[strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0

[Benoit Foucher]

Hi,

After looking more carefully at the logs, there are also some suspicious traces for pluto:

pluto[11637]: | creating acquire event for policy 10.12.15.22/32 === 27.21.27.40/32 with reqid {16420}
pluto[11637]: | 
pluto[11637]: | *handling asynchronous events
pluto[11637]: | initiate on demand from 10.12.15.22:0 to 27.21.27.40:0 proto=0 state: fos_start because: whack
pluto[11637]: | find_connection: looking for policy for connection: 10.12.15.22:0/0 -> 27.21.27.40:0/0
pluto[11637]: | find_connection: concluding with empty

ip xfrm state gives me the following:

src 10.12.15.22 dst 27.21.27.40
        proto esp spi 0xc7c5af3a reqid 16420 mode tunnel
        replay-window 32 
        auth hmac(sha1) 0x47ff9f0112dac804a37a7f47f4371ac8b69219a8
        enc cbc(aes) 0xf1bedbfe7aabc07cda4a40b8fb934484
        sel src 0.0.0.0/0 dst 0.0.0.0/0 
src 27.21.27.40 dst 10.12.15.22
        proto esp spi 0xc500ee4a reqid 16420 mode tunnel
        replay-window 32 
        auth hmac(sha1) 0x413ed35699112a5a00599ee721ce72017f400bbb
        enc cbc(aes) 0x0b289980e478348eb8950bd4da54b8d3
        sel src 0.0.0.0/0 dst 0.0.0.0/0 

It sounds like charon fails to retrieve the policy or are those traces expected?

Thanks

Cheers,
Benoit.

On Dec 2, 2010, at 8:53 PM, Benoit Foucher wrote:

> Hi,
> 
> I've upgraded from 4.4.1 to 4.5.0 today to workaround the issue where a given peer ID can't acquire multiple virtual IP addresses. However, my IKEv1 connections don't work anymore now. I did add keyexchange=ikev1 to make sure to use pluto. I've attached my config below.
> 
> The tunnel is established but it seems there are some problems with routing. If I ping my strongSwan gateway from the peer network, the gateway correctly receives the ICMP packets (according to tcpdump on the gateway). However, the replies don't seem to be sent back over the tunnel (I don't see any ICMP reply with tcpdump on the gateway and the ping from the peer doesn't get any reply either).
> 
> The only suspicious thing are the errors below which come from charon despite the fact that the tunnel is established with pluto. Could this be related to the change where pluto is now using netlink for setting up policies? Here are the messages:
> 
> charon: 05[KNL] received an SADB_ACQUIRE with policy id 140489 but no matching policy found
> charon: 05[KNL] creating acquire job for policy 10.12.15.22/32 === 27.21.27.40/32 with reqid {0}
> charon: 03[CFG] trap not found, unable to acquire reqid 0
> 
> My ipsec.conf for that connection:
> ---
> config setup
>        plutodebug=control
>        crlcheckinterval=180
>        strictcrlpolicy=no
>        charonstart=yes
>        plutostart=yes
>        nat_traversal=yes
> 
> conn %default
>        ikelifetime=3h
>        lifetime=3h
>        rekeymargin=3m
>        keyingtries=1
>        left=%defaultroute
>        leftid=@gw.foo.com
>        leftsourceip=192.168.128.1
>        leftsubnet=192.168.128.0/17
>        leftcert=gw_cert.pem
>        leftfirewall=yes
>        rightfirewall=yes
> 
> conn sj-gw
>        keyexchange=ikev1
>        right=%any
>        leftsubnet=192.168.0.0/16
>        rightsubnet=192.168.0.0/16
>        rightid=@sj-gw.foo.com
>        auto=add
> ----
> 
> Any ideas what could be wrong? Is there some additional settings require for 4.5.0 now?
> 
> Thanks for the help!
> 
> Cheers,
> Benoit.
>