LAN discovery issue

[Guus Sliepen]

On Thu, Dec 06, 2012 at 02:04:54PM +0100, Markus Teufelberger wrote:

> host files:
> Alpha
> *******************
> Subnet = [single IP]/32
> IndirectData = yes

Remove the IndirectData statement from all the host config files. With recent
versions of tinc, it is not necessary to use this option if you are behind a
NAT or firewall, and it will actually prevent direct exchange of packets
between Beta and Gamma in your scenario.

> Beta and Gamma are set to ConnectTo Alpha, Alpha itself doesn't
> ConnectTo anyone. Beta currently has Alpha's LAN IP written in the
> host file of Alpha, since Beta is unlikely to be moved outside the
> LAN.
> 
> I have the following problem:
> Pinging Alpha's VPN IP from Beta gives great LAN times of ~1 ms.
> Pinging Beta's VPN IP from Alpha too.
> However:
> Pinging Alpha's VPN IP from Gamma gives all sorts of weird timings,
> sometimes up to 2+ seconds, sometimes down to less than 10 ms.

Hm, that is strange, with LocalDiscovery enabled it should after a while be in
the same range as the latency between Alpha and Beta.

> Pinging Beta's VPN IP from Gamma (remember, Gamma only ConnectsTo
> Alpha) seems to be settling down at 4 ms with some ~200ms hickups
> inbetween and at the beginning.

4 ms sounds reasonable, given that you are using IndirectData and packets
between Beta and Gamma will therefore be routed via Alpha.

Note that when you ping for the first time after starting tinc, it has not
started the discovery process yet, so latency can be high. That is normal, but
after 10 seconds or so it should have settled.

> My suspicion is that Gamma somehow manages to connect to the external
> IP of my NAT and VPN packets are routed around the globe rather than
> through the LAN...

That is indeed likely what happens, but the packets should not go around the
globe, rather the NAT device should send them straight back inside.

> LAN discovery doesn't seem to work in this case.

If the LocalDiscovery option is enabled it should work. It does rely on
broadcast packets though, and may be filtered due to firewall settings on
Alpha, Beta and/or Gamma.

> How can I debug this further?

On Gamma, start tinc with "tincd -n <netname> -d5 -D". This will show a lot of
information. While it is running, ping Alpha or Beta, and see what happens. It
should tell you to which real IP address it is sending packets, that should
start with the WAN IP, but later change to the LAN IP.

> Obviously what I want to accomplish is to have LAN speeds (and connectivity)
> on Gamma when I'm home, so ultimately Gamma should open a connection to
> Alpha's LAN IP, even if it can reach it through it's WAN IP too.

What you can do is add another Address statement to hosts/Alpha on Gamma, with
Gamma's LAN IP address (just like you did with Beta). Make sure it is above the
other Address statement. That way, tinc will first try to connect via the LAN
IP. If that doesn't work, it will try resolving the DynDNS hostname.

> Would tinc 1.1 help here? I was hesitant of using it, since it's not marked
> as stable yet...

It might. It would be very nice in any case if you could try out 1.1pre4, and
let us know if it works fine or if there are any bugs in it.

> Are there any plans of using another LAN discovery method (I saw
> Avahi/Zeroconf mentioned somewhere) maybe that's more standard?

Not really.

> Also I'm not sure if I should change the nodes to "switch" mode
> instead, as I plan to use D-LAN (http://www.d-lan.net/) for
> multisourced sharing of files in my VPN and it's node discovery also
> relies on UDP multicast (http://www.d-lan.net/faq.html). As far as I
> understood, if I change all nodes to "switch" instead, I'd still have
> the current functionality, but be able to have UDP multicasts in the
> VPN as well?

Contrary to what the manual says, multicast IP traffic is also supported in
router mode, so you don't need to use switch mode for D-LAN.

-- 
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/20121206/329ff6d3/attachment.pgp>