tinc - Feb 2012 - Automatic configuration of direct routes behind NAT

Hi,

I've followed the guide at:

http://blogs.operationaldynamics.com/andrew/software/research/using-tinc-vpn

and have a working tinc VPN. Here's my topology:

- CentralNode has a fixed public IP address that everyone connects to
- Leaf1 and Leaf2 may have different IP addresses depending on where
they are, and usually those will be behind NAT (think, two laptops
going around and you get the idea).

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

Is anything like this currently possible or planned?

Cheers,

Pedro

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

-- 
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/91cd8593/attachment.pgp>

On Wed, Feb 22, 2012 at 2:40 PM, Pedro C?rte-Real <pedro at pedrocr.net>
wrote:
> Hi,
>
> I've followed the guide at:
>
>
http://blogs.operationaldynamics.com/andrew/software/research/using-tinc-vpn
>
> and have a working tinc VPN. Here's my topology:
>
> - CentralNode has a fixed public IP address that everyone connects to
> - Leaf1 and Leaf2 may have different IP addresses depending on where
> they are, and usually those will be behind NAT (think, two laptops
> going around and you get the idea).
>
> 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? 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.
>
> Is anything like this currently possible or planned?
You could run tinc on top of UDP hole puncher, such as pwnat:

http://samy.pl/pwnat/
http://resources.infosecinstitute.com/udp-hole-punching/

But then you need to adapt your tinc config accordingly.

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

On Wed, Feb 22, 2012 at 7:04 PM, Pedro C?rte-Real <pedro at pedrocr.net>
wrote:
> On Wed, Feb 22, 2012 at 5:57 PM, Benjamin Henrion <bh at udev.org>
wrote:
>> Android does not have tun0/tap0 support, maybe Cyanogenmod.
>>
>> Or mayeb ICS 4.0 got tun support:
>>
>> http://code.google.com/p/android/issues/detail?id=24693
>>
>> I only have 2.x devices here, so I cannot test with 4.0.
>
> According to this:
>
> http://wiki.cyanogenmod.com/wiki/OpenVPN
>
> it seems cyanogenmod does indeed ship with tun built-in since v6.1,
> and having it be standard in 4.0 sounds great. tinc could potentially
> just be shipped as a market app than runs on boot and the builtin SIP
> client could then be configured with a tinc VPN IP for full
> integration.
Is there a special reason why you want to route the SIP traffic
through the Tinc vpn?

-- 
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."