UPnP support in tinc

Etienne Dechamps etienne at edechamps.fr
Fri Nov 13 01:14:27 CET 2015


On 12 November 2015 at 22:23, Guus Sliepen <guus at tinc-vpn.org> 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!


More information about the tinc mailing list