LAN discovery issue

Post by Markus Teufelberger
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.

Post by Markus Teufelberger
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.
Pinging Alpha's VPN IP from Beta gives great LAN times of ~1 ms.
Pinging Beta's VPN IP from Alpha too.
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.

Post by Markus Teufelberger
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.

Post by Markus Teufelberger
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.

Post by Markus Teufelberger
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.

Post by Markus Teufelberger
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.

Post by Markus Teufelberger
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.

Post by Markus Teufelberger
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.

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

Not really.

Post by Markus Teufelberger
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>

Markus Teufelberger

2013-01-19 21:06:20 UTC

Ok, I decided to go ahead with still trying out 1.0.19 a bit, I'll
test 1.1pre5 when it comes out.

Post by Markus Teufelberger
Alpha
*******************
Subnet = [single IP]/32
IndirectData = yes

/done

Post by Markus Teufelberger
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.

Ok, then it's just the stupid router at home that's so slow...

Post by Markus Teufelberger
How can I debug this further?

Work perfectly on LAN now, BUT I seem now to have that problem the
other way round:
It seems to try quite often via the LAN IP and rather forwards the
packets (even though I did remove the IndirectData stuff from all
config files) though Alpha when connecting to the VPN from the
internet from Gamma (who ConnetsTo Alpha) and pinging Beta... Even
after a minute or so, the -d5 log just contains the following 5 lines:

Sending packet of 74 bytes to Alpha ([WAN-IP] port YYY)
Received packet of 74 bytes from Alpha ([WAN-IP] port YYY)
Writing packet of 74 bytes to Windows tap device
Sending packet of 74 bytes to Beta (192.168.x.x port XXX)
Packet for Beta (192.168.x.x port XXX) larger than minimum MTU, for
warding via Alpha

Also in the beginning, there was the following error for some time
periodically (went away though after half a minute or so):
Error sending packet to Alpha ([WAN-IP] port YYY): (10014) The s
ystem detected an invalid pointer address in attempting to use a pointer argumen
t in a call.

Post by Markus Teufelberger
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.

There was a bug on win32 reported by fantomtk (and fixed on git
already), so I decided to wait for pre5 before I try out pre4 and have
tinc maybe stall randomly.

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.

I receive the following error with -d5 when running D-LAN (D-LAN is
bound to the tinc interface):
Cannot route packet from Gamma (MYSELF): unknown IPv4 destination
address: 10.xx.xx.255

My guess is that I somehow need to tell tinc that I am actually trying
to run a 10.x.x.0/24 network, but on the other hand I only use static
IPs (10.x.x.x/32) in my config files.

That all aside, I ran into a different issue - from the manual:
?ALRM?
Forces tinc to try to connect to all uplinks immediately. Usually tinc
attempts to do this itself, but increases the time it waits between
the attempts each time it failed, and if tinc didn?t succeed to
connect to an uplink the first time after it started, it defaults to
the maximum time of 15 minutes.

On a laptop it is (in my case) quite common that connecting to the
wireless network takes a few seconds after booting - tinc seems to be
faster and then is on a strike for 15 minutes (there's no way I know
of to send a signal to a service on Windows). Please make that maximum
value configurable or make it fail a bit more gracefully (first wait 2
seconds, then 4, then 8 or whatever you do to increase the wait time)
instead of going directly to the max. value. I tried to set up a
backup program to run after boot - but then the tinc interface doesn't
come up for 15 minutes after booting, which screws the whole process
and confuses the hell out of that poor program too... ;-)

Guus Sliepen

2013-01-20 15:39:55 UTC

Post by Guus Sliepen
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.

Work perfectly on LAN now, BUT I seem now to have that problem the
It seems to try quite often via the LAN IP and rather forwards the
packets (even though I did remove the IndirectData stuff from all
config files) though Alpha when connecting to the VPN from the
internet from Gamma (who ConnetsTo Alpha) and pinging Beta... Even
Sending packet of 74 bytes to Alpha ([WAN-IP] port YYY)
Received packet of 74 bytes from Alpha ([WAN-IP] port YYY)
Writing packet of 74 bytes to Windows tap device
Sending packet of 74 bytes to Beta (192.168.x.x port XXX)
Packet for Beta (192.168.x.x port XXX) larger than minimum MTU, for
warding via Alpha
Also in the beginning, there was the following error for some time
Error sending packet to Alpha ([WAN-IP] port YYY): (10014) The s
ystem detected an invalid pointer address in attempting to use a pointer argumen
t in a call.

Hm, half a minute corresponds with the maximum time PMTU discovery can take. So
somehow that fails (maybe it is indeed an invalid pointer, although it could
also be something completely different), and that means tinc thinks direct
communication with Alpha is not possible, so it will indeed forward packets via
another node.

Post by Guus Sliepen
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.

I receive the following error with -d5 when running D-LAN (D-LAN is
Cannot route packet from Gamma (MYSELF): unknown IPv4 destination
address: 10.xx.xx.255

That's not a multicast address, but a broadcast address. I see in the FAQ on
D-LAN's website that they use 236.13.43.24 as the multicast address. My guess
is that those multicast packets are not being sent to tinc's interface by your
operating system. I have no idea how multicast actually works on Windows.

Post by Markus Teufelberger
My guess is that I somehow need to tell tinc that I am actually trying
to run a 10.x.x.0/24 network, but on the other hand I only use static
IPs (10.x.x.x/32) in my config files.

In this case it might indeed be better to run tinc in switch mode.

Post by Markus Teufelberger
?ALRM?
Forces tinc to try to connect to all uplinks immediately. Usually tinc
attempts to do this itself, but increases the time it waits between
the attempts each time it failed, and if tinc didn?t succeed to
connect to an uplink the first time after it started, it defaults to
the maximum time of 15 minutes.

Uhm, that is strange, it should not go to the maximum time immediately... I
cannot reproduce this behaviour myself on Linux, but I'll try it on Windows
later.

Post by Markus Teufelberger
On a laptop it is (in my case) quite common that connecting to the
wireless network takes a few seconds after booting - tinc seems to be
faster and then is on a strike for 15 minutes (there's no way I know
of to send a signal to a service on Windows). Please make that maximum
value configurable or make it fail a bit more gracefully (first wait 2
seconds, then 4, then 8 or whatever you do to increase the wait time)
instead of going directly to the max. value.

You can change the maximum time with the MaxTimeout configuration variable.
Also, tinc 1.1 doesn't rely on signals anymore, you will be able to tell tinc
to immediately try reconnecting using the tincctl program.

Post by Markus Teufelberger
I tried to set up a
backup program to run after boot - but then the tinc interface doesn't
come up for 15 minutes after booting, which screws the whole process
and confuses the hell out of that poor program too... ;-)

For now just add something like "MaxTimeout = 30" to tinc.conf :)
--
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/20130120/495d9a5d/attachment.pgp>

Rob Townley

2013-01-24 04:19:09 UTC

If for some reason, MaxTimeout does not work:

A win32 sleep command could also be used.
At cmd.exe, set /?
i believe set or choice can take input but times out after a specified
amount of time.
tinc-up could sleep for 30 seconds or so.

Post by Guus Sliepen
What you can do is add another Address statement to hosts/Alpha on

Gamma, with

Post by Guus Sliepen
Gamma's LAN IP address (just like you did with Beta). Make sure it is

above the

Post by Guus Sliepen
other Address statement. That way, tinc will first try to connect via

the LAN

Post by Guus Sliepen
IP. If that doesn't work, it will try resolving the DynDNS hostname.

argumen

Post by Markus Teufelberger
t in a call.

Post by Guus Sliepen
Contrary to what the manual says, multicast IP traffic is also

supported in