Comment by toast0
2 days ago
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...
The feasibility of this assumes one peer is always behind an endpoint dependent mapping. That's great if you only care about peers working with you and you control your style of NAT, but it's still pretty broken for the case you want this to work for any 2 peers. In practical terms, the success rate goes from something like the 64% with 256 probes down to something less than 0.01%.
If you can manage to bump it up to 65536 probes without getting blocked, hitting a NAT limit, or causing the user to fall asleep waiting, then it should hit the same success rate :D. I'm not sure many would like to use that P2P service though, at that point just pay for the TURN server.
64k probes is a lot, but it might be reasonable if you're trying to get something like wireguard connected between locations that are behind CGNAT, send 10 probes a second for a couple hours and then remain connected for a long time. Of course, CGNAT might split your traffic over multiple IPs and then the math is terrible.
If you need to send 64k probes to get p2p and you want to make a 15 minute call, it probably doesn't make sense, but it's probably worth trying a bit in case you catch an easy case. Not that p2p is always better than going through a relay, but it's often less expensive.
The math doesn't quite work that conveniently in that at least one side needs to actually initiate (and keepalive) 65k sessions through their NAT while the other tests 10 of those ports at a time. If you just do 10 at a time both sides until you've done 65k total you end up with even worse odds than having just done 256 at once, due to the Birthday Paradox nature of the problem.
For wireguard that might be fine because you likely control the head end and opening ~65k NAT sessions is something you can opt to do if you tune things accordingly. Of course, in that case, you can also just opt to use the more lenient form of NAT at your head end and just use attempt with 256 ports instead.
1 reply →