On 12 November 2015 at 21:29, Guus Sliepen <[email protected]> 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 _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
