Questions on how hole punching works

[mikedilger]

I'm working on a nostr successor protocol and the idea of not having servers has come up multiple times but I've always been skeptical of hole punching. So I've come here to be educated. I can't make great decisions without having deeper knowledge. Can someone explain how hole punching works? In particular...

If two NAT-bound clients connect to a rendezvous server on the Internet, and that rendezvous server shares with each client every single thing it knows about them (including especially how it is communicating back to them), this still does not seem sufficient for a NAT gateway to accept packets into this established NAT mapping from a different IP source address. Why wouldn't NAT gateways drop such packets when the source address changes from what they were expecting?

I did a test with Iroh a while back and it was going through one of your relays. So I guess I fell into the 10% that fail. So I'm also wondering under what conditions hole punching fails.

[matheus23]

If two NAT-bound clients connect to a rendezvous server on the Internet, and that rendezvous server shares with each client every single thing it knows about them (including especially how it is communicating back to them), this still does not seem sufficient for a NAT gateway to accept packets into this established NAT mapping from a different IP source address. Why wouldn't NAT gateways drop such packets when the source address changes from what they were expecting?

Some do. Some don't.
Well, NATs are just translations, but they're pretty much always combined with stateful firewalls. When these firewalls see that some IP:port starts communicating with the outside, they'll open up the firewall for receiving packets that are directed at IP:port, independent on which original destination the machine behind the firewall originally talked through.
If they didn't do this, I think this breaks load balancing in some cases, where a machine would first dial the load balancer, but then it's another IP addr that actually answers. You can see how we can use this behavior to our advantage, where the relay is essentially the "load balancer" and the other peer is "the machine that actually answers".

But as I said, not all stateful firewall + NATs work this way. Some actually restrict incoming packets to only come from a specific IP addr, we've seen those in the past. I like to call these "Endpoint-dependent stateful firewalls", but most people prefer calling those "symmetric NATs", I think.

I did a test with Iroh a while back and it was going through one of your relays. So I guess I fell into the 10% that fail. So I'm also wondering under what conditions hole punching fails.

If you did a test with iroh and it failed it can be due to other issues: Some networks filter out UDP packets entirely (or any UDP traffic that doesn't look like DNS), or any traffic that doesn't look exactly like "super normal HTTP/1.1", which is why this the protocol we use over the relay.

It could also be due to a bug :) Hard to say though without more information.

[mikedilger]

That helps. Thanks.