LAN discovery issue

[Markus Teufelberger]

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

2012/12/6 Guus Sliepen <guus at tinc-vpn.org>:
> 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.

/done

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

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

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.

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

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

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