[strongSwan] installpolicy=no not working, even when reqid is manually set

Mohammad Ayyash mohammad.ayyash at nsn.com
Tue Nov 2 10:29:16 CET 2010


By the way, i just realized it is 4.3.6

there is not any previous connection, this is the first connection made 
after clean start, and i couldn't find indications of a temporary SA 
created and deleted.

# ip xfrm state
src 10.0.0.2 dst 10.0.0.1
     proto esp spi 0xc4ac94cf reqid 2 mode tunnel
     replay-window 32 flag 20
     auth hmac(md5) 0x11ff55908a41ac92f141544623ca8420
     enc cbc(des3_ede) 0x4097d8e922581bb364afd6ff020e223ef3335999dbf2b29c
src 10.0.0.1 dst 10.0.0.2
     proto esp spi 0xce030a4e reqid 2 mode tunnel
     replay-window 32 flag 20
     auth hmac(md5) 0x405d116a3795afb110450a3ba386e011
     enc cbc(des3_ede) 0xa5ec086797c680f5960f44ef9e6a227a4a688f66b36f6a76


# ip  xfrm policy
src 5.5.0.0/16 dst 4.4.0.0/16
     dir in priority 31800
     tmpl src 10.0.0.1 dst 10.0.0.2
         proto esp reqid 1 mode tunnel
src 4.4.0.0/16 dst 5.5.0.0/16
     dir out priority 31800
     tmpl src 10.0.0.2 dst 10.0.0.1
         proto esp reqid 1 mode tunnel


log doesn't show double sessions!

configuration 'rule16~vpn1' routed
10[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
10[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
10[IKE] 10.0.0.1 is initiating an IKE_SA
10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) 
N(NATD_D_IP) N(MULT_AUTH) ]
10[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
12[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
12[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) ]
12[CFG] looking for peer configs matching 
10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
12[CFG] selected peer config 'rule16~vpn1'
12[IKE] authentication of '10.0.0.1' with pre-shared key successful
12[IKE] authentication of '10.0.0.2' (myself) with pre-shared key
12[IKE] IKE_SA rule16~vpn1[1] established between 
10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
12[IKE] scheduling rekeying in 1900s
12[IKE] maximum IKE_SA lifetime 2000s
12[IKE] CHILD_SA rule16~vpn1{2} established with SPIs ce030a4e_i 
c4ac94cf_o and TS 4.4.0.0/16 === 5.5.0.0/16
12[ENC] generating IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
12[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]






On 11/02/2010 11:22 AM, ext Andreas Steffen wrote:
> Charon starts with reqid 1 and then just enumerates them. If
> reqid 2 is assigned to your IPsec SA means that reqid 1 was
> assigned to an earlier connection.
>
> Regards
>
> Andreas
>
> On 02.11.2010 10:16, Mohammad Ayyash wrote:
>> hi,
>>
>> can you explain how Charon assigns reqids (4.3.x)?
>>
>> i insert two xfrm rules:
>> ip xfrm policy add dir in  src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>> priority 31800 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp mode tunnel
>> reqid 1 level required
>> ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
>> priority 31800 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode tunnel
>> reqid 1 level required
>>
>>
>> configurations is like shown below for host2, here is the log
>>
>> 06[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
>> 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
>> 06[IKE] 10.0.0.1 is initiating an IKE_SA
>> 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP)
>> N(NATD_D_IP) N(MULT_AUTH) ]
>> 06[NET] sending packet: from 10.0.0.2[500] to 10.0.0.1[500]
>> 07[NET] received packet: from 10.0.0.1[500] to 10.0.0.2[500]
>> 07[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MULT_AUTH) ]
>> 07[CFG] looking for peer configs matching
>> 10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
>> 07[CFG] selected peer config 'rule16~vpn1'
>> 07[IKE] authentication of '10.0.0.1' with pre-shared key successful
>> 07[IKE] authentication of '10.0.0.2' (myself) with pre-shared key
>> 07[IKE] IKE_SA rule16~vpn1[1] established between
>> 10.0.0.2[10.0.0.2]...10.0.0.1[10.0.0.1]
>> 07[IKE] scheduling rekeying in 1854s
>> 07[IKE] maximum IKE_SA lifetime 1954s
>> 07[KNL] getting SPI for reqid {2}
>>
>>
>> my question is about the last line, where did this {2} come from?  this
>> is causing the local kernel drop packets since there will be SAD entries
>> with reqids 2 and SPD entries with reqid 1.
>>
>>
>> -Mohammad
>>
>>
>>
>>
>>
>>
>> On 11/01/2010 08:45 PM, ext Andreas Steffen wrote:
>>> Hi Mohammad,
>>>
>>> I recommend to upgrade to strongSwan 4.4.1 or 4.5.0 where you
>>> can fix the reqid with
>>>
>>>    conn xyz
>>>         reqid=<value>
>>>
>>> Regards
>>>
>>> Andreas
>>>
>>> On 11/01/2010 07:17 PM, Mohammad Ayyash wrote:
>>>> Hi,
>>>>
>>>> This topic has been complained about so many times and i wonder why
>>>> there isn't proper documentation about it.  It is clear from this
>>>> mailing list + strongswan documentation that if you wish to control SPD
>>>> policy installment yourself, you should set installpolicy=no, but if you
>>>> do, you must also manually set reqid when creating SPD entries, though
>>>> you have to guess the reqid and hope for the best (i am still using
>>>> 4.3.x, can't upgrade yet)
>>>>
>>>> the setup is very simple:
>>>> Host1
>>>> Host2
>>>> 10.0.0.1<========== IPSec  tunnel ==========>   10.0.0.2
>>>> 5.5.0.0/16
>>>> 4.4.0.0/16
>>>>
>>>> traffic going between 5.5.0.0/16 and 4.4.0.0/16 subnets will go in IPsec
>>>> tunnel.
>>>>
>>>> configurations:
>>>> Host1 (initiates ping):
>>>> /etc/ipsec.conf:
>>>> config setup
>>>>        charonstart=yes
>>>>        plutostart=no
>>>>        charondebug="knl 0,enc 0,net 0"
>>>> conn %default
>>>>        keyexchange=ikev2
>>>> ca strongswan
>>>>        cacert=/etc/ipsec/certs/ipsec.d//cacerts/cacert.pem
>>>> conn rule16~vpn1
>>>>        rekeymargin=100
>>>>        rekeyfuzz=100%
>>>>        left=10.0.0.1
>>>>        right=10.0.0.2
>>>>        leftsubnet=5.5.0.0/16
>>>>        rightsubnet=4.4.0.0/16
>>>>        leftprotoport=%any
>>>>        rightprotoport=%any
>>>>        authby=secret
>>>>        leftid=10.0.0.1
>>>>        rightid=10.0.0.2
>>>>        ike=aes128-md5-modp768
>>>>        esp=3des-md5
>>>>        type=tunnel
>>>>        pfs=yes
>>>>        pfsgroup=modp1024
>>>>        ikelifetime=2000s
>>>>        keylife=1000s
>>>>        mobike=no
>>>>        auto=route
>>>>        installpolicy=no
>>>>
>>>> xfrm config:
>>>> ip xfrm policy add dir out  src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>>>> action allow priority 31798 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp
>>>> mode tunnel reqid 1 level required
>>>> ip xfrm policy add dir in src 4.4.0.0/16 dst 5.5.0.0/16 proto any action
>>>> allow priority 31798 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode
>>>> tunnel reqid 1 level required
>>>>
>>>> # ip xfrm policy
>>>> 4.4.0.0/16[0] 5.5.0.0/16[0]
>>>>        upspec 0 dev (none) uid 0
>>>>        in  allow index 0x8010a878 priority 31800 share any flags
>>>> 0x00000000
>>>>        tmpl-1:
>>>>          10.0.0.2 10.0.0.1
>>>>              esp spi 0(0x00000000) reqid 1 tunnel
>>>>              level required share any algo-mask:E=32, A=32, C=32
>>>>        vrfid: 0
>>>>        linkvrfid: 0
>>>>        fpid 0x0000004c
>>>>
>>>> 5.5.0.0/16[0] 4.4.0.0/16[0]
>>>>        upspec 0 dev (none) uid 0
>>>>        out allow index 0x8010a871 priority 31800 share any flags
>>>> 0x00000000
>>>>        tmpl-1:
>>>>          10.0.0.1 10.0.0.2
>>>>              esp spi 0(0x00000000) reqid 1 tunnel
>>>>              level required share any algo-mask:E=32, A=32, C=32
>>>>        vrfid: 0
>>>>        linkvrfid: 0
>>>>        fpid 0x0000004b
>>>>
>>>>
>>>> # ip xfrm state
>>>> 10.0.0.1 10.0.0.2
>>>>        esp spi -926705739(0xc8c397b5) reqid 1 tunnel
>>>>        A:md5 3f3c4f2f 57a7f21f 80498a37 ea4af86
>>>>        E:des3_ede fdd4ad84 bba12863 fa248f1d 4c08e50 d5f6ec7 b27945e3
>>>>        vrfid: 0
>>>>        xvrfid: 0
>>>>        fpid 0x0000004a
>>>>        fp_output_blade 1
>>>> 10.0.0.2 10.0.0.1
>>>>        esp spi -806604046(0xcfec32f2) reqid 1 tunnel
>>>>        A:md5 dbbdbbd5 2a4b3e2c 9958557 703262b9
>>>>        E:des3_ede 27edde48 aabb4bb 9abc758f 2db6185e e2643aa5 46318f40
>>>>        vrfid: 0
>>>>        xvrfid: 0
>>>>        fpid 0x00000049
>>>>        fp_output_blade 1
>>>>
>>>>
>>>>
>>>> Host2 configurations (responds to ping)
>>>>
>>>>
>>>> config setup
>>>>            charonstart=yes
>>>>            plutostart=no
>>>>            charondebug="knl 0,enc 0,net 0"
>>>> conn %default
>>>>            auto=route
>>>>            keyexchange=ikev2
>>>> ca strongswan
>>>>            cacert=/etc/ipsec/certs/ipsec.d//cacerts/cacert.pem
>>>> conn rule16~vpn1
>>>>            rekeymargin=100
>>>>            rekeyfuzz=100%
>>>>            left=10.0.0.2
>>>>            right=10.0.0.1
>>>>            leftsubnet=4.4.0.0/16
>>>>            rightsubnet=5.5.0.0/16
>>>>            leftprotoport=%any
>>>>            rightprotoport=%any
>>>>            authby=secret
>>>>            leftid=10.0.0.2
>>>>            rightid=10.0.0.1
>>>>            ike=aes128-md5-modp768
>>>>            esp=3des-md5
>>>>            type=tunnel
>>>>            pfs=yes
>>>>            pfsgroup=modp1024
>>>>            ikelifetime=2000s
>>>>            keylife=1000s
>>>>            mobike=no
>>>>            auto=route
>>>>            installpolicy=no
>>>>
>>>> ip xfrm policy add dir in  src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>>>> action allow priority 31798 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp
>>>> mode tunnel reqid 1 level required
>>>> ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
>>>> action allow priority 31798 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp
>>>> mode tunnel reqid 1 level required
>>>>
>>>>
>>>> ip xfrm policy
>>>>
>>>> src 5.5.0.0/16 dst 4.4.0.0/16
>>>>        dir in priority 31800
>>>>        tmpl src 10.0.0.1 dst 10.0.0.2
>>>>            proto esp reqid 1 mode tunnel
>>>> src 4.4.0.0/16 dst 5.5.0.0/16
>>>>        dir out priority 31800
>>>>        tmpl src 10.0.0.2 dst 10.0.0.1
>>>>            proto esp reqid 1 mode tunnel
>>>>
>>>>
>>>> ip xfrm state
>>>> src 10.0.0.2 dst 10.0.0.1
>>>>        proto esp spi 0xcfec32f2 reqid 2 mode tunnel
>>>>        replay-window 32 flag 20
>>>>        auth hmac(md5) 0xdbbdbbd52a4b3e2c99058557703262b9
>>>>        enc cbc(des3_ede)
>>>> 0x27edde48aabb4b0b9abc758f2db6185ee2643aa546318f40
>>>> src 10.0.0.1 dst 10.0.0.2
>>>>        proto esp spi 0xc8c397b5 reqid 2 mode tunnel
>>>>        replay-window 32 flag 20
>>>>        auth hmac(md5) 0x3f3c4f2f57a7f21f80498a37ea4a0f86
>>>>        enc cbc(des3_ede)
>>>> 0xfdd4ad84bba12863fa248f1d4c008e50d50f6ec7b27945e3
>>>>
>>>>
>>>> TCPdump on Host2:
>>>> 18:33:51.034800 IP 10.0.0.1.isakmp>   10.0.0.2.isakmp: isakmp: parent_sa
>>>> ikev2_init[I]
>>>> 18:33:51.049928 IP 10.0.0.2.isakmp>   10.0.0.1.isakmp: isakmp: parent_sa
>>>> ikev2_init[]
>>>> 18:33:51.054881 IP 10.0.0.1.isakmp>   10.0.0.2.isakmp: isakmp: child_sa
>>>> ikev2_auth[I]
>>>> 18:33:51.058002 IP 10.0.0.2.isakmp>   10.0.0.1.isakmp: isakmp: child_sa
>>>> ikev2_auth[]
>>>> 18:33:51.062744 IP 10.0.0.1>   10.0.0.2: ESP(spi=0xc8c397b5,seq=0x1),
>>>> length 116
>>>> 18:33:51.062744 IP 5.5.0.1>   4.4.0.1: ICMP echo request, id 1943, seq 1,
>>>> length 64
>>>> 18:33:52.060550 IP 10.0.0.1>   10.0.0.2: ESP(spi=0xc8c397b5,seq=0x2),
>>>> length 116
>>>> 18:33:52.060550 IP 5.5.0.1>   4.4.0.1: ICMP echo request, id 1943, seq 2,
>>>> length 64
>>>> 18:33:53.061335 IP 10.0.0.1>   10.0.0.2: ESP(spi=0xc8c397b5,seq=0x3),
>>>> length 116
>>>> 18:33:53.061335 IP 5.5.0.1>   4.4.0.1: ICMP echo request, id 1943, seq 3,
>>>> length 64
>>>>
>>>>
>>>> and looks like that kernel is happy:
>>>> type=MAC_IPSEC_EVENT msg=audit(1288629231.034:31937): op=SA-notfound
>>>> src=10.0.0.1 dst=10.0.0.2 spi=3940734004(0xeae2d434) seqno=4267262005
>>>> type=MAC_IPSEC_EVENT msg=audit(1288629231.054:31938): op=SA-notfound
>>>> src=10.0.0.1 dst=10.0.0.2 spi=3940734004(0xeae2d434) seqno=4267262005
>>>> type=MAC_IPSEC_ADDSA msg=audit(1288629231.056:31939): SAD add: auid=0
>>>> src=10.0.0.1 dst=10.0.0.2 spi=3368261557(0xc8c397b5) protocol=ESP res=1
>>>> type=SYSCALL msg=audit(1288629231.056:31939): arch=40000003 syscall=102
>>>> success=yes exit=420 a0=b a1=b5791a80 a2=ed06e4 a3=1 items=0 ppid=19459
>>>> pid=19470 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 eg
>>>> id=0 sgid=0 fsgid=0 tty=(none) ses=4428 comm="charon"
>>>> exe="/usr/local/libexec/ipsec/charon" key=(null)
>>>> type=MAC_IPSEC_ADDSA msg=audit(1288629231.056:31940): SAD add: auid=0
>>>> src=10.0.0.2 dst=10.0.0.1 spi=3488363250(0xcfec32f2) protocol=ESP res=1
>>>> type=SYSCALL msg=audit(1288629231.056:31940): arch=40000003 syscall=102
>>>> success=yes exit=420 a0=b a1=b5791a80 a2=ed06e4 a3=1 items=0 ppid=19459
>>>> pid=19470 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 eg
>>>> id=0 sgid=0 fsgid=0 tty=(none) ses=4428 comm="charon"
>>>> exe="/usr/local/libexec/ipsec/charon" key=(null)
>>>>
>>>>
>>>>
>>>> so it s clear that SAD is established.  But my guess is that the kernel
>>>> drop the ping packet after decrypting it because it can't find a
>>>> matching SPD, since the SAD reqid is 2, but the SPD reqid is 1.
>>>>
>>>>
>>>> by the way, if i manually set the SPD to 2, it works like magic!! here
>>>> is what i did on Host2:
>>>> ip xfrm policy flush
>>>> ip xfrm policy add dir in  src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>>>> priority 31800 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp mode tunnel
>>>> reqid 2 level required
>>>> ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
>>>> priority 31800 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode tunnel
>>>> reqid 2 level required
>>>>
>>>>
>>>> ip xfrm policy
>>>> src 5.5.0.0/16 dst 4.4.0.0/16
>>>>        dir in priority 31800
>>>>        tmpl src 10.0.0.1 dst 10.0.0.2
>>>>            proto esp reqid 2 mode tunnel
>>>> src 4.4.0.0/16 dst 5.5.0.0/16
>>>>        dir out priority 31800
>>>>        tmpl src 10.0.0.2 dst 10.0.0.1
>>>>            proto esp reqid 2 mode tunnel
>>>>
>>>>
>>>>     ip xfrm state
>>>> src 10.0.0.2 dst 10.0.0.1
>>>>        proto esp spi 0xca4b93d8 reqid 2 mode tunnel
>>>>        replay-window 32 flag 20
>>>>        auth hmac(md5) 0x1ff83ae814829e5462df5e0630c85aef
>>>>        enc cbc(des3_ede)
>>>> 0x6570b63899e1a9e033ecd4c06be9d52fffc9a13cc3c38e75
>>>> src 10.0.0.1 dst 10.0.0.2
>>>>        proto esp spi 0xcd3a6949 reqid 2 mode tunnel
>>>>        replay-window 32 flag 20
>>>>        auth hmac(md5) 0x82d26082cbf3eb9fb413540c8520bafb
>>>>        enc cbc(des3_ede)
>>>> 0x09e998e1a8cc10aa786b8400e677ab40edcce11c13217317
>>>>
>>>>
>>>>
>>>> with some audit messages from the kernel:
>>>> type=MAC_IPSEC_EVENT msg=audit(1288630275.825:31958): op=SA-notfound
>>>> src=10.0.0.1 dst=10.0.0.2 spi=933797257(0x37a89d89) seqno=1612457666
>>>> type=MAC_IPSEC_EVENT msg=audit(1288630275.847:31959): op=SA-notfound
>>>> src=10.0.0.1 dst=10.0.0.2 spi=933797257(0x37a89d89) seqno=1612457666
>>>> type=MAC_IPSEC_ADDSA msg=audit(1288630275.850:31960): SAD add: auid=0
>>>> src=10.0.0.1 dst=10.0.0.2 spi=3443157321(0xcd3a6949) protocol=ESP res=1
>>>> type=SYSCALL msg=audit(1288630275.850:31960): arch=40000003 syscall=102
>>>> success=yes exit=420 a0=b a1=b112fa80 a2=3cb6e4 a3=1 items=0 ppid=19536
>>>> pid=19554 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 eg
>>>> id=0 sgid=0 fsgid=0 tty=(none) ses=4428 comm="charon"
>>>> exe="/usr/local/libexec/ipsec/charon" key=(null)
>>>> type=MAC_IPSEC_ADDSA msg=audit(1288630275.850:31961): SAD add: auid=0
>>>> src=10.0.0.2 dst=10.0.0.1 spi=3393950680(0xca4b93d8) protocol=ESP res=1
>>>>
>>>>
>>>> So you said charon starts counting reqid from 1, why did it then insert
>>>> a SAD with reqid 2?
>>>>
>>>>
>>>> another puzzling issue which sounds like a nice work around (but would
>>>> like to verify its sanity) is that if i do this: for out rules, give
>>>> reqid (2n+1), and for in rules give reqid (2n+2), where n=0,1,2,..
>>>> number of rules.
>>>>
>>>> here is host2:
>>>> ip xfrm policy flush
>>>> ip xfrm policy add dir in  src 5.5.0.0/16 dst 4.4.0.0/16 proto any
>>>> priority 31800 tmpl src 10.0.0.1 dst 10.0.0.2 proto esp mode tunnel
>>>> reqid 2 level required
>>>> ip xfrm policy add dir out src 4.4.0.0/16 dst 5.5.0.0/16 proto any
>>>> priority 31800 tmpl src 10.0.0.2 dst 10.0.0.1 proto esp mode tunnel
>>>> reqid 1 level required
>>>>
>>>>
>>>> is this the right way to go?
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> 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]==
>




More information about the Users mailing list