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

[Benoit Foucher]

No other IKE daemons are running, ip xfrm policy does indeed come back empty:

[root at gw ~]# /etc/init.d/ipsec stop
Stopping strongSwan IPsec...
[root at gw ~]# ip xfrm policy
[root at gw ~]# 

Cheers,
Benoit.

On Dec 3, 2010, at 9:25 AM, Andreas Steffen wrote:

> Hi Benoit,
> 
> is there some other IKE daemon running (e.g. racoon) which is inserting
> IPsec policies into the kernel? Does the command
> 
>  ip xfrm policy
> 
> come back empty before you start strongSwan?
> 
> Andreas
> 
> On 12/03/2010 09:21 AM, Benoit Foucher wrote:
>> Hi Andreas,
>> 
>> Thanks for your prompt reply. All my connections are defined with auto=add (a mix of IKEv1 and IKEv2 connections).
>> 
>> Benoit.
>> 
>> On Dec 3, 2010, at 9:18 AM, Andreas Steffen wrote:
>> 
>>> Hi Benoit,
>>> 
>>> it is strange that you get acquire events. Do you define any connections
>>> in ipsec.conf with the setting auto=route? If yes, are these IKEv1
>>> or IKEv2 connections?
>>> 
>>> Regards
>>> 
>>> Andreas
>>> 
>>> On 12/03/2010 09:11 AM, Benoit Foucher wrote:
>>>> 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.
> 
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution!                www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==