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