This is iked (IKEv2). No patches, plain from dist. On Oct 13, 2011, at 12:38 PM, Johan Ryberg wrote:
> 2011/10/13 Maxim Bourmistrov <m...@alumni.chalmers.se>: >> Hi misc@, >> >> I'm trying to understand why my IPSec tunnel not functioning as expected and >> especially >> why packets start flow as soon as I start to ping from the opposite side. >> >> Hopefully someone can explain what is going on and why. >> >> Following setup: >> >> Network Home(1.1.1.0/25) connecting to the network office(2.2.2.0/21) via an >> IPSec tunnel. >> Gw at Home-side is an OpenBSD 4.9-stable. Gw at Office OpenBSD 5.0-current in >> a CARP(failover) setup. >> >> gw at home IP: 10.1.1.1 >> gw at office IP: 20.1.1.1(CARP iface. gw1: 20.1.1.2 gw2: 20.1.1.3) >> >> CARP, eg. failover part, is working fine. >> >> Following iked.conf I have. >> >> Home gw: >> local_gw="10.1.1.1" >> remote_gw="20.1.1.1" >> >> ikev2 "homeNET_to_officeNET" active esp \ >> from $local_gw to $remote_gw \ >> from 1.1.1.0/25 to 2.2.2.0/21 \ >> local $local_gw peer $remote_gw \ >> srcid $local_gw \ >> dstid $remote_gw >> >> Office gw: >> local_gw="20.1.1.1" >> remote_gw="10.1.1.1" >> >> ikev2 "officeNET_to_homeNET" passive esp \ >> from $local_gw to $remote_gw \ >> from 2.2.2.0/21 to 1.1.1.0/25 \ >> local $local_gw peer $remote_gw \ >> srcid $local_gw \ >> dstid $remote_gw >> >> >> Tunnel gets established. >> >> On office-gw I see >> sa_state: VALID -> ESTABLISHED from 10.1.1.1:500 to 20.1.1.2:500 policy >> 'officeNET_to_homeNET' >> Note, that the IP-address is actually not one on CARP iface, but rather from >> physical iface. >> >> ipsecctl -s all gives: >> FLOWS: >> flow esp in from 10.1.1.1 to 20.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1 dstid >> IPV4/10.1.1.1 type use >> flow esp out from 20.1.1.1 to 10.1.1.1 peer 10.1.1.1 srcid IPV4/20.1.1.1 dstid >> IPV4/10.1.1.1 type require >> flow esp in from 1.1.1.0/25 to 2.2.2.0/21 peer 10.1.1.1 srcid IPV4/20.1.1.1 >> dstid IPV4/10.1.1.1 type use >> flow esp out from 2.2.2.0/21 to 1.1.1.0/25 peer 10.1.1.1 srcid IPV4/20.1.1.1 >> dstid IPV4/10.1.1.1 type require >> >> SAD: >> ---> esp tunnel from 20.1.1.2 to 10.1.1.1 spi 0x2d2a6151 auth hmac-sha2-256 >> enc aes-256 >> esp tunnel from 10.1.1.1 to 20.1.1.2 spi 0x5152256e auth hmac-sha2-256 enc >> aes-256 >> >> >> On home-gw I see >> sa_state: VALID -> ESTABLISHED from 20.1.1.1:57185 to 10.1.1.1:500 policy >> 'policy1' >> >> ipsecctl -s all gives: >> FLOWS: >> flow esp in from 2.2.2.0/21 to 1.1.1.0/25 peer 20.1.1.1 srcid IPV4/10.1.1.1 >> dstid IPV4/20.1.1.1 type use >> flow esp out from 1.1.1.0/25 to 2.2.2.0/21 peer 20.1.1.1 srcid IPV4/10.1.1.1 >> dstid IPV4/20.1.1.1 type require >> flow esp in from 20.1.1.1 to 10.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1 dstid >> IPV4/20.1.1.1 type use >> flow esp out from 10.1.1.1 to 20.1.1.1 peer 20.1.1.1 srcid IPV4/10.1.1.1 dstid >> IPV4/20.1.1.1 type require >> >> SAD: >> esp tunnel from 20.1.1.1 to 10.1.1.1 spi 0x2d2a6151 auth hmac-sha2-256 enc >> aes-256 >> esp tunnel from 10.1.1.1 to 20.1.1.1 spi 0x5152256e auth hmac-sha2-256 enc >> aes-256 >> >> >> The problem is that I can not ping Office-net from Home-net then tunnel is >> established. >> I can see packets on enc0 going from Home-net to Office-net while I'm watching >> on Home-gw, but nothing on enc0 on the Office-side. >> >> This is the state for tunnel until I start a ping from some machine on >> Office-side, then suddenly tunnel functioning correctly >> and I can ping internal machines from both sides and connect(ssh) from both >> sides. >> >> Question is why this strange behavior? I tried to switch from passive to >> active on the Office-gw with the same result. >> Or does it have to do with the CARP? PF rules are as they are described in the >> iked.conf manual. >> >> Anyone have an idea what is going on? >> >> Regards, >> Maxim > > Have you patched isakmpd? > > Maybe that's one of the problems that was addressed. > > I made a quick script that patches isakmpd automatic, it's maybe ugly > but it works for me. > > http://pastebin.com/CCV0PitV > > Best regards Johan
