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.
> 


_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users

Reply via email to