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
