On 12 November 2015 at 22:23, Guus Sliepen <[email protected]> wrote: > On Thu, Nov 12, 2015 at 10:05:19PM +0000, Etienne Dechamps wrote: > >> My best guess is that it's simply a direct application of >> probabilities: if the probability that a NAT is "compliant" is 70%, >> then the probability that *both* NATs at both ends of the tunnel are >> "compliant" is only 50% (0.70*0.70). Indeed both NATs need to be >> compliant in order for UDP hole punching to work. > > That's not true, full cone or address restricted NAT can still > communicate with a symmetric NAT. It's only port restricted NAT that > cannot communicate with symmetric NAT. So in the second graph, it's > PAR-SYM and SYM-SYM that don't work, the rest do.
Ah, yes, indeed. That's because as long as the other (non-symmetric) NAT doesn't have constraints on the source port of incoming packets, it will still correctly forward packets from a symmetric NAT with previously unseen source ports. tinc will then be able to reconstruct the correct port from the source port of the incoming packet, and talk back through the symmetric NAT's mapping. Got it. What a mess though... the headaches are killing me! _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
