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.
pluto.log
Description: Binary data
charon.log
Description: Binary data
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]==
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
