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
