Automatic configuration of direct routes behind NAT

[Guus Sliepen]

On Wed, Feb 22, 2012 at 03:32:33PM +0000, Pedro Côrte-Real wrote:

> On Wed, Feb 22, 2012 at 2:28 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> > On Wed, Feb 22, 2012 at 01:40:20PM +0000, Pedro Côrte-Real wrote:
> > The current protocol does allow a client to send its own address to others.
> > However, perhaps it could detect that it is trying to connect to a node that,
> > as seen form CentralNode, has the same address as itself.
> 
> The simple algorithm I imagine is to just have the peers swap IP
> addresses through central node and see if they can just open a
> connection directly using those. This is simpler and more effective
> than figuring out if you're on the same subnet as that might not be
> the case and yet everything could still be routable (e.g., node A is
> on 10.0.0.1/24 and node B on 192.168.1.1/24 but they're actually two
> subnets of the same private installation).

I will see if it is possible to add something like this to the protocol in a
backwards-compatible way.

> > If they are not behind the same NAT, tinc does use a STUN-like technique to
> > allow the Leafs to talk to each other directly (if the NAT devices allow that).
> 
> I just read that this was added to 1.0.12. It seems the version that
> ships with the current Ubuntu LTS is 1.0.11 so I didn't have that
> update. Could you clarify what you mean by STUN-like and "if the NAT
> devices allow"? Why not just use STUN itself?

The STUN protocol, as defined in RFC5389, is meant to be used in a stand-alone
server, and is more complex than is necessary for tinc. The basic idea of STUN
is used though; a third node that is in communication with two other nodes
forwards the UDP address and port that the first one uses to the second, so the
second can connect back to that exact address/port combination. This requires
that the NAT device of the first node allows incoming packets from the second
node on that address/port combination, also knows as "cone NAT". For more
details, see http://en.wikipedia.org/wiki/Network_address_translation. Luckily,
most cheap ADSL routers implement cone NAT.

> Bringing it all together:
> 1- If Address fields are specified try those

This could indeed be added. At the moment, the Address field is only used when
making the initials connections defined by ConnectTo statements.

> 2- Try a direct connection to the IP address of the peer, reported
> through the CentralNode (pontentially a private IP behind NAT)

This needs support in the protocol.

> 3- Try a direct connection to the IP address of the peer as seen by
> CentralNode (as you suggested in case the router at the border
> forwards packets back)
> 4- Use STUN to allow connecting between two NATs
> 5- If all else fails and while the other stuff is happening just route
> everything through CentralNode

That is already in tinc.

> If I understood you correctly currently tinc does 1 and 5 obviously
> and a homegrown version of 4 but not 2 and 3.

Tinc does 3. 

-- 
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: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120222/2ae67c60/attachment.pgp>