[dfawcus]

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]

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.

[spacechild1]

> But really, these methods are needed for traversing between any two networks behind stateful firewalls, which will pose a barrier to P2P indefinitely.

That's true. The actual problem are symmetric NATs where every peer sees a different port number. This makes traditional NAT-traversal impossible and you have to resort to port guessing/scanning. See for example https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

[ffsm8]

People honestly thought for a while that devices behind a NAT were secured unless ports were specifically routed to them, hence the term "nat hole punching" was coined.

You're probably right that it makes less sense from today's perspective

[tjoff]

Doesn't make sense. NAT hole punching requires you to execute on the target inside the NAT.

If you are able to do that whatever security you got from NAT has been breached even before NAT hole punching enters the conversation.

NAT will block unsolicited incoming connections, that is a great boon for security but obviously not a silver bullet for all network related security issues nor outgoing connections. That has never been a trope.

[ffsm8]

> Doesn't make sense. NAT hole punching requires you to execute on the target inside the NAT.

Why doesn't it make sense to you? From my perspective the idea was that the NAT protects your devices - and your device is now punching a hole into this protection, making it vulnerable to the world wide web

This circumventing doesn't have to be done by a malicious actor, it just comes at the added risk of becoming "targetable" from the Internet

[tjoff]

Because it is the same thing as opening an outgoing connection but with more steps. The only thing it allows is to connect to someone else that is also behind NAT.

It has no bearing on security.

[ffsm8]

By this logic, a firewall has no bearing on security either. It just drops packets / makes devices unadressable unless a route has been allowed/ a port has been opened