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:
>>>>
>>>> [r...@gw ~]# /etc/init.d/ipsec stop
>>>> Stopping strongSwan IPsec...
>>>> [r...@gw ~]# ip xfrm policy
>>>> [r...@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
>>>>>>>>> [email protected]
>>>>>>>>> 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
>>>>>>>>> [email protected]
>>>>>>>>> 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 [email protected]
>>> 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 [email protected]
> 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]==
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
