1

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?

Improve this question
2
  • 1
    "does the dual external IP addresses mean that UDP hole punching will never be reliable?" UDP hole punching is never reliable in the first place.
    – Ron Maupin ♦
    Commented Jul 30, 2019 at 11:39
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin ♦
    Commented Dec 15, 2019 at 5:56

1 Answer 1

Reset to default
3

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)
Improve this answer
4
  • Thanks for the detailed reply. My understanding of what I've done (which obviously may well be incorrect!) was that when I connect to the broker, I would need to connect to it using the same external IP as when I connected to a peer. Eg, if I connect to the broker service using 1.2.3.4:5000, that informs my NAT that if it receives something back via that ip:port to send it back to my PC. However, if I then try to connect to a peer using a second external IP, say 5.6.7.8:2000, that is now a new connection, and so the hole punching won't work. Is that not correct?
    – Steve Hardingson
    Commented Jul 30, 2019 at 12:54
  • I should mention that this does work roughly 50% of the time, and I only see it not work when I see my software connect to the broker via a different IP, hence my suspicion here.
    – Steve Hardingson
    Commented Jul 30, 2019 at 12:55
  • @SteveHardingson You're not quite there: sending from A 1.2.3.4:5000 to broker:1000 makes the NAT router map inside 1.2.3.4:5000 to outside 2.3.4.5:6000 - that is sent to the broker. The broker then tells B to send to 2.3.4.5:6000 which the NAT router maps back to 1.2.3.4:5000 regardless - voilá. With restricted cone, that mapping is valid for the broker's IP only and you're out of luck.
    – Zac67 ♦
    Commented Jul 30, 2019 at 14:30
  • If that's the case, would I expect to see this working some of the time, but not others? Sounds like if that was the issue it would just not work at all? Is there any mechanism for determining what type of NAT I'm behind?
    – Steve Hardingson
    Commented Jul 30, 2019 at 15:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.