Nat – Is UDP Hole Punching possible if the network of one peer has multiple external IP addresses

nat;udp

I've developed an implementation for UDP hole punching that works for most use cases that I've come across. However, one of our offices has a network configuration where we have two ISPs providing us with internet for redundancy. This is set up to load balance between the two lines, so that whenever you make an outbound connection to something, it's pot luck which line you make that connection on. Obviously each line has its own external IP address, and my software has no knowledge of what that address is, or which it's using.

I believe this is stopping UDP hole punching from working. I connect to the known connection server that I'm running on AWS via one IP address, but when my software is told to connect to a peer somewhere else in the world, it may try and connect to that peer on the same IP as it did to the connection server, or it may use the other one, in which case it won't connect.

Is there a solution to this, or does the dual external IP addresses mean that UDP hole punching will never be reliable?

Best Answer

UDP hole punching works by an external broker service passing back the NATed public IP:port combinations to the actual communicating parties. Those combinations are the ones that are actually used, so yes, it should also work when a NAT router uses a public IP pool instead of a single IP.

However, UDP hole punching can't work if one or both NAT routers use restricted cone NAT. With that, the source IP:port is checked on inbound NAT, and when it doesn't match the establishing parameters the packet is dropped. Likely, this is what you're seeing.

UDP hole punching can be used in a 'known' environment. In an ad-hoc scenario it's a matter of luck and far from reliable. With older routers it might mostly work but no so much with newer ones with stricter security. Chances are, things get worse for you over time.

There are various solutions for your problem, most prominently:

  • VPN (pro: best overall approach, con: most demanding setup)
  • configured port forwarding (destination NAT; pro: low effort, con: each p2p link requires separate handling)
  • a centralized, active broker service that relays the communication (pro: little to no effort on the user side, con: requires external service and integration into application protocol)
Related Topic