Automatic configuration of direct routes behind NAT
Pedro Côrte-Real
pedro at pedrocr.net
Sat Mar 10 23:20:34 CET 2012
On Wed, Feb 22, 2012 at 10:32 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> I just committed local node discovery support to the git repository. It is a
> simplified version of Daniel Schall's idea, and basically just adds some
> broadcast packets to the PMTU discovery phase. If another node on the same LAN
> sees those, it will pick up the LAN IP address of the first node and will use
> that for further communication.
>
> Get it from http://tinc-vpn.org/repository/, read the README.git, compile, and
> add "LocalDiscovery = yes" to tinc.conf to enable this feature.
>
> I have tested it locally and it works fine. In fact, only one of the nodes on
> the LAN needs to support this, and no support from a third node is necessary.
> On the other hand, it doesn't work with more complicated network situations.
I've just had some time to finally pick that up, build some packages
and quickly deploy it. My results are pretty much in line with what
you mentioned.
My setup was:
- One CentralNode with a public Internet IP
- Two ServerNodes behind the same NAT (same LAN)
- One LeafNode behind a NAT that's also behind the first NAT (It's
just a virtualbox instance running on a computer that's on the same
LAN)
The result was:
1- The two ServerNodes connected to each other fine and pings went for
>200ms to <1ms. Great!
2- I didn't do extensive testing but it seemed I was only able to get
it to work once I enabled the feature on both ServerNodes and
restarted tinc on both
3- LeafNode still had to route through CentralNode since it doesn't
get any broadcast packets from the LAN
All in all a great outcome. Point 3 is the only sticking point and
would be solved by my suggestion of having CentralNode tell LeafNode
what it's IP is and having LeafNode connect to that. This way you'd
stop relying on everyone getting broadcast packets, which fails when
the network topology is a little less straightforward (e.g., two
subnets fully routable between each other, and behind the same NAT).
Cheers,
Pedro
More information about the tinc
mailing list