tinc - Dec 2012 - LAN discovery issue

Hi there,

Following situation:

3 nodes, Alpha (Home fileserver), Beta (regular PC), Gamma (Notebook).
All three in a NATed LAN usually, though the notebook also gets
carried around and connects from the outside from time to time. Tinc
should help me keep my other 2 PCs reachable from Gamma, even when I'm
not at home. Also I plan on maybe adding more nodes to that in the
future.

I have set up a DynDNS entry + port forward to Alpha and Beta from the
internet and it works great (tested on Gamma by disabling WLAN and
using an UMTS stick instead, so I connect from the outside).

Configuration:
tinc.conf on all three nodes (all running tinc 1.0.19 on Windows):
*******************
Name = [Name]
ConnectTo = Alpha (<-- commented out on Alpha of course)
Compression = 9
LocalDiscovery = yes
Interface = tincVPN
*******************

host files:
Alpha
*******************
Subnet = [single IP]/32
IndirectData = yes
Address = [DynDNS]
Port = [Port]
-----RSA Part-----
*******************
Beta
*******************
Subnet = [single IP]/32
IndirectData = yes
Address = [DynDNS]
Port = [Port]
-----RSA Part-----
*******************
Gamma
*******************
Subnet = [single IP]/32
IndirectData = yes
-----RSA Part-----
*******************

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

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... LAN discovery doesn't seem to work in this case.

How can I debug this further? 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. It seems to me that the
packets for LocalDiscovery get lost somewhere in my network or at
least not picked up/used by the clients. Would tinc 1.1 help here? I
was hesitant of using it, since it's not marked as stable yet... Are
there any plans of using another LAN discovery method (I saw
Avahi/Zeroconf mentioned somewhere) maybe that's more standard?
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?

Thanks for reading (and if you write an answer, thanks for that too!)
and for providing such a great piece of software!

Cheers,
Markus

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>