ARP resolution not done from one end

[Guus Sliepen]

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>