How NAT traversal works (2020)(tailscale.com)
tailscale.com
How NAT traversal works (2020)
https://tailscale.com/blog/how-nat-traversal-works/
110 comments
> 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.
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.
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.
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.
> 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.
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.
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.
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.
I'll go with the IETF position:
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.
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.
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.
> … does so without the managed intent of a firewall.
Most home networks have no management, or intent, at all. People just buy whatever boxes are sold to them and plug them in.
Now, yes, if you actually design a network, and properly set things up, then a firewall will give you better control. Will grampa Jim do that? Absolutely not.
Most home networks have no management, or intent, at all. People just buy whatever boxes are sold to them and plug them in.
Now, yes, if you actually design a network, and properly set things up, then a firewall will give you better control. Will grampa Jim do that? Absolutely not.
You can also have LAN before NAT, and if you're not firewalled from LAN, you can be attacked.
> 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/campfire.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.
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/campfire.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.
> I'd rather take the risk of...
But not on your own network or your parents/friends whoever. You want others to have that pain, as a policy decision, right? It's reasonable but worth clarifying.
But not on your own network or your parents/friends whoever. You want others to have that pain, as a policy decision, right? It's reasonable but worth clarifying.
With one public address you can expose a socks proxy that will provide access to your local network.
Hole punching requires cooperation by the application that wants to be reached. That's not quite the same thing as turning off a firewall (or equivalently, port forwarding).
Infrastructure that lets applications open the door for themselves like NAT-PMP and UPnP are also available, but not many people turn them off.
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.
As far as I see the only thing you're really suggesting here is that consumer routers should have firewalls that can't be disabled, and that NAT currently fulfills this function.
Much "We're from Silicon Valley and we're here to help" vibes.
Much "We're from Silicon Valley and we're here to help" vibes.
For the ISP-provided one, absolutely a sensible move. Just like most ISPs here don't offer bridging mode anymore in their modem+router combos.
This still doesn't mean someone who has no clue will end up buying a device that allows them to do this, and ignore a warning message in big bold letters and still do it, but the vast majority of people will be saved from themselves.
This still doesn't mean someone who has no clue will end up buying a device that allows them to do this, and ignore a warning message in big bold letters and still do it, but the vast majority of people will be saved from themselves.
That’s what my current ISP does - their current router firmware doesn’t have functioning UPnP, nor does it have an option for port forwarding.
It’s extremely annoying.
It’s extremely annoying.
>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.
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.
That breaks, however, once there is more than 1 customer device on the network. Since "multiple devices" case is super common, I don't think this is something to be concerned about for general public.. "hey, you broke by ipad, whatever checkbox you unchecked, check it back"
Yes and you do this accidentally by plugging WAN cable into LAN port of the router, effectively bridging your interal devices with ISP, and if DHCP from ISP wins the race against your router, then your PC is on global address with no firewall.
True story!
Things like Homenet that tried to fix this did not go anywhere
True story!
Things like Homenet that tried to fix this did not go anywhere
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.
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".
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".
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.
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.
>Even better not single of my devices living behind only nat in 20+ years was taken over or ransomed.
Yeah, because you didn't turn off the firewall. And/or because your ISP was being nice / competent and not routing packets to you that didn't make sense for your assigned route.
Yeah, because you didn't turn off the firewall. And/or because your ISP was being nice / competent and not routing packets to you that didn't make sense for your assigned route.
Still my point is right, NAT traversal hacking is not an issue and is complicated enough to not be practical.
Residential off the shelf routers don’t have firewall for incoming traffic. For business use you always put hardware firewall behind ISP router, I don’t have firewall at home.
Residential off the shelf routers don’t have firewall for incoming traffic. For business use you always put hardware firewall behind ISP router, I don’t have firewall at home.
> Residential off the shelf routers don’t have firewall for incoming traffic
[citation needed]
[citation needed]
This is 100% wrong.. all consumer routers have firewall functionality built in.
[deleted]
I think the component that prevents that packet from crossing from WAN to LAN is, precisely, the NAT. Or more specifically, that no dynamic NAT mapping has been established previosuly, from an outbound transmission from 192.168.1.2 towards the remote source of the packet.
Given how NAT works, if there hadn't been any outbound connection, there is no mapping of transport addresses in the NAT table, and thus an incoming packet is rejected. The firewall would be _behind_ the NAT, on the internal side, applying _additional_ rules to packets that did match some of the NAT mapping rules and were able to cross that boundary.
So to all effects, if the NAT discards an incoming packet, the firewall doesn't even get to process it.
Which is not to say that some vendors confuse this distinction, and call "firewall" to the NAT behavior.
Given how NAT works, if there hadn't been any outbound connection, there is no mapping of transport addresses in the NAT table, and thus an incoming packet is rejected. The firewall would be _behind_ the NAT, on the internal side, applying _additional_ rules to packets that did match some of the NAT mapping rules and were able to cross that boundary.
So to all effects, if the NAT discards an incoming packet, the firewall doesn't even get to process it.
Which is not to say that some vendors confuse this distinction, and call "firewall" to the NAT behavior.
That is only one specific, limited type of NAT, i.e. an "address dependent filtering" NAT.
The recommended (and common) form is EIM (Endpoint Independent Mapping), where one a private host+port (say 192.168.1.1:4567) has formed a connection to some public location (e.g. 1.1.1.1:53), and acquired a mapping on the WAN of (WAN-IP:pppp) then anywhere on the whole public Internet can form a connection to 192.168.1.1:4567 by sending packets to WAN-IP:pppp.
That is one of the ways in which NAT-Traversal ("hole punching") works. It has the nice property that P2P applications (e.g. online games) can form direct connections between devices behind NATs.
That same property generally applies for both TCP and UDP, and for all ports.
The thing which would prevent that in some NAT is the filtering behaviour, i.e. the session table which people are conflating with a firewall. If that filtering is also "Endpoint Independent" (which it often will be for consumer devices), then the above description applies.
If the filtering is "Address Dependent", or "Address and Port Dependent" then the more restrictive cases of other public internet devices not being able to use the mapping applies. However this is usually only seen with various forms of enterprise deployed NAT (since they often have firewalls also explicitly installed).
The recommended (and common) form is EIM (Endpoint Independent Mapping), where one a private host+port (say 192.168.1.1:4567) has formed a connection to some public location (e.g. 1.1.1.1:53), and acquired a mapping on the WAN of (WAN-IP:pppp) then anywhere on the whole public Internet can form a connection to 192.168.1.1:4567 by sending packets to WAN-IP:pppp.
That is one of the ways in which NAT-Traversal ("hole punching") works. It has the nice property that P2P applications (e.g. online games) can form direct connections between devices behind NATs.
That same property generally applies for both TCP and UDP, and for all ports.
The thing which would prevent that in some NAT is the filtering behaviour, i.e. the session table which people are conflating with a firewall. If that filtering is also "Endpoint Independent" (which it often will be for consumer devices), then the above description applies.
If the filtering is "Address Dependent", or "Address and Port Dependent" then the more restrictive cases of other public internet devices not being able to use the mapping applies. However this is usually only seen with various forms of enterprise deployed NAT (since they often have firewalls also explicitly installed).
NAT will map an incoming packet with destination WAN_IP:port to LAN_IP:port. It is irrelevant for incoming packets with destination LAN_IP:port.
I have been trying to figure this out thank you for this response
192.168.1.2 should be dropped because it doesn't match the WAN subnet. If your router is set up wrong at the factory to forward any traffic through the WAN port I wouldn't trust the firewall, let alone NAT, save me...
The whole conceit of this conversation is that iforgotpassword has (a thought experiment of) a router where they've managed to "turn off the firewall" but still expect safety due to the use of NAT. My comment was about how that is not true. ie a) if it's easy to turn off the firewall then it's also equivalently easy to turn the router into a bridge, and b) if there is no firewall then bogons on the WAN will not be filtered and will instead be forwarded to the LAN.
You are technically right, which is the best kind of right, but then again, what would pose a greater risk: ipv4 with NAT where you turned the firewall of, as you described, or ipv6 with no nat where the firewall gets turned off? In your example with a packet coming in on the wan side with a destination address in my lan segment, how exactly did that packet get there? Spoofing the source address is easy, but for a spoofed destination you'd have to be my ISP, or have hacked my ISP.
[deleted]
IPv6 might still be more secure; granted, with IPv6 you would have direct access to devices you know, but blind enumeration of other LAN devices would take more time that literally scanning the entire IPv4 internet.
How would such a packet get routed to you in the first place?
Your ISP could be incompetent or malicious and not filter bogons out. Or you could be sharing a subnet with another tenant that has a misconfiguration on their end or is just plain malicious.
I see. But wouldn't your router simply then drop the packet, since there would be no WAN-side entry for that address in the translation table?
You don't need a translation table to cross interfaces.
Any router has forwarding enabled (because otherwise it's not a router and would discard packet not addressed to it), so if the packet hits WAN with an address in LAN subnet - it's just get routed if there is no explicit 'deny all from all' on WAN, on the FORWARD table, to be precise.
Surely, you can't forward the packet with dst_address in RFC1918 over the Internet, but you can do that if you are close enough.
This is the reason the NAT is not a security boundary or firewall: NAT apologists are saying what 'NAT drops anything on WAN', except it:
is not even involved if the attacker is close enough to forward the packets with your LAN subnet at your router WAN interface
doesn't help if there some established session or misconfiguration[1] which explicitly allows to access the host on the LAN subnet
Take a look at the table at [0]:
And to the chain traversal order:
[0] https://www.digitalocean.com/community/tutorials/a-deep-dive...
EDIT:
[1] or a helpful autoconfiguration tech:
Any router has forwarding enabled (because otherwise it's not a router and would discard packet not addressed to it), so if the packet hits WAN with an address in LAN subnet - it's just get routed if there is no explicit 'deny all from all' on WAN, on the FORWARD table, to be precise.
Surely, you can't forward the packet with dst_address in RFC1918 over the Internet, but you can do that if you are close enough.
This is the reason the NAT is not a security boundary or firewall: NAT apologists are saying what 'NAT drops anything on WAN', except it:
is not even involved if the attacker is close enough to forward the packets with your LAN subnet at your router WAN interface
doesn't help if there some established session or misconfiguration[1] which explicitly allows to access the host on the LAN subnet
Take a look at the table at [0]:
And to the chain traversal order:
Incoming packets destined for the local system: PREROUTING -> INPUT
Incoming packets destined to another host: PREROUTING -> FORWARD -> POSTROUTING
[0] https://www.digitalocean.com/community/tutorials/a-deep-dive...
EDIT:
[1] or a helpful autoconfiguration tech:
NAT fanboi: I am secure because NAT, har har
Helpful media player with UPnP: hold my beer
Torrent client: hold /my/ beerSure, 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.
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.
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.
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.
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.
So in a very real way it has provided protection accidentally.
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.
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.
> 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.
[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.
Hah? I'm missing a step here. Why would they ship like that?
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.
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.
> 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.
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.
> 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 DCC (Direct Client-to-Client). CTCP is another in-line protocol that allows things like /me or asking what software other clients run.
That's DCC (Direct Client-to-Client). CTCP is another in-line protocol that allows things like /me or asking what software other clients run.
You’re way off on your comparisons. Routers that shipped with WPA3 had an IPv6 setting of “enable ipv6” and nothing else. Comparing it to a bygone era of no encryption is dumb.
On a router I had back in the day that seemed to only offer IPv6 support with a toggle of "enable IPv6" it still had a stateful firewall of all out and no new in by default, you just couldn't add custom rules because its whole legacy firewall UI was based around the NAT port forwarding.
I've never had a home router that just completely opened IPv6 to the world on my whole home network.
I've never had a home router that just completely opened IPv6 to the world on my whole home network.
I’m not sure what you’re saying. That that checkbox enabled IPv6 and made all IPv6 capable devices behind the router accessible without any filtering?
You said “had”, so presumably people found out what a bad idea that is and routers added filtering without also introducing NAT for IPv6. Isn’t that exactly the point?
You said “had”, so presumably people found out what a bad idea that is and routers added filtering without also introducing NAT for IPv6. Isn’t that exactly the point?
Yes, that’s exactly what they did. The assumption (presumably) was that anyone smart enough to browse the router settings would know to put firewalls on everything.
After all, the entire point of ipv6 was to allow connections to internal devices. If the router blocks it, what’s the fucking point? (See the dichotomy now between people who claim ipv6 stateful filtering for routers is obvious and the people who want ipv6?)
They eventually added in a default stateful firewall as well for ipv6, which made it completely pointless to convert. Still can’t host games without STUN, etc.
After all, the entire point of ipv6 was to allow connections to internal devices. If the router blocks it, what’s the fucking point? (See the dichotomy now between people who claim ipv6 stateful filtering for routers is obvious and the people who want ipv6?)
They eventually added in a default stateful firewall as well for ipv6, which made it completely pointless to convert. Still can’t host games without STUN, etc.
> 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.
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.
Gas back in the day was also shipped with lead additives. Things change. I don't think I've ever had a home router that didn't also advertise a stateful firewall and I've been buying home routers since 802.11b was a new thing.
Are you sure you're not thinking of modems not shipping with a firewall? Because yeah, a pure modem probably doesn't have a firewall. I wouldn't want a modem with a firewall.
Are you sure you're not thinking of modems not shipping with a firewall? Because yeah, a pure modem probably doesn't have a firewall. I wouldn't want a modem with a firewall.
[deleted]
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.
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.
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.
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?)
(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?)
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.
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.
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.
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?
> 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.
As it should – a modem is not a router.
> 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?
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?
They are on by default now. Have been for years.
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.
They address basic requirements for customer edge IPv6 routers, and some consumer devices are now following that.
I believe you meant your second link to be https://www.rfc-editor.org/rfc/rfc7084
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.
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.
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.
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.
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.
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.
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
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
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)
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)
NAT, the classic example of technical debt created when scalability is not in every designer mind.
[2020]
And yet it's the bible of NAT traversal.
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.
Historical material is always welcome on HN and it's fun for readers to know what year an article dates from.
Nah, this is the bible of NAT traversal: https://bford.info/topics/Network-Address-Translation/ (2005)
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.
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.
Man I wish there was more documentation like this out there, too.
[NAT]
was thinking, traversing Nat is dead-simple
was thinking, traversing Nat is dead-simple
Added. Thanks!
recency troll
> 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?
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?
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.
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.
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.
Check this:
https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunn...
See the "Preventing DNS Tunneling" chapter.
https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunn...
See the "Preventing DNS Tunneling" chapter.
Interesting, thanks. Seems like the firewall would have to be specifically configured to block, say "WebRTC through DNS tunneling" in this case, though.
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/
For example you can see here:
https://analogbit.com/software/tcp-over-dns/
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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).
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).
> 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.
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.
> > 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.
> 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.
We do. This is also not our own insight/invention, to be clear. We're implementing the spiritual core (but not the SIP clothing) of the ICE protocol (https://datatracker.ietf.org/doc/html/rfc8445), which was developed by Google and the XMPP foundation as part of Jingle, the XMPP extension for p2p voice and video. That same stuff lives on in browsers today as part of WebRTC.
ICE in particular provides a model for probing potentially feasible datapaths, selecting the best if multiple paths are available, and suggests how to handle datapath failure.
It's not a weekend's worth of hacking to get it working robustly, but it's also very doable.
ICE in particular provides a model for probing potentially feasible datapaths, selecting the best if multiple paths are available, and suggests how to handle datapath failure.
It's not a weekend's worth of hacking to get it working robustly, but it's also very doable.
Thanks for your article. I’m not even currently working on any network-related stuff, and I found it very interesting and enlightening to read.
> 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.
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.
Apologies for the confusion. I did not know about this type of setup. I am aware of the oversubscription problem but didn’t know it was being mitigated in any way.
Do you have examples on environments that use PMPs in such a way? And if so, which PMPs? (I’m asking because if I can avoid UPnP and use the other more sane protocols, it’d still be a win)
Do you have examples on environments that use PMPs in such a way? And if so, which PMPs? (I’m asking because if I can avoid UPnP and use the other more sane protocols, it’d still be a win)
You should really read the article, because it covers every single point you just mentioned.
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.