3 ms·

Natural follow up question - does NAT traversal actually work? I've tried to replicate the NAT traversal paper[1] a couple of times in python, but it never rea

by devxpy 6y ago

Natural follow up question - does NAT traversal actually work? I've tried to replicate the NAT traversal paper[1] a couple of times in python, but it never really got it to work. Maybe my ISP's network topology just inlcudes multiple NATs which is messing things up. [1] https://bford.info/pub/net/p2pnat/ https://bford.info/pub/net/p2pnat/

dave_universetf 6y ago
author here. NAT traversal definitely still works, but it's very situational. I'd estimate the simple techniques get you successful p2p in 90% of cases, but those 90% are unevenly distributed: for a particular pair of endpoints, the success rate is either 100% or 0%, and it's little consolation to the 0% folks to know that they're the exception :) The paper you linked seems to have reasonably modern techniques for UDP traversal, so it should work. One thing that paper doesn't make clear, IMO, is that you need to STUN on both ends to discover your WAN ip:port, and you need to run the STUN traffic from the same socket as the one you're using for the NAT traversal. If you have Tailscale, you can run `tailscale netcheck` to characterize your network a little bit, which might give you some answers as to why the traversal doesn't work. Successful traversal depends on the properties of both endpoints, so you'd want to netcheck from both ends. The usual culprit is MappingVariesByDestIP=true, which indicates a hard NAT.
- devxpy 6y ago
  Thanks for the insider info. I didn't run a STUN server, but I exchanged the WAN ip:port via a server and some simple TCP messages.
apankrat 6y ago
Yes, it works quite well. Especially if the port prediction part is driven by a dedicated "rendezvous" server rather than delegated to the clients to do. This plus taking care of the long tail (weird NAT combos) and adding a TCP traversal as a fallback used to get you a success rate of 95-97%.

by devxpy 6y ago

dave_universetf 6y ago

author here. NAT traversal definitely still works, but it's very situational. I'd estimate the simple techniques get you successful p2p in 90% of cases, but those 90% are unevenly distributed: for a particular pair of endpoints, the success rate is either 100% or 0%, and it's little consolation to the 0% folks to know that they're the exception :) The paper you linked seems to have reasonably modern techniques for UDP traversal, so it should work. One thing that paper doesn't make clear, IMO, is that you need to STUN on both ends to discover your WAN ip:port, and you need to run the STUN traffic from the same socket as the one you're using for the NAT traversal. If you have Tailscale, you can run `tailscale netcheck` to characterize your network a little bit, which might give you some answers as to why the traversal doesn't work. Successful traversal depends on the properties of both endpoints, so you'd want to netcheck from both ends. The usual culprit is MappingVariesByDestIP=true, which indicates a hard NAT.

devxpy 6y ago
Thanks for the insider info. I didn't run a STUN server, but I exchanged the WAN ip:port via a server and some simple TCP messages.

apankrat 6y ago

Yes, it works quite well. Especially if the port prediction part is driven by a dedicated "rendezvous" server rather than delegated to the clients to do. This plus taking care of the long tail (weird NAT combos) and adding a TCP traversal as a fallback used to get you a success rate of 95-97%.