8 ms·

How NAT Traversal Works (2020)

api 2y ago
Another year, another repost of an article about NAT traversal, another couple replies about how this is insecure followed by people explaining that NAT is not a security feature.
- Uptrenda 2y ago
  It will be year of P2P networking for realsies this time tho!
  - api 2y ago
    P2P is all over the place. It’s just largely invisible, part of the internals of games and VoIP and video chat apps among many other things.
- Hikikomori 2y ago
  It's like the Aragon broken toe of networking.
dfawcus 2y ago
(2020) Previous discussion: (2022) https://news.ycombinator.com/item?id=30707711 (2020) https://news.ycombinator.com/item?id=24241105
- normie3000 2y ago
  Thanks. Links aren't clickable. Maybe these will be: https://news.ycombinator.com/item?id=30707711 https://news.ycombinator.com/item?id=30707711 https://news.ycombinator.com/item?id=24241105 https://news.ycombinator.com/item?id=24241105
- dang 2y ago
  Thanks! Macroexpanded: How NAT traversal works (2020) - https://news.ycombinator.com/item?id=36969018 https://news.ycombinator.com/item?id=36969018 - Aug 2023 (106 comments) How NAT traversal works (2020) - https://news.ycombinator.com/item?id=30707711 https://news.ycombinator.com/item?id=30707711 - March 2022 (37 comments) How NAT Traversal Works - https://news.ycombinator.com/item?id=24241105 https://news.ycombinator.com/item?id=24241105 - Aug 2020 (28 comments) (p.s. your links weren't clickable because lines that are indented with 2 or more spaces get formatted as code - see https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc)
ocdnix 2y ago
Fascinatingly effective, but maybe I'm the only one getting the heebie-jeebies when someone suggests implementing this in production corp networks. Sure it's super convenient, but the thought of bypassing all traditional NATs and firewalls, and instead relying solely on a software ACL, seems super risky. Maybe I just don't understand how it works, but it seems that a bad actor getting access to a stray VM with Tailscale on it in, say, your AWS testing env, essentially has an clear path all the way into your laptop on the internal corp network, through the kernel, into user space and into the Tailscale ACL code as the sole arbiter of granting or blocking access. Would I even know someone unauthorized made it that far?
- devmor 2y ago
  That is a whole lot of different levels of exploits that would have to be chained together that you just trivialized there. How do you suppose they gained access to the kernel and userspace just by having a network connection to the laptop?
  - cyberpunk 2y ago
    I think the point is not that there are necessarily exploits, but by compromising one node in the tailnet they now have the ability to hit code in these locations, or services running on your tun0 interface on your laptop etc.
    - aborsy 2y ago
      You would typically remove the default any to any ACL rule, and allow the connections that you need. The compromised node normally would not have access to anything interesting. Normally it’s jailed, or would not be able to make outgoing connections. Am I missing something?
      - cyberpunk 2y ago
        The ACL logic happens in the tailscaled on the destination though doesn't it? So even if you block the access via the ACL the packet has still gone through the network stack and go runtime etc before the traffic is dropped which is a significantly bigger surface than a (traditional) external network firewall.
randunel 2y ago
I wish there was a tailscale-like equivalent without connectivity encryption, for devices which encrypt at the application layer (like almost the entire internet does). We don't always need the lower layers to be encrypted, this is especially computationally expensive for low power devices (think IoT stuff running a tailscale like tunnel). GRE tunnels exist and I actually use them extensively, but UDP hole punching is not handled so hub-and-spoke architecture is needed for them, no peer to peer meshes with GRE (ip fou). Are there equivalent libraries out there which do UDP hole punching and unencrypted GRE tunnels following an encrypted handshake to confirm identity?
- jamilbk 2y ago
  Yes, the established standard here is known collectively as Interactive Connectivity Establishment (ICE) [1] which WebRTC relies on -- there are a few good libraries out there that implement it and/or various elements of it [2] [3]. libp2p [4] may be what you're after if you want something geared more towards general purpose connectivity. [1] https://datatracker.ietf.org/doc/html/rfc8445 https://datatracker.ietf.org/doc/html/rfc8445 [2] https://github.com/pion/webrtc https://github.com/pion/webrtc [3] https://github.com/algesten/str0m https://github.com/algesten/str0m [4] https://libp2p.io https://libp2p.io
  - randunel 2y ago
    Thank you for the resources! I will study them. FWIW, libp2p also enforces transport encryption, quote: > Encryption is an important part of communicating on the libp2p network. Every connection must be encrypted to help ensure security for everyone. As such, Connection Encryption (Crypto) is a required component of libp2p.
- Muromec 2y ago
  Turn, stun, ice is what does hole punching for voip, so you can reuse libraries from voip for that
- Uptrenda 2y ago
  It's not UDP but I do TCP hole punching here: https://github.com/robertsdotpm/p2pd https://github.com/robertsdotpm/p2pd and every other major method of NAT traversal. It's written in Python. Though its not based on using the default interface like most networking code. I wanted the possibility to be able to run services across whatever interfaces you like. Allowing for much more diverse and useful things to be built. Its mostly based on standard library modules. I hate C extension crap as it always breaks packages cross-platform.
michidk 2y ago
Such a great explanation. Wish I would have had something like this back in my gamedev days.
zerox7felf 2y ago
> So, to traverse these multiple stateful firewalls, we need to share some information to get underway: the peers have to know in advance the ip:port their counterpart is using. > [...] To move beyond that, we built a coordination server to keep the ip:port information synchronized This is where I wish SIP lived up to its name (Session Initiation Protocol, i.e. any session, such as a VPN one...) and wasn't such a complicated mess making it not worth the hassle. I mean it was made to be the communication side-channel used for establishing p2p rtp streams.
- Muromec 2y ago
  Yeah, sip is doing so many things that its scary to load all them in your head at the same time. Its like http, but its also statefull, bidirectional, federated and works over udp too. Just looking at the amount of stuff (tls over udp included) baresip implements to barely sip. And it isnt even bloated, the stuff has to be there.
  - rixed 2y ago
    > Its like http and for the same reason: both were initialy designed to be simple...
dennis-tra 2y ago
This is an excellent article! The tribal knowledge seems to be that you shouldn't do TCP-based hole punching because it's harder than UDP. The author acknowledges this: > You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go. However, I only see marginally added complexity (given the already complex UDP flows). IMO this complexity doesn't justify discarding TCP hole punching altogether. In the article you could replace raw UDP packets to initiate a connection with TCP SYN packets plus support for "simultaneous open" [0]. This is especially true if networks block UDP traffic which is also acknowledged: > For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic. My point is that many articles gloss over TCP hole punching with the excuse of being harder than UDP while I would argue that it's almost equally feasible with marginal added complexity. [0] https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcp...
- dfawcus 2y ago
  The existence of stateful firewalls, and the fact that most NAT filters are EDF rather than EIF means that simultaneous open (send) is necessary even for UDP. Hence the added complexity of doing a simultaneous open via TCP is fairly minor. The main complication is communicating the public mapping, and coordinating the "simultaneous" punch/open. However that is generally needed for UDP anyway... One possible added complexity with TCP is one has to perform real connect() calls, rather than fake up the TCP SYN packet. That is becase some firewalls pay attention to the sequence numbers.
  - LegionMammal978 2y ago
    Yeah, I've gotten somewhat annoyed by the name of 'NAT traversal' for these methods. It seems to make some people think that cutting out NAT will lead to a beautiful world of universal P2P connections. But really, these methods are needed for traversing between any two networks behind stateful firewalls, which will pose a barrier to P2P indefinitely. Also, wouldn't it be easier for stateful firewalls to block simultaneous TCP open (intentionally or not)? With UDP, the sender's firewall must create a connection as soon as it sends off the first packet, even if that packet bounces off the other firewall: the timing doesn't have to be particularly tight. But with TCP, the firewall might plausibly wait until the handshake is complete before allowing incoming packets, and it might only allow the 3-way SYN/SYN-ACK/ACK instead of the simultaneous SYN/SYN/ACK/ACK.
binary132 2y ago
Really clear and clean exposition on what can be a hairy and badly-discussed subject, thanks for posting!
vinay_ys 2y ago
Interesting blast from the past. We built an oblivious p2p mesh network that did this in 2010. Back then, nobody cared about security as much as we thought they should. Since then, nobody still cares about security as much as they should. Devices have increased and their value has increased, and still, they are quite insecure. Truly secure endpoints with hardware root-of-trust and secure chains of trust for authn/authz and minimal temporary privileges is still hard, and network perimeter security theater is still ongoing in home networks, corp networks and even large production datacenter networks. Only reason we don't find these to be the primary root-cause for security breaches is because more easier attack chains are still easily available!
apitman 2y ago
This is the article I sent people to for NAT traversal This may be the only way we ever have to build p2p apps. IPv6 doesn't have enough steam since NAT and SNI routing solve most problems for most people. And ISPs are very much not incentivized for that to change.
Uptrenda 2y ago
IMO: this is arguably one of the most detailed articles on NAT traversal on the entire Internet. But it is missing information on delta behaviors (its not that complex -- just that some NATs have observable patterns in how they choose to assign successive external ports. The most common one is simply preserving the source port. But there can also be others, e.g. an increment of the former mapping.) It's a very good theoretical article. I wonder to what extent a software engineer could use this though. Because although it does describe many things I'm not sure there's enough detail to write algorithms for it. Like, could an engineer wrote an algorithm to test for different types of NATs on the basis of this article? Could they adapt their own hole punching code? I've personally read papers where simple tables were more useful than entire articles like this (as extensive as it is.) Maybe still a good starting point though. Also, the last section in the article is extremely relevant. It has the potential to bypass symmetric NATs which are used in the mobile system. The latest research on NAT traversal uses similar techniques and claims near 100% success rates.
deleted 2y ago
[deleted]
boredatoms 2y ago
It really shows how much we need ipv6 gua addresses everywhere
yyyfb 2y ago
The fact that this emerged instead of IPv6 is a true testament to the power of "good enough hackery"
snthpy 2y ago
A bit OT: A read a bit about this space a few weeks ago after not knowing anything about it beforehand. My impression is that ip6 dices all of this and NAT traversal isn't necessary anymore. So why isn't ip6 more popular and how do I get started with it for my home network and tailscale VPN?
- drio 2y ago
  > why isn't ip6 more popular Not sure how much of a factor but human usability has always been challenging. There is also the lack of business incentives.

api 2y ago

Another year, another repost of an article about NAT traversal, another couple replies about how this is insecure followed by people explaining that NAT is not a security feature.

Uptrenda 2y ago
It will be year of P2P networking for realsies this time tho!
- api 2y ago
  P2P is all over the place. It’s just largely invisible, part of the internals of games and VoIP and video chat apps among many other things.
Hikikomori 2y ago
It's like the Aragon broken toe of networking.

dfawcus 2y ago

(2020) Previous discussion: (2022) https://news.ycombinator.com/item?id=30707711 (2020) https://news.ycombinator.com/item?id=24241105

normie3000 2y ago
Thanks. Links aren't clickable. Maybe these will be: https://news.ycombinator.com/item?id=30707711 https://news.ycombinator.com/item?id=30707711 https://news.ycombinator.com/item?id=24241105 https://news.ycombinator.com/item?id=24241105
dang 2y ago
Thanks! Macroexpanded: How NAT traversal works (2020) - https://news.ycombinator.com/item?id=36969018 https://news.ycombinator.com/item?id=36969018 - Aug 2023 (106 comments) How NAT traversal works (2020) - https://news.ycombinator.com/item?id=30707711 https://news.ycombinator.com/item?id=30707711 - March 2022 (37 comments) How NAT Traversal Works - https://news.ycombinator.com/item?id=24241105 https://news.ycombinator.com/item?id=24241105 - Aug 2020 (28 comments) (p.s. your links weren't clickable because lines that are indented with 2 or more spaces get formatted as code - see https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc)

ocdnix 2y ago

Fascinatingly effective, but maybe I'm the only one getting the heebie-jeebies when someone suggests implementing this in production corp networks. Sure it's super convenient, but the thought of bypassing all traditional NATs and firewalls, and instead relying solely on a software ACL, seems super risky. Maybe I just don't understand how it works, but it seems that a bad actor getting access to a stray VM with Tailscale on it in, say, your AWS testing env, essentially has an clear path all the way into your laptop on the internal corp network, through the kernel, into user space and into the Tailscale ACL code as the sole arbiter of granting or blocking access. Would I even know someone unauthorized made it that far?

devmor 2y ago
That is a whole lot of different levels of exploits that would have to be chained together that you just trivialized there. How do you suppose they gained access to the kernel and userspace just by having a network connection to the laptop?
- cyberpunk 2y ago
  I think the point is not that there are necessarily exploits, but by compromising one node in the tailnet they now have the ability to hit code in these locations, or services running on your tun0 interface on your laptop etc.
  - aborsy 2y ago
    You would typically remove the default any to any ACL rule, and allow the connections that you need. The compromised node normally would not have access to anything interesting. Normally it’s jailed, or would not be able to make outgoing connections. Am I missing something?
    - cyberpunk 2y ago
      The ACL logic happens in the tailscaled on the destination though doesn't it? So even if you block the access via the ACL the packet has still gone through the network stack and go runtime etc before the traffic is dropped which is a significantly bigger surface than a (traditional) external network firewall.

randunel 2y ago

I wish there was a tailscale-like equivalent without connectivity encryption, for devices which encrypt at the application layer (like almost the entire internet does). We don't always need the lower layers to be encrypted, this is especially computationally expensive for low power devices (think IoT stuff running a tailscale like tunnel). GRE tunnels exist and I actually use them extensively, but UDP hole punching is not handled so hub-and-spoke architecture is needed for them, no peer to peer meshes with GRE (ip fou). Are there equivalent libraries out there which do UDP hole punching and unencrypted GRE tunnels following an encrypted handshake to confirm identity?

jamilbk 2y ago
Yes, the established standard here is known collectively as Interactive Connectivity Establishment (ICE) [1] which WebRTC relies on -- there are a few good libraries out there that implement it and/or various elements of it [2] [3]. libp2p [4] may be what you're after if you want something geared more towards general purpose connectivity. [1] https://datatracker.ietf.org/doc/html/rfc8445 https://datatracker.ietf.org/doc/html/rfc8445 [2] https://github.com/pion/webrtc https://github.com/pion/webrtc [3] https://github.com/algesten/str0m https://github.com/algesten/str0m [4] https://libp2p.io https://libp2p.io
- randunel 2y ago
  Thank you for the resources! I will study them. FWIW, libp2p also enforces transport encryption, quote: > Encryption is an important part of communicating on the libp2p network. Every connection must be encrypted to help ensure security for everyone. As such, Connection Encryption (Crypto) is a required component of libp2p.
Muromec 2y ago
Turn, stun, ice is what does hole punching for voip, so you can reuse libraries from voip for that
Uptrenda 2y ago
It's not UDP but I do TCP hole punching here: https://github.com/robertsdotpm/p2pd https://github.com/robertsdotpm/p2pd and every other major method of NAT traversal. It's written in Python. Though its not based on using the default interface like most networking code. I wanted the possibility to be able to run services across whatever interfaces you like. Allowing for much more diverse and useful things to be built. Its mostly based on standard library modules. I hate C extension crap as it always breaks packages cross-platform.

michidk 2y ago

Such a great explanation. Wish I would have had something like this back in my gamedev days.

zerox7felf 2y ago

> So, to traverse these multiple stateful firewalls, we need to share some information to get underway: the peers have to know in advance the ip:port their counterpart is using. > [...] To move beyond that, we built a coordination server to keep the ip:port information synchronized This is where I wish SIP lived up to its name (Session Initiation Protocol, i.e. any session, such as a VPN one...) and wasn't such a complicated mess making it not worth the hassle. I mean it was made to be the communication side-channel used for establishing p2p rtp streams.

Muromec 2y ago
Yeah, sip is doing so many things that its scary to load all them in your head at the same time. Its like http, but its also statefull, bidirectional, federated and works over udp too. Just looking at the amount of stuff (tls over udp included) baresip implements to barely sip. And it isnt even bloated, the stuff has to be there.
- rixed 2y ago
  > Its like http and for the same reason: both were initialy designed to be simple...

dennis-tra 2y ago

This is an excellent article! The tribal knowledge seems to be that you shouldn't do TCP-based hole punching because it's harder than UDP. The author acknowledges this: > You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go. However, I only see marginally added complexity (given the already complex UDP flows). IMO this complexity doesn't justify discarding TCP hole punching altogether. In the article you could replace raw UDP packets to initiate a connection with TCP SYN packets plus support for "simultaneous open" [0]. This is especially true if networks block UDP traffic which is also acknowledged: > For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic. My point is that many articles gloss over TCP hole punching with the excuse of being harder than UDP while I would argue that it's almost equally feasible with marginal added complexity. [0] https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcpstate.html https://ttcplinux.sourceforge.net/documents/one/tcpstate/tcp...

dfawcus 2y ago
The existence of stateful firewalls, and the fact that most NAT filters are EDF rather than EIF means that simultaneous open (send) is necessary even for UDP. Hence the added complexity of doing a simultaneous open via TCP is fairly minor. The main complication is communicating the public mapping, and coordinating the "simultaneous" punch/open. However that is generally needed for UDP anyway... One possible added complexity with TCP is one has to perform real connect() calls, rather than fake up the TCP SYN packet. That is becase some firewalls pay attention to the sequence numbers.
- LegionMammal978 2y ago
  Yeah, I've gotten somewhat annoyed by the name of 'NAT traversal' for these methods. It seems to make some people think that cutting out NAT will lead to a beautiful world of universal P2P connections. But really, these methods are needed for traversing between any two networks behind stateful firewalls, which will pose a barrier to P2P indefinitely. Also, wouldn't it be easier for stateful firewalls to block simultaneous TCP open (intentionally or not)? With UDP, the sender's firewall must create a connection as soon as it sends off the first packet, even if that packet bounces off the other firewall: the timing doesn't have to be particularly tight. But with TCP, the firewall might plausibly wait until the handshake is complete before allowing incoming packets, and it might only allow the 3-way SYN/SYN-ACK/ACK instead of the simultaneous SYN/SYN/ACK/ACK.

binary132 2y ago

Really clear and clean exposition on what can be a hairy and badly-discussed subject, thanks for posting!

vinay_ys 2y ago

Interesting blast from the past. We built an oblivious p2p mesh network that did this in 2010. Back then, nobody cared about security as much as we thought they should. Since then, nobody still cares about security as much as they should. Devices have increased and their value has increased, and still, they are quite insecure. Truly secure endpoints with hardware root-of-trust and secure chains of trust for authn/authz and minimal temporary privileges is still hard, and network perimeter security theater is still ongoing in home networks, corp networks and even large production datacenter networks. Only reason we don't find these to be the primary root-cause for security breaches is because more easier attack chains are still easily available!

apitman 2y ago

This is the article I sent people to for NAT traversal This may be the only way we ever have to build p2p apps. IPv6 doesn't have enough steam since NAT and SNI routing solve most problems for most people. And ISPs are very much not incentivized for that to change.

Uptrenda 2y ago

IMO: this is arguably one of the most detailed articles on NAT traversal on the entire Internet. But it is missing information on delta behaviors (its not that complex -- just that some NATs have observable patterns in how they choose to assign successive external ports. The most common one is simply preserving the source port. But there can also be others, e.g. an increment of the former mapping.) It's a very good theoretical article. I wonder to what extent a software engineer could use this though. Because although it does describe many things I'm not sure there's enough detail to write algorithms for it. Like, could an engineer wrote an algorithm to test for different types of NATs on the basis of this article? Could they adapt their own hole punching code? I've personally read papers where simple tables were more useful than entire articles like this (as extensive as it is.) Maybe still a good starting point though. Also, the last section in the article is extremely relevant. It has the potential to bypass symmetric NATs which are used in the mobile system. The latest research on NAT traversal uses similar techniques and claims near 100% success rates.

deleted 2y ago

[deleted]

boredatoms 2y ago

It really shows how much we need ipv6 gua addresses everywhere

yyyfb 2y ago

The fact that this emerged instead of IPv6 is a true testament to the power of "good enough hackery"

snthpy 2y ago

A bit OT: A read a bit about this space a few weeks ago after not knowing anything about it beforehand. My impression is that ip6 dices all of this and NAT traversal isn't necessary anymore. So why isn't ip6 more popular and how do I get started with it for my home network and tailscale VPN?

drio 2y ago
> why isn't ip6 more popular Not sure how much of a factor but human usability has always been challenging. There is also the lack of business incentives.