Automatic configuration of direct routes behind NAT

[Pedro Côrte-Real]

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).

This would work for situations without NAT at all as well. If you have
three peers all with public IP addresses and configure them this way,
the two leaves will figure out they can just talk with one another
without any Address fields in their configuration. This would be
useful for hosts that have dynamic ip addresses, making it hard to
specify a proper Address.

> At the end of 2010 year two ways to deal with this were proposed, one by Daniel
> Schall and one by me, but nothing happened. In the last months there apparently
> has been an increased interest in a way for tinc to detect local peers, so I
> will try to get this merged before the next release.
>
>> If they're behind the same NAT it would work and if not
>> it would just continue to go back and forth to CentralNode. In that
>> situation it would ideally use something like STUN so it could do away
>> with the central node even when both hosts are behind two different
>> NATs.
>
> 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?

Bringing it all together:
1- If Address fields are specified try those
2- Try a direct connection to the IP address of the peer, reported
through the CentralNode (pontentially a private IP behind NAT)
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

If I understood you correctly currently tinc does 1 and 5 obviously
and a homegrown version of 4 but not 2 and 3. For me 2 is the
low-hanging fruit and I'll have to try a newer version to see if the
homegrown STUN works for me.

Thanks for the reply,

Pedro