How NAT traversal works (2020)

https://tailscale.com/blog/how-nat-traversal-works/

by punnerud • 3 years ago

305 106 3 years ago

tailscale.com

seabass-labrax• 3 years ago

[2020]

tadfisher• 3 years ago

[NAT]

was thinking, traversing Nat is dead-simple

gjvc• 3 years ago

recency troll

yuvadam• 3 years ago

And yet it's the bible of NAT traversal.

wmf• 3 years ago

Nah, this is the bible of NAT traversal: https://bford.info/topics/Network-Address-Translation/ (2005)

dang3• 3 years ago

It's just the convention to put the year in the title when the article is older than a year or so.

Historical material is always welcome on HN and it's fun for readers to know what year an article dates from.

commandlinefan3• 3 years ago

Man I wish there was more documentation like this out there, too.

dang3• 3 years ago

Added. Thanks!

Jyaif• 3 years ago

For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic. No amount of clever NAT tricks is going to get around the firewall eating your packets.

I'm not familiar with DNS at all, but can't you craft UDP packets that look like DNS packets, but contain a useful payload with which you can do the whole STUN/UDP-hole-punching/p2p dance, assuming you have matching that can unwrap the payload?

stevekemp• 3 years ago

TCP over DNS has been a thing for a long time, though I guess it's fallen out of favour because "real" VPNs are so easily available nowadays.

For example you can see here:

https://analogbit.com/software/tcp-over-dns/

Hikikomori• 3 years ago

Smarter firewalls can filter not just ports but the payload as well.

gnfargbl2• 3 years ago

Even if you could, the problem would come when you wanted to establish a data connection with the remote end. Assuming "except for DNS traffic" actually means "except for packets on the well-known port for DNS" then you are going to be restricted to sending packets with destination port 53. This means that for comms to work, the remote end is going to have to be able to receive packets on port 53. Some kinds of network setups may allow this -- all of this stuff ends up being hideously dependent on the detail -- but many won't.

cephei• 3 years ago

It certainty depends on how the network is doing the packet scanning and the other measures in place. If the security measures include a allow list of DNS servers, then there's little that can be done to bypass it.

kjs3• 3 years ago

There are all sorts of tunnel-thru-DNS possibilities (e.g. iodine, heyoka, etc.). There also a number of ways to mitigate (e.g. limit destination DNS servers, traffic analysis to spot anomalous 'queries', etc.). It's an arms race.

tw04• 3 years ago

Any modern enterprise firewall has app identification built in and will quickly identify you trying to send non dns traffic. And after the solarwinds debacle, everyone with a security team is looking for it.

commandlinefan3• 3 years ago

Well, there'd be no way for a firewall to block a request like:

dig -b peername data.data.data.data

And let the "name server" on the other end listening on port 53 parse the data. You _would_ have to be able to listen on port 53 and of course it would be slow as hell, but it's unblockable.

gnfargbl2• 3 years ago

(NATs do not enhance security in any meaningful way, but that’s a rant for another time.)

Eh, I'm not sure I agree. People plug all kinds of weird and wonderful crap into their home networks, they turn off their Windows firewall and allow connections to RPC ports, all sorts of nonsense. The main factor that prevents even more stuff being exposed to the internet than now (and there's a lot exposed already) is the prevalence of IPv4 NAT devices.

OK, UPnP is a thing, and NATs aren't firewalls, but in practice NATs do look and feel enough like a firewall to be at least somewhat useful to the average home user.

johncolanduoni2• 3 years ago

Every router firewall in existence supports some sort of established/related only rule. That’s sufficient to provide all security benefits of a NAT except the hiding of which devices behind the router are making which connections.

noselasd• 3 years ago

Only if those were on by default.

Back in the days when my ISP didn’t do NAT , their dsl modem didn’t block anything.

Most people do not have the capability to secure their internet connection. I still think the op has a good point in that NAT has protected many home networks , if nothing else from ISP incompetence , even if in theory a firewall could have done it better.

benlivengood• 3 years ago

Sure, but any stateful firewall on the home Internet router would be just as secure as NAT. UPnP and friends would create only an allow rule instead of a combination allow rule plus a DNAT entry.

If NAT did not have a stateful firewall then it would simply let in any traffic for which an SNAT or DNAT entry matched or else forward it to some default host that was expected to receive most traffic, perhaps the router device itself.

bombcar2• 3 years ago

If we didn't have NAT default home routers would ship with "all ports open and routed" firewalls; and in fact that can still happen with IPv6.

So in a very real way it has provided protection accidentally.

tjoff• 3 years ago

Sure, but the failure modes of NAT is pretty good and the NAT is hard to misconfigure.

That the crappiest firewall could do the same is missing the point. People back in the day didn't have crappy firewalls, they had nothing.

NAT was and is a brilliant first step that everyone has nowadays.

UPnP tries its best to make it worse though but the existence of UPnP is alone proof that a crappy or good firewall wouldn't have been better than NAT for the common user.

w7• 3 years ago

What makes NAT the "main factor" for that.

I'm pretty sure every consumer router since at least 2002, if not further back, has had some stateful firewall implementation with default deny rules.

whatupmiked• 3 years ago

NATs provide one form of network segmentation. Network segmentation is a commonly accepted network security practice. The author maybe thinking of a specific application of NAT, but a blanket “NAT provides no additional security” is not a defensible position.

otabdeveloper4• 3 years ago

Thank you for the voice of sanity.

(And anyways, stateful firewalls are a special case of a simple NAT. If you're doing stateful address mangling anyways, why not do something actually useful and hide your LAN addresses?)

AtlasBarfed• 3 years ago

The NAT position is long-parroted IPV6 zealotry.

These people saying "the idiots with NATs will turn them off to get things running", but think that "the idiot user" with firewall-only setups won't .... turn off the firewall as the first (and last) debugging step?

And the assumption that whatever ipv6 space assigned you/your device will be sufficient is ... optimistic. I can easily see some CGNAT thing giving a single ipv6 to your mobile device and you need to NAT on your end to do more fun things. It doesn't matter than ipv6 can address every atom in the universe. Sine lazy ISP is going to decide your endpoint a single atom.

throw0101b6• 3 years ago

The main factor that prevents even more stuff being exposed to the internet than now (and there's a lot exposed already) is the prevalence of IPv4 NAT devices.

All of this is blocked by default-deny firewall rules.

I have IPv6 at home from my residential ISP, and I get a globally routable a 2000::/3 IPv6 address on my systems (via SLAAC), but they are not accessible from the public Internet by default.

The idea of publicly routable = publicaly accessible needs to die.

iforgotpassword6• 3 years ago

The thing is, you can turn that off. So if the user can turn it off, they will eventually turn it off, because that's just what people do if they have some problem somewhere: toggle random settings they have no clue what they mean, or asked their 14yo "computer wizard" nephew for advice, you name it.

With NAT it is impossible to disable the firewall. The worst you can do is put one machine into the DMZ, and people did do that of course because of what I just said, but at least it isn't the entire network at once with every shitty iot fridge smart bulb vibrator toaster the average Joe has today.

wg0• 3 years ago

Can this be allowed by default? If yes, is this configuration with the ISP or the end user?

harha_• 3 years ago

What I've used NAT for (for example in AWS), is that I've split the virtual network into "public" and "private" subnets. Public subnets are behind an internet gateway and are open to the internet, private ones are either only private with no internet access or behind a NAT gateway to allow connections to internet but not the other way around. My understanding has been that it's common practice, segmenting a network like that. I obviously would still configure firewalls for the devices in those different subnets, but what is this kind of NAT usage called if not security enhancement?

One thing that came to my mind typing this is, that the fact that there's NAT in there could mask problems with the firewall configuration, if one does not truly test whether the firewall rules are strict enough or not. So if those private subnets behind NAT would somehow magically be switched behind an internet gateway, security holes could emerge.

dfawcus3• 3 years ago

Nope, that is just a form of NAT one is forced to use for IPv4, with a stateful session table. It is that session tracking which adds the "outbound initiated" only behaviour.

There is a form of NAT for IPv6 (NPTv6) which can be used to gain pseudo provider independence. It has static mapping rules, with no session table. It allows for "inbound initiated" sessions.

So it is NAT which is globally reachable, without the endpoint addresses being globally routable.

dfawcus3• 3 years ago

See https://www.rfc-editor.org/rfc/rfc6204.html and its update https://www.rfc-editor.org/rfc/rfc6204.html which were created because of the "NAT adds security" delusion.

They address basic requirements for customer edge IPv6 routers, and some consumer devices are now following that.

me-vs-cat• 3 years ago

I believe you meant your second link to be https://www.rfc-editor.org/rfc/rfc7084

dang3• 3 years ago

How NAT traversal works (2020) - https://news.ycombinator.com/item?id=30707711 - March 2022 (37 comments)

How NAT Traversal Works - https://news.ycombinator.com/item?id=24241105 - Aug 2020 (28 comments)

klabb33• 3 years ago

This is an incredible resource on NAT traversal in practice. I used it as a reference while building a server-assisted p2p-over-TCP[1] system. The post covers UDP but all of the theory applies to TCP as well – you just need some SO_REUSEPORT dual dial/listen magic so the code will look a bit different.

Meta: The post alludes to this, but I think NAT traversal is an inaccurate and confusing term. I like “hole punching” a lot more as a general term. It gets the message across without the myopic connotation that it’s all about NATs – it isn’t.

[1] https://github.com/betamos/rdv

JoeAltmaier• 3 years ago

It's a good primer. It's also more complicated than that.

NAT mappings can change (your router can reboot etc). So you have to be ready to 'try again' dynamically.

Port number can be as important as IP address. The STUN server can see one port number, but a different one may be used by your gateway for talking to the real desired endpoint. Result: fail, at least for TCP

I used to do all this but used UDP. One port for talking to everybody. Had to tag packets with some kind of UID so I knew who it was from, since every conversation came thru the same port. That worked better.

Still UDP is the red-headed stepchild of the internet. Some countries(!) didn't used to allow it. Some corporations don't. Some routers screw it up regularly - drop packets, reorder packets, don't do reassembly if they get fragmented. Had to recover from all that.

My approach was to use WiFi size packets (<=512 bytes) with a UID and a single port for everything. Put sequence numbers in them, and reorder if they got swapped (a regular thing with some routers).

And always be prepared to revert to TURN (your public server that forwards packets for you).

klabb33• 3 years ago

It's a good primer. It's also more complicated than that.

Subjective, but I think primer is an understatement. Tailscale did an absolute stellar job of simplifying the problem to something that works very well in practice, and is relatively simple to implement.

NAT mappings can change (your router can reboot etc). So you have to be ready to 'try again' dynamically.

Yes, this is a big issue and indeed a source of a lot of stateful complicated logic in the tailscale client and anyone else who attempts it. And that’s aside from the absolute clusterfuck that is UPnP – super complicated for what it does. In my view it’s not enough bang for the buck; if STUN won’t work (some mobile carriers and enterprise networks) then port-mapping protocols probably won’t work either. You gotta cut your losses somewhere.

The STUN server can see one port number, but a different one may be used by your gateway for talking to the real desired endpoint.

The post covers this in detail. They call it endpoint-dependent mapping.

anyfoo6• 3 years ago

> NAT mappings can change (your router can reboot etc). So you have to be ready to 'try again' dynamically.
Yes, this is a big issue [...] You gotta cut your losses somewhere.

And the article also gets into that, in detail. It appears that tailscale not only dynamically retries, they also test out all possible paths to switch to the best one.

kortilla3• 3 years ago

if STUN won’t work (some mobile carriers and enterprise networks) then port-mapping protocols probably won’t work either

This is a bad conclusion. STUN dies on endpoint dependent mappings and proper port mapping setups are specifically to allow this. The oversubscription enabled by endpoint dependent mapping is drastically higher if you have the memory to run it. The correlation between modes and support for the protocols does not work in the way you think.

anyfoo6• 3 years ago

You should really read the article, because it covers every single point you just mentioned.

teleforce• 3 years ago

NAT, the classic example of technical debt created when scalability is not in every designer mind.

MzHN2• 3 years ago

The article goes through all of this, but since it starts with

For example, WebRTC uses this bag of tricks to send peer-to-peer audio, video and data between web browsers.

I think it is worth emphasizing that since web users are increasingly mobile users, having P2P on the web is nearly impossible.

Mobile users have the worst kinds of CGNATs with everything randomized for every connection. Throw in a couple of IPv4 only non-mobile clients, and your IPv6 mobile users can't even connect to them even if they didn't have NAT.

So for my use cases the TL;DR of the article is: "How NAT traversal works", it does not. At least not on the web.

Which is a shame.

dave_universetf2• 3 years ago

That is not accurate to our experience. Mobile devices on cell networks see about the same amount of success with p2p connections as other devices. Mobile networks differ vastly in their behaviors when it comes to NAT traversal, and you can certainly find specific carriers that behave poorly, but it's far from the death of p2p that you describe.

That said, you _do_ need last-resort relaying, not just for the more difficult mobile networks but for all kinds of edge cases (e.g. the UC Berkeley guest wifi case I mentioned in the article). So in that sense, the purist argument is that p2p is impossible since you will always need to have relaying as an option. But the key is that p2p works well enough to make the relays economically viable to operate, and that _some_ connectivity is usually sufficient, even if it's not the theoretically optimal connectivity.

Plus, IPv6 continues to be deployed (and AWS charging for IPv4 is another step on that path), so while some CGNAT deployments work to degrade p2p, IPv6 in parallel is restoring better p2p connectivity than IPv4's allowed for decades. It's not all roses, but it's possible to be optimistic about a future where cloud servers aren't the only option.

MzHN2• 3 years ago

Thanks for the optimism.

I guess I'm just salty, that 100% of my users can't connect to 100% of my users, but that is only because I'm building highly local hobby projects, so I can't see the global picture where the % is a lot more sensible.

How NAT traversal works (2020)

Related Stories