[strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0
Benoit Foucher
benoit at bittrap.com
Fri Dec 3 12:56:31 CET 2010
That was it! Disabling the kernel-pfkey plugin solved the issue.
Thanks for your help.
Cheers,
Benoit.
On Dec 3, 2010, at 11:44 AM, Andreas Steffen wrote:
> Hmmm,
>
> I see that pluto loads the kernel-pfkey plugin which is totally untested with IKEv1
>
> Dec 3 09:16:43 gw pluto[16007]: loaded plugins:
> curl aes des blowfish sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem
> gmp hmac xauth attr kernel-pfkey kernel-netlink resolve
>
> Could you please remove the kernel-pfkey plugin and check whether the
> problem disappears? And do the same on charon
>
> Dec 3 09:16:43 gw charon: 00[DMN] loaded plugins:
> curl aes des blowfish sha1 sha2 md4 md5 random x509 revocation pubkey
> pkcs1 pgp pem fips-prf gmp xcbc hmac attr kernel-pfkey kernel-netlink
> resolve socket-raw stroke smp updown eap-identity eap-sim
> eap-sim-file eap-aka eap-md5 eap-gtc eap-mschapv2
>
> since the PFKEYv2 kernel interface does not give you any advantage
> over the default XFRM interface on a Linux box.
>
> Regards
>
> Andreas
>
> On 12/03/2010 10:28 AM, Benoit Foucher wrote:
>> I've attached pluto and charon logs. One additional information: the acquire event traces only show up when I try to ping a machine on the remote network from the strongSwan gateway (the ping doesn't succeed). The remote network is behind a Zywall USG 100 which only supports IKEv1. Thanks again for your help.
>>
>> Cheers,
>> Benoit.
>>
>>
>>
>>
>>
>>
>> On Dec 3, 2010, at 9:50 AM, Andreas Steffen wrote:
>>
>>> It is getting stranger all the time. Could you send me the complete ipsec.conf and complete pluto log (with plutodebug=control) and charon
>>> log where these acquire events happen? Are you initiation both IKEv1 and
>>> IKEv2 connections? Just start the minimum number of connections for
>>> this strange phenomenon to occur.
>>>
>>> Regards
>>>
>>> Andreas
>>>
>>> On 12/03/2010 09:38 AM, Benoit Foucher wrote:
>>>> 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]==
>>
>
>
> --
> ======================================================================
> 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]==
More information about the Users
mailing list