UPnP support in tinc

[Etienne Dechamps]

On 12 November 2015 at 21:29, Guus Sliepen <guus at tinc-vpn.org> wrote:
> On Wed, Nov 11, 2015 at 09:04:20PM +0000, Etienne Dechamps wrote:
>> According to an online NAT check service, around 50% of NATs in the
>> wild have this problem, making this a very real issue:
>> http://nattest.net.in.tum.de/results.php
>
> Are you referring to port restricted NAT in the first graph? Because
> that should still work with tinc. Symmetric NAT looks like 15% or so,
> and if you include everything to the right of it, it comes to 35% or so.

Hmm. Well I was only looking at the third graph, which presents a
simplified view where "UDP hole punching" only works in 50% of cases,
which is the number I pulled. To be honest I am not quite sure how
that follows from the first or second graph.

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.

However, that indeed means that my original post was badly worded - I
should have said "50% of *cases*" not "50% of NATs". My bad.

> What is more interesting is the last graph: tinc does UDP hole punching
> but not UPnP (yet), the difference between the first two bars is about
> 10%. Not unworthwile.

It is especially worthwhile if you consider that UPnP makes you
reachable not only if your NAT is making things difficult, but also if
the NAT of *the other side* is making things difficult, too. UPnP is
basically a "get out of jail free" card that makes you look exactly
like a publicly addressable node, which means you can establish direct
communication with anyone even if they themselves don't have the
luxury of sitting behind a "good" NAT. That makes it very useful IMHO
(in fact it makes it even more useful than fixing the user's NAT). I'm
not sure if the graph takes that fact into account - I would have
expected way more than a 10% difference if that was the case.

> Of course if there is a lightweight,
> cross-platform library that is easy to integrate we should have a look
> at that. If that can be done with MiniUPnP, go ahead.

Understood. I'll get busy this week-end :)

> As for dependencies: it should be possible to disable support for UPnP
> for those who want to build a minimal version of tinc. As for threads,
> tinc 1.0.x on Windows already uses threads (as you should know) without
> using libpthread. If UPnP can be integrated by just using CreateThread()
> and maybe Enter/LeaveCriticalSection(), I'd use that and avoid the whole
> issue of libpthread.

Okay.

> NAT-PMP (and PCP?) seems interesting to, maybe it is simple enough to
> code directly into tinc?

Well, the author of miniupnpc also wrote libnatpmp, which apparently
*is* specifically designed to be integrated into an event loop:
http://miniupnp.free.fr/libnatpmp.html