[toast0]

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.

[zamadatix]

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.

[toast0]

Fair enough, I didn't go through the math. I don't think many NATs are realistically likely to let a single client run 64k sessions.

ISPs are increasingly putting customers behind CGNAT, so wireguard at home doesn't imply control over NAT policies. Especially new entrants and fixed wireless ISPs don't tend to have the resources to get an IP (v4) for every customer, and some of them don't offer v6 either, so having some form of hope would be nice.