Comment by crote
5 hours ago
Why not? Doesn't it depend on the type of NAT used?
As I understand it, most consumer devices will set up a port mapping which is completely independent of the destination's IP and port. It's just "incoming packet for $wanip:567 goes to $internal:123, outgoing packet from $internal:123 get rewritten to appear from $wanip:567". This allows any packet towards $wanip:567 to reach the internal host - both the original server the client initiated the connection to, and any other random host on the internet. Do this on two clients, have the server tell them each other's mappings, and they can do P2P comms: basic hole punching. I believe this is usually called "Full Cone NAT".
However, nothing is stopping you from setting up destination-dependent mapping, where it becomes "incoming packet from $server:443 to $wanip:456 goes to $internal:123, outgoing packet from $internal:123 to $server:443 gets rewritten to appear from $wanip:567". This would still work totally fine for regular client-to-server communication, but that mapping would only work for that specific server. A packet heading towards $wanip:456 would get dropped because the source isn't $server:443 - or it could even get forwarded to another host on the NATed network. This would block traditional hole punching. I believe this is called "Address Restricted Cone NAT" if it filters only on source IP, or "Port Restricted Cone NAT" if it filters on both source IP and source port.
If your NAT allows arbitrary connections out, and you're patient enough, you can probably finagle a peer to peer connection, eventually. Here's a discussion about that [1]. But that math is based on each NAT having a single external address; if your NAT spreads you over multiple addresses, the math gets much worse.
And there's a lot of other considerations; chances are your NAT won't be happy if you send all those probe packets at once, and your user may not be either. It's probably only worth it to do exhaustive probing if the connection is long lived, and proxying is expensive (in dollars because of bandwidth or in latency)
[1] https://github.com/danderson/nat-birthday-paradox/tree/maste...