On Fri, May 10, 2013 at 09:46:43PM +0200, Nick Hibma wrote:
> We have a setup where each mobile node connects with 1 or more tinc
instances (over different links) to a central node. tinc is running in switch
mode. The link is chosen by setting the IP address on the active link's
interface, and the central node sees this after the first packet on the link,
and moves the MAC address to a different 'ethernet port' (link). This
works really well, and keeps webmal sessions alive on a moving ship (VSat ->
3G -> VSat).
>
> We have changed our setup and now the tunnel becomes idle for long periods
of time. The problem is that the central node expires it's ARP table entry
for the node. tinc is not forwarding ARP requests over the link / links. After
doing 1 ping from the mobile node to the central node the ARP entry is there
again as that end does forward ARP requests, and things are back to normal. The
roaming node seems to initiate ARP resolution, while the central node does not.
>
> Any points as to why the central tinc is not doing / able to do the ARP
request?
I don't know, but here are some things:
- ARP requests are not always broadcast, they can be unicast as well. When the
kernel remembers the MAC address, but the ARP entry is about to expire, it
will use unicast. Only after a few unicast ARP packets have not elicited a
response will the kernel fall back to broadcast. (AFAIK, on Linux.)
- Tinc maintains its own table of MAC addresses it has seen on the VPN. They
are also expired after a while (10 minutes by default, configurable with the
MACExpire option). If a packet inside the VPN has a destination MAC address
that is known, tinc will directly send it to the node it thinks the MAC
address
belongs to. If it is not known, the packet is broadcast.
So, if you swap the MAC addresses of the client's virtual interfaces, and
you
don't send any packet FROM the client, then tinc will not learn of the new
MAC
addresses. If the server still remembers the old MAC addresses, and sends
unicast packets via the wrong link, then the client's kernel will likely
drop
those packets, and there will be no response from the client to fix the
situation.
It could also be something else. Stateful firewall rules can expire their state
after a while. Anyway, when it happens again, run tcpdump on the virtual
interfaces (if possible on the server as well as on both of the client), and
let tinc log what is happening (with tinc 1.0.x, use "tincd -n
<netname> -kint"
to temporarily raise the debug level, or with tinc 1.1pre7, just run "tinc
-n
<netname> log 5").
--
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/20130510/5098376a/attachment.pgp>