[strongSwan] Charon hangs after failing to delete Rekeyed IPsec SAs
anand rao
anandrao_me at yahoo.co.in
Fri Apr 6 14:09:28 CEST 2012
Hi gowrishankar,
Thanks for your reply.
After searching the git for rekeying bugs on 4.3.6, I have updated my setup to strongswan 4.5.3.
Even with this version I encountered multiple redundant SA's issue.
my configuration is as follows
config setup
crlcheckinterval=180
strictcrlpolicy=no
nat_traversal=yes
charonstart=yes
plutostart=yes
charondebug="ike 2, knl 3, cfg 0"
conn toevm2-psk
left=172.17.10.1
leftsubnet=192.168.1.0/24
right=172.17.10.2
rightsubnet=192.168.2.0/24
authby=secret
type=tunnel
keyexchange=ikev2
pfs=yes
auto=route
ikelifetime=9m
keylife=12m
rekeymargin=3m
keyingtries=1
mobike=no
rekeyfuzz=100%
on the other side gateway same configuration with ip's reversed.
with charon debug enabled I saw below messages
when rekeying happens
14[KNL] policy 192.168.1.0/24 === 192.168.2.0/24 fwd already exists, increasing refcount
14[KNL] policy 192.168.2.0/24 === 192.168.1.0/24 out already exists, increasing refcount
after delete payload I can see below messages
14[KNL] deleting policy 192.168.2.0/24 === 192.168.1.0/24 out
14[KNL] policy still used by another CHILD_SA, not removed
14[KNL] deleting policy 192.168.1.0/24 === 192.168.2.0/24 in
14[KNL] policy still used by another CHILD_SA, not removed
so when i issue ipsec statusall
I can see multiple redundant SA's exists
root at OpenWrt:/# ipsec statusall
000 Status of IKEv1 pluto daemon (strongSwan 4.5.3):
000 interface eth2/eth2 fec0::ef01:500
000 interface eth0/eth0 fec0::ee01:500
000 interface lo/lo ::1:500
000 interface lo/lo 127.0.0.1:4500
000 interface lo/lo 127.0.0.1:500
000 interface eth0/eth0 172.17.10.1:4500
000 interface eth0/eth0 172.17.10.1:500
000 interface eth2/eth2 192.168.1.1:4500
000 interface eth2/eth2 192.168.1.1:500
000 interface eth1/eth1 169.254.0.1:4500
000 interface eth1/eth1 169.254.0.1:500
000 interface ath0/ath0 192.168.3.1:4500
000 interface ath0/ath0 192.168.3.1:500
000 %myid = '%any'
000 loaded plugins: aes des blowfish sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem gmp hmac kernel-pfkey kernel-netlink
000 debug options: none
000
Status of IKEv2 charon daemon (strongSwan 4.5.3):
uptime: 17 minutes, since Jan 01 00:07:32 1970
malloc: sbrk 245760, mmap 0, used 112984, free 132776
worker threads: 8 of 16 idle, 7/1/0/0 working, job queue: 0/0/0/0, scheduled: 7
loaded plugins: aes des blowfish sha1 sha2 md5 random x509 pubkey pkcs1 pgp pem gmp xcbc hmac kernel-pfkey kernel-netlink socket-raw stroke updown duplicheck
Listening IP addresses:
172.17.10.1
fec0::ee01
192.168.1.1
fec0::ef01
169.254.0.1
192.168.3.1
Connections:
toevm2-psk: 172.17.10.1...172.17.10.2
toevm2-psk: local: [172.17.10.1] uses pre-shared key authentication
toevm2-psk: remote: [172.17.10.2] uses any authentication
toevm2-psk: child: 192.168.1.0/24 === 192.168.2.0/24 TUNNEL
Routed Connections:
toevm2-psk{1}: ROUTED, TUNNEL
toevm2-psk{1}: 192.168.1.0/24 === 192.168.2.0/24
Security Associations (1 up, 0 connecting):
toevm2-psk[9]: ESTABLISHED 98 seconds ago, 172.17.10.1[172.17.10.1]...172.17.10.2[172.17.10.2]
toevm2-psk[9]: IKE SPIs: 0a9c60819e051c94_i* 0b64df798cd41fb3_r, pre-shared key reauthentication in 69 seconds
toevm2-psk[9]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
toevm2-psk{30}: INSTALLED, TUNNEL, ESP SPIs: cf8743af_i cf7ffe31_o
toevm2-psk{30}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 4 minutes
toevm2-psk{30}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{31}: INSTALLED, TUNNEL, ESP SPIs: ccdfaf22_i ccb5d105_o
toevm2-psk{31}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 5 minutes
toevm2-psk{31}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{32}: INSTALLED, TUNNEL, ESP SPIs: cdd7ce5e_i cc7adc9f_o
toevm2-psk{32}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 minutes
toevm2-psk{32}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{33}: INSTALLED, TUNNEL, ESP SPIs: cb4b4948_i c573c50c_o
toevm2-psk{33}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 4 minutes
toevm2-psk{33}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{34}: INSTALLED, TUNNEL, ESP SPIs: c37fe1cb_i ca4a69e4_o
toevm2-psk{34}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 minutes
toevm2-psk{34}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{35}: INSTALLED, TUNNEL, ESP SPIs: cc0073b7_i c69843da_o
toevm2-psk{35}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 5 minutes
toevm2-psk{35}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{36}: INSTALLED, TUNNEL, ESP SPIs: c43838a9_i c98885c0_o
toevm2-psk{36}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 6 minutes
toevm2-psk{36}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{37}: INSTALLED, TUNNEL, ESP SPIs: cc54f6cf_i c0109628_o
toevm2-psk{37}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 5 minutes
toevm2-psk{37}: 192.168.1.0/24 === 192.168.2.0/24
toevm2-psk{1}: INSTALLED, TUNNEL, ESP SPIs: cf3a7d7f_i c3fe1fcc_o
toevm2-psk{1}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 5 minutes
toevm2-psk{1}: 192.168.1.0/24 === 192.168.2.0/24
Please help me as this is leading to hanging of charon daemon.
Thanks,
Anand
----- Original Message -----
From: gowrishankar <gowrishankar.m at linux.vnet.ibm.com>
To: anand rao <anandrao_me at yahoo.co.in>
Cc: Tobias Brunner <tobias at strongswan.org>; "users at lists.strongswan.org" <users at lists.strongswan.org>
Sent: Friday, March 23, 2012 7:16 PM
Subject: Re: [strongSwan] Charon hangs after failing to delete Rekeyed IPsec SAs
Hi Anand,
wrt RFC 4306 Page 22:
If the two ends have the same lifetime policies, it is possible that
both will initiate a rekeying at the same time (which will result in
redundant SAs). To reduce the probability of this happening, the
timing of rekeying requests SHOULD be jittered (delayed by a random
amount of time after the need for rekeying is noticed).
Not a concrete suggestion, but to make sure that, strongswan 4.3(.6) is
not having
any bug (or improper handling) to gitter rekeymargin. Can it be searched
quickly
in git tree (for any such commit)?
Second, after reading few following paragraphs (and importantly last
para of Sec2.8),
the timing window for rekeymargin is also associated to CREATE_CHILD_SA
request
handled by rekey responder. You may need to look closely in charon.log
at this situation.
I also observed that, you are setting keyingtries=1. Can it be the
default 3 and tried
once again, if there is any packet drop observed ?
Thanks,
Gowri Shankar
On Tuesday 20 March 2012 06:24 PM, anand rao wrote:
> Hi Tobias,
>
> I have already enabled both kernel-pfkey and kernel-netlink plugins. Both the plugins are loaded.
> This was suggested by Andreas for my earlier query about pfkey plugin usage for IKEv1.
>
> Since 4.5.3 is causing kernel-panic in my environment for unknown reasons, i want to resolve
> the redundant child SA issue on 4.3.6. Please suggest me in resolving this issue.
>
> Thanks,
> Anand
>
> ----- Original Message -----
> From: Tobias Brunner<tobias at strongswan.org>
> To: anand rao<anandrao_me at yahoo.co.in>
> Cc: "users at lists.strongswan.org"<users at lists.strongswan.org>
> Sent: Tuesday, March 20, 2012 2:25 PM
> Subject: Re: [strongSwan] Charon hangs after failing to delete Rekeyed IPsec SAs
>
> Hi Anand,
>
>> On my environment there is no support for kernel-netlink interface
>> for IPsec,
>>
>> I have to use kernel-pfkey interface only as I have my hooks
>> registered in PFKEY to XFRM for IPsec.
>>
>> I have tried latest versions of strongswan (4.5.1 and 4.5.3) both
>> resulted in kernel panic after running for a while. I think there is
>> not much support for kernel-pfkey plugin in latest strtongswan
>> versions, and since latest versions require kernel-netlink plugin to
>> function properly migrating to newer versions might be not helpful in
>> my case.
> You actually need both plugins on Linux, even if using kernel-pfkey to
> install IPsec SAs and policies. The reason for this is that the
> kernel-netlink plugin also implements the kernel_net_t interface which
> is used for address and route lookups etc. You can enable both plugins,
> the kernel-pfkey plugin is then loaded first by default (otherwise make
> sure it is loaded first), which means that its kernel_ipsec_t
> implementation is used while the kernel-netlink plugin can still provide
> the required kernel_net_t implementation.
>
> Regards,
> Tobias
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
>
More information about the Users
mailing list