[strongSwan] installpolicy=no not working, even when reqid is manually set
Mohammad Ayyash
mohammad.ayyash at nsn.com
Tue Nov 2 10:16:55 CET 2010
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?
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>
More information about the Users
mailing list