[HN Gopher] How NAT traversal works (2020)
___________________________________________________________________
How NAT traversal works (2020)
Author : punnerud
Score : 191 points
Date : 2023-08-02 10:22 UTC (1 days ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| Jyaif wrote:
| > 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?
| gnfargbl wrote:
| 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 wrote:
| 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.
| stevekemp wrote:
| 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/
| tw04 wrote:
| 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.
| commandlinefan wrote:
| 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.
| JackGreyhat wrote:
| Check this:
|
| https://www.paloaltonetworks.com/cyberpedia/what-is-dns-
| tunn...
|
| See the "Preventing DNS Tunneling" chapter.
| kjs3 wrote:
| 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.
| Hikikomori wrote:
| Smarter firewalls can filter not just ports but the payload as
| well.
| [deleted]
| klabb3 wrote:
| 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 wrote:
| 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).
| gnfargbl wrote:
| _> (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.
| harha_ wrote:
| 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.
| dfawcus wrote:
| 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.
| dfawcus wrote:
| 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.
| johncolanduoni wrote:
| 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 wrote:
| 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.
| lxgr wrote:
| > Back in the days when my ISP didn't do NAT , their dsl
| modem didn't block anything.
|
| As it should - a modem is not a router.
| johncolanduoni wrote:
| Modems don't generally block anything, unless they're a
| modem/router combo. Have you ever actually encountered a
| device that had a NAT but no stateful firewall?
| throw0101b wrote:
| > _Only if those were on by default._
|
| My Asus RT-AC68U, released in 2013, did/does (by default).
|
| * https://www.pcmag.com/reviews/asus-rt-ac68u-dual-band-
| wirele...
|
| Are you saying routers in 2023 do not? Can you list any
| examples of currently shipping CPEs that do not?
| samcat116 wrote:
| They are on by default now. Have been for years.
| w7 wrote:
| 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.
| benlivengood wrote:
| 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.
| bombcar wrote:
| 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.
| throw0101b wrote:
| > _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._
|
| [citation needed]
|
| Because my not-very-new Asus AC-something home router does
| get a /56 assignment from my residential ISP and _none_ of
| my systems with a 2000:: /3 address are accessible from the
| Internet.
| anyfoo wrote:
| Hah? I'm missing a step here. Why would they ship like
| that?
| bombcar wrote:
| Because they _did_ ship like that, years ago - and some
| routers pretty recently would default "route all" unless
| they were in NAT mode.
|
| And even if the defaults were secure, I guarantee someone
| would "route all" when that was a known "fix it" issue -
| just like you used to find people who would forward
| 1-65535 to their PC to play Internet games.
|
| NAT is still annoying and wrong, perhaps, but it DOES
| provide something akin to a layer of security in some
| cases; just like security through obscurity DOES provide
| some security for many things.
| throw0101b wrote:
| > _Because they_ did _ship like that, years ago - and
| some routers pretty recently would default "route all"
| unless they were in NAT mode._
|
| And guess what: people _used to_ connect their PCs
| directly to their DSL /cable modems and run PPPoE (or
| DHCP) on their Windows PCs directly, and their Windows
| PCs used to get assigned public IP addresses.
|
| Times change. It's no longer 2003.
|
| We've learned things in both the IPv4 and IPv6 space over
| the decades.
| anyfoo wrote:
| > Because they did ship like that, years ago
|
| Yeah, years ago.
|
| Years ago there was no encryption whatsoever.
|
| "Host based" authentication was common. And not the type
| that used certificates (or, in fact, cryptography of any
| kind), but the kind where you would enter IP addresses,
| host names, or even just patterns of those into a file
| called ".rhosts", and those then were the hosts that were
| allowed to run commands as root completely without
| further authentication.
|
| When you shared a folder in Windows using SMB, you
| usually shared it to anyone, including the Internet.
| Windows did not even have a good concept of separate user
| accounts. This is not an exaggeration, a very significant
| portion of unsuspecting users had their hard disk made
| available to everyone because they intended to share it
| with their own little local network. No password, no
| nothing.
|
| The Internet was littered with public FTP servers, of
| which a lot, and a lot of very public ones, had a
| directory called "/incoming" where you could upload and
| make available things for everyone else.
|
| IRC had a thing called "CTCP", client-to-client-protocol,
| with which two users' IRC clients communicated directly,
| client IP to client IP. That's right, you were chatting
| (or not chatting) to some "rando", and they not only had
| your IP address, they had the ability to send commands to
| your IRC client.
|
| WiFi, for a surprisingly long time, had encryption
| optional. And when it was turned on, it was easy to
| crack.
|
| The Internet was a very trusting place, and became
| gradually less so. With or without NAT, routers would
| have added strict, stateful firewalls, for the same
| reasons that everything else I've written above stopped.
| [deleted]
| zamadatix wrote:
| All ports open and routed outbound sure, that's how they
| are now. Inbound though there isn't any clear reason to
| suddenly switch to allowing inbound session initiation to
| any port just because you aren't translating the port.
|
| It may have been a good kick back 20+ years ago when
| security wasn't as much a concern as just getting working
| internet. Not sure it's actually a relevant distinction at
| this point though.
| tjoff wrote:
| 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.
| whatupmiked wrote:
| 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 wrote:
| 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?)
| throw0101b wrote:
| > _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.
| iforgotpassword wrote:
| 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.
| throw0101b wrote:
| > _With NAT it is impossible to disable the firewall._
|
| My Asus has Advanced Settings > Firewall > Enable Firewall:
| Yes/No. (Also Enable IPv6 Firewall: Yes/No.)
|
| It also has Advanced Settings > WAN > Port Forwarding to
| expose specific ports and DMZ to completely expose a
| machine.
|
| You can punch holes in IPv4 security just fine.
| iforgotpassword wrote:
| That's not what you think but some additional nonsense
| like turning off ICMP replies on the wan interface.
|
| If you only get one public ipv4 assigned by your ISP,
| there is simply no way to set it up in a way that every
| device on your network is reachable from the internet on
| all ports with just one click.
| throw0101b wrote:
| I'll go with the IETF position: NAT
| (particularly NAPT) actually has the potential to lower
| overall security because it creates the illusion
| of a security barrier, but does so without the
| managed intent of a firewall. Appropriate
| security mechanisms are implemented in the end host,
| without reliance on assumptions about routing
| hacks, firewall filters, or missing NAT
| translations, which may change over time to enable a
| service to a neighboring host. In general,
| defined security barriers assume that any threats
| are external, leading to practices that make internal
| breaches much easier.
|
| * https://datatracker.ietf.org/doc/html/rfc2993#section-9
|
| The more likely scenario is your system (or phone) gets
| compromised, it lives behind the supposedly secure NAT
| "firewall", and since you had a false sense of security
| from NAT your entire internal network has all sorts of
| holes.
|
| The era of network moats was over long ago, and NAT is
| simply perpetuating the illusion.
|
| I'd rather take the risk of SPI IPv6 firewalls, have the
| alleged chaos of allegedly exposed IoT systems, and force
| everyone to up their security game: short-term pain is
| healthier IMHO.
| horsawlarway wrote:
| > The more likely scenario is your system (or phone) gets
| compromised, it lives behind the supposedly secure NAT
| "firewall"
|
| It's far easier than that - web pages running on your
| machine are also "calling from inside the house" if you
| will (https://static.tvtropes.org/pmwiki/pub/images/campf
| ire.png)
|
| You load up some js on any random site and it can do a
| pretty thorough scan of your network in a few minutes.
| Arnavion wrote:
| >With NAT it is impossible to disable the firewall.
|
| Nonsense. If we suppose a switch to turn the firewall off,
| we can suppose a switch to turn NAT off and convert the
| router into a bridge that connects LAN and WAN. Then a LAN
| device can speak DHCP to your ISP and get its own public
| address. It doesn't have to be limited to one LAN device
| either; my ISP allows two IPs per customer connection to
| make it easier for people power-cycling their routers /
| ONTs during troubleshooting.
| iforgotpassword wrote:
| That's an outlier. Almost every ISP hands out 0 to 1 ipv4
| addresses. And even if it's two, the user will quickly
| realize that "internet is broken" on some of their
| devices, as two random ones picked up the addresses and
| the rest don't get any, and reverse the config change.
| Arnavion wrote:
| My argument is about LAN devices ending up with publicly
| reachable IPs. It's not contingent on the ISP allowing
| more than one IP address per customer connection.
|
| BTW, since you think you can turn your router's firewall
| off and rely on just the NAT to protect you, please tell
| me what you think will happen when a packet with
| destination IP 192.168.1.2 appears on your router's WAN
| interface. What component of the router do you think
| prevented those packets from crossing to LAN? Hint: its
| name starts with "f" and ends with "irewall".
| ozim wrote:
| Sorry but your argument is moot. Yes NAT is not firewall.
|
| No my devices are not receiving random packets with
| internal IP addresses often enough for me to worry about
| it.
|
| Even better not single of my devices living behind only
| nat in 20+ years was taken over or ransomed.
|
| If it would be real problem I would hear about it daily
| and - if it would be so easy - all kinds of APT groups
| would take over devices behind NAT en mass. I don't
| believe that any residential router has firewall enabled
| by default and only devices that are taken over are ones
| really having public IP.
|
| Anyone can prove me wrong sharing links to articles and
| instances where there was occurrence of mass takeovers
| using NAT traversals.
| rzzzt wrote:
| Infrastructure that lets applications open the door for
| themselves like NAT-PMP and UPnP are also available, but
| not many people turn them off.
| iforgotpassword wrote:
| It is, and I guess many tech savvy people turn that off
| immediately, but it's still not as bad. You don't
| suddenly expose every Windows machine, every iot device's
| telnet port with guessable password etc to the internet.
| wg0 wrote:
| Can this be allowed by default? If yes, is this configuration
| with the ISP or the end user?
| dang wrote:
| Related:
|
| _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)
| seabass-labrax wrote:
| [2020]
| gjvc wrote:
| recency troll
| yuvadam wrote:
| And yet it's the bible of NAT traversal.
| commandlinefan wrote:
| Man I wish there was more documentation like this out there,
| too.
| dang wrote:
| 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.
| wmf wrote:
| Nah, this is the bible of NAT traversal:
| https://bford.info/topics/Network-Address-Translation/ (2005)
| api wrote:
| This old post too:
|
| https://www.zerotier.com/blog/the-state-of-nat-traversal/
|
| There are lots of others. The TS post is well written
| though, and contains some interesting information like the
| way the birthday paradox relates to punching symmetric
| NATS.
| dang wrote:
| Added. Thanks!
| tadfisher wrote:
| [NAT]
|
| _was thinking, traversing Nat is dead-simple_
___________________________________________________________________
(page generated 2023-08-03 23:00 UTC)