Automatic configuration of direct routes behind NAT

[Andrew Cowie]

On Wed, 2012-02-22 at 15:28 +0100, Guus Sliepen wrote:
> On Wed, Feb 22, 2012 at 01:40:20PM +0000, Pedro Côrte-Real wrote:
> 
> > I setup Leaf1 and Leaf2 to connect to CentralNode and they both do and
> > everyone can talk to everyone.
> > 
> > However, when both Leaf's are behind the same NAT it would be nice if
> > they were able to figure that out and not have to go through
> > CentralNode for everything. Since the IP addresses are always changing
> > I can't configure an Address option. Is tinc able to just try and use
> > whatever is the current IP address of the two hosts and see if it can
> > communicate?
> 
> 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.
> 
> 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).

As far as I can tell, the ICE protocol as used by Empathy to get a
Jingle audio or video call going simply transmits the addresses of *all*
local addresses. The the other side decides which has the lowest metric
(sic) cost, and of course if they are on the same subnet (ie tinc!) then
that's what they pick.

Perhaps tinc could do something analogous? If I advertise that I'm on
192.168.90.x and you are on 192.168.90.x then it's probably worth a shot
at attempting a direct connection. Sure it might not work (for not the
least reason that you might have conflicting overlapping private address
spaces on two actually remote clients) but mightn't it be easier than
e.g. braodcasting (which is very much limited to local segment only).

AfC
Sydney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120311/ba35fd68/attachment.pgp>