Subject: strange IPsec+gif problem
To: None <tech-net@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: tech-net
Date: 06/01/2005 17:57:54
Hi,
I have 2 3.0_BETA systems, running identical software and hardware.
I'm using them to do a etherIP tunnel, to provide ethernet connectivity
between 2 sites. Both have the following setup:

          ex0
	/   \
    vlan0    vlan4
	       |
             bridge4
	       |
	      gif4

vlan0 has a routable IP (say, a.b.c.d and a.b.c.e). vlan4 has a local IP
(say, 10.0.0.1 and 10.0.0.2) and is connected to the ethernet network I
want to tunnel between the 2 sites. gif4 runs in etherip mode.

With just this setup, all work fine. Any box on from one site can ping any
box from the other though the tunnel.
Now I'd like to add ipsec to secure the tunnel. I use on each system:
add a.b.c.d a.b.c.e esp 1234 -E 3des-cbc "foobar1" -A hmac-sha1 "barfoo1";
add a.b.c.e a.b.c.d esp 4321 -E 3des-cbc "foobar2" -A hmac-sha1 "barfoo2";

spdadd 0.0.0.0/0 0.0.0.0/0 etherip -P out ipsec esp/transport//require;
spdadd 0.0.0.0/0 0.0.0.0/0 etherip -P in ipsec esp/transport//require;

With this in place, things mostly works exept the following oddities:
- one of the box (and only one) sends once per second a ESP packet which
  doesn't seen related to a real packet sent from the box:
  17:42:17.166135 00:04:76:24:5f:7f > 01:00:5e:63:3f:3a, ethertype IPv4 (0x0800), length 134: IP a/b/c/d > a.b.c.e: ESP(spi=0x00001234,seq=0x4d3)
  Note that this packet is sent to a multicast ethernet address.
  Does anyone know what this means ? Packets related to the tunnel traffic
  use the ethernet addresses of each host, as expected.

- I can't ping any more a host on the remote site from one of the IPsec box:
  it doens't get back ARP replies. If I enter the MAC address using arp,
  then IP traffic works. From tcpdump output, it seems that the ARP reply
  is properly forwarded over the tunnel but isn't properly received by the
  local box. Looking at tcpdump output it seems that the arp replies
  are received, but are eiter not properly decoded by ipsec, or not properly 
  received by the gif interface (tcpdump doesn't decode properly packets
  on gif interfaces in ethetip mode).
  Again, any idea what could cause this problem ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--