UPnP support in tinc

[Guus Sliepen]

On Wed, Nov 11, 2015 at 09:04:20PM +0000, Etienne Dechamps wrote:

> Unfortunately, I often notice that even with the advanced UDP hole
> punching mechanisms that tinc uses, I still come across cases on my
> network where two nodes behind NATs cannot talk to each other because
> one of the nodes is behind a "strict" NAT [...]. This type of NAT
> will stop any UDP hole punching attempt dead in its tracks, and
> there's nothing we can do about it.
> 
> 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.

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.

> A Google search for "pf cone nat" returns somewhat depressing results:
> apparently it's not even possible to configure pf to act as an
> EIM-NAT, and people asking for such an option are basically being told
> to go away with demonstrably weak security-related arguments (which
> can easily be debunked by pointing out that NATs and firewalls have
> different goals, and that providing endpoint-independent mapping does
> not preclude endpoint-dependent *filtering*, which would still allow
> UDP hole punching to work).

Yes, and they are not RFC 4787 compliant.

> The only way we can try to get through EDM-NATs is by using UPnP-IGD,
> which tinc could use to explicitly open its UDP port on the NAT. This
> should pretty much fix the issue with home routers since most of them
> support UPnP (for example the aforementioned ZTE router does). As a
> bonus, if we also use UPnP to open the TCP metaconnection port, it
> could even allow AutoConnect to work between nodes behind NATs, which
> would be quite nice.

Indeed. (That reminds me, I have to do something similar with the SOCKS
proxy code, as it also support opening listening ports.)

> Now, the reason why this is not already a pull request is because
> bringing UPnP support to tinc is more complicated than it sounds. I
> could only find one UPnP library that can be qualified as
> "lightweight" (i.e. doesn't require ridiculous dependencies like XML
> libraries), that's miniupnpc: http://miniupnp.free.fr/ Here's the
> catch: miniupnpc only provides a blocking API, there is no way to
> integrate it into an event loop. That pretty much means we will need
> to run the UPnP code in a separate thread. Which means using pthreads
> on POSIX, and then we would either have a dependency on pthreads-Win32
> on Windows, or we would need to #ifdef Win32 thread code in.

When I started looking at NAT traversal support for tinc, there were
several libraries, but all of them quite large, some larger than tinc
itself, and it was indeed difficult to integrate them into tinc's event
loop. Since a STUN-like protocol was easy to implement in tinc itself, I
opted for that solution. 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.

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.

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

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20151112/30644838/attachment.sig>