[prev in list] [next in list] [prev in thread] [next in thread]
List: strongswan-users
Subject: [strongSwan] Multiple CHILD_SA problem
From: John Brown <jb20141125 () gmail ! com>
Date: 2016-02-26 14:59:46
Message-ID: CAMCukfURByoDoXHhe6Rp6naRVZjdRkJmZQhXGx+wSNNvoAsHyQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi all,
I am facing some problems with strongswan 4.5.2 or 5.2.1 (currenty tested)
on debian wheezy (armel). One of these problems is having multiple CHILD_SA
created under Security Association
For example, fragment of the output from "ipsec statusall" taken from
remote device looks like this:
Security Associations (1 up, 0 connecting):
vpn1[17]: ESTABLISHED 33 minutes ago, 2001:db8:de5c::134[C=AA,
O=Test-co, CN=dev1]...2001:db8:cab1::201[C=AA, O=Test-co, CN=dev2]
vpn1[17]: IKEv2 SPIs: 6e7520807913c57c_i* 404ad97e8447df4a_r, rekeying
in 60 minutes, public key reauthentication in 2 hours
vpn1[17]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_512/MODP_2048
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c947dd26_i c85fc3c0_o
vpn1{10}: AES_GCM_12_256, 2496 bytes_i (24 pkts, 0s ago), 3120 bytes_o
(30 pkts, 0s ago), rekeying in 9 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c04a385a_i cdcc2a4b_o
vpn1{10}: AES_GCM_12_256, 23296 bytes_i (224 pkts, 0s ago), 23920
bytes_o (230 pkts, 0s ago), rekeying in 7 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c09d50d8_i c72fefde_o
vpn1{10}: AES_GCM_12_256, 16016 bytes_i (154 pkts, 0s ago), 16640
bytes_o (160 pkts, 0s ago), rekeying in 10 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: ce87de01_i c0bd6c13_o
vpn1{10}: AES_GCM_12_256, 23088 bytes_i (222 pkts, 0s ago), 23816
bytes_o (229 pkts, 0s ago), rekeying in 8 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c83839f6_i c5bee9c4_o
vpn1{10}: AES_GCM_12_256, 2392 bytes_i (23 pkts, 0s ago), 3120 bytes_o
(30 pkts, 0s ago), rekeying in 10 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c4f3ff51_i ce1cb4f4_o
vpn1{10}: AES_GCM_12_256, 40872 bytes_i (393 pkts, 0s ago), 41600
bytes_o (400 pkts, 0s ago), rekeying in 9 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: cce7630b_i c125f156_o
vpn1{10}: AES_GCM_12_256, 10712 bytes_i (103 pkts, 0s ago), 11440
bytes_o (110 pkts, 0s ago), rekeying in 11 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c106eb4e_i cdeae2d2_o
vpn1{10}: AES_GCM_12_256, 34528 bytes_i (332 pkts, 0s ago), 35152
bytes_o (338 pkts, 0s ago), rekeying in 9 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: cc5b9dd0_i c3954198_o
vpn1{10}: AES_GCM_12_256, 662792 bytes_i (6373 pkts, 0s ago), 662792
bytes_o (6373 pkts, 0s ago), rekeying in 10 minutes
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64
This is after 22 hours of working tunnel in which for test purposes goes
icmp traffic (~10 requests/sec). As the time goes by, the number of
CHILD_SA created grows up. There is of course only one CHILD_SA just after
the tunnel is established.
I could not find a solution but I've found an option "inactivity" which
"defines the timeout interval, after which a CHILD_SA is closed if it did
not send or receive any traffic". I've got other device with sswan 4.5.2
(wheezy, armel) with inactivity set to 3m and there I do not observe many
CHILD_SA now, but here they are. As I execute "ipsec statusall" every few
seconds I see that only one CHILD_SA is used for traffic at a time and
others have unchanged number of bytes transferred but the time elapsed
since particular CHILD_SA was used is very often 0s after execute "ipsec
statusall" (as you can see above) and is increasing after subsequent calls
but never reaches the 5m, it falls back to 0 after no more than ~200seconds.
The remote device was an ikev2 initiator.
Does anyone know what might be causing the problem?
Normally I am using longer key life times but they were shortened during
the tests which probably increase the number of CHILD_SA in a particular
period of time.
Configurations:
remote device config:
conn vpn1
left=2001:db8:de5c::134
right=2001:db8:cab1::201
rightsubnet=2001:db8:cab2::201/64
ike=aes256gcm12-aes256-sha256-modp2048!
esp=aes256gcm12-aes256-sha256-modp2048!
keyexchange=ikev2
ikelifetime=100m
lifetime=30m
inactivity=5m
reauth=no
rekeymargin=300s
rekeyfuzz=100%
mobike=no
auto=route
reqid=10
leftauth=pubkey
rightauth=pubkey
leftcert=d1.crt
rightid="C=AA, O=Test-co, CN=dev2"
leftid="C=AA, O=Test-co, CN=dev1"
gate config:
conn toClient1-ipv6
left=2001:db8:cab1::201
leftsubnet=2001:db8:cab2::/64
right=2001:db8:de5c::134
ike=aes256gcm16-sha512-modp2048!
esp=aes256gcm12-sha256-modp2048!
keyexchange=ikev2
ikelifetime=180m
lifetime=60m
rekeymargin=300s
rekeyfuzz=100%
mobike=no
auto=route
leftauth=pubkey
rightauth=pubkey
rightid="%any"
leftcert=gate.crt
reqid=10
[Attachment #5 (text/html)]
<div dir="ltr">Hi all,<br><br> I am facing some problems with strongswan 4.5.2 or \
5.2.1 (currenty tested) on debian wheezy (armel). One of these problems is having \
multiple CHILD_SA created under Security Association<br><br> For example, fragment \
of the output from "ipsec statusall" taken from remote device looks like \
this:<br> <br> Security Associations (1 up, 0 connecting):<br> \
vpn1[17]: ESTABLISHED 33 minutes ago, 2001:db8:de5c::134[C=AA, O=Test-co, \
CN=dev1]...2001:db8:cab1::201[C=AA, O=Test-co, CN=dev2]<br> vpn1[17]: IKEv2 SPIs: \
6e7520807913c57c_i* 404ad97e8447df4a_r, rekeying in 60 minutes, public key \
reauthentication in 2 hours<br> vpn1[17]: IKE proposal: \
AES_GCM_16_256/PRF_HMAC_SHA2_512/MODP_2048<br> vpn1{10}: INSTALLED, TUNNEL, ESP \
SPIs: c947dd26_i c85fc3c0_o<br> vpn1{10}: AES_GCM_12_256, 2496 bytes_i (24 \
pkts, 0s ago), 3120 bytes_o (30 pkts, 0s ago), rekeying in 9 minutes<br> \
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64<br> vpn1{10}: \
INSTALLED, TUNNEL, ESP SPIs: c04a385a_i cdcc2a4b_o<br> vpn1{10}: \
AES_GCM_12_256, 23296 bytes_i (224 pkts, 0s ago), 23920 bytes_o (230 pkts, 0s ago), \
rekeying in 7 minutes<br> vpn1{10}: 2001:db8:de5c::134/128 === \
2001:db8:cab2::/64<br> vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c09d50d8_i \
c72fefde_o<br> vpn1{10}: AES_GCM_12_256, 16016 bytes_i (154 pkts, 0s ago), \
16640 bytes_o (160 pkts, 0s ago), rekeying in 10 minutes<br> vpn1{10}: \
2001:db8:de5c::134/128 === 2001:db8:cab2::/64<br> vpn1{10}: INSTALLED, TUNNEL, \
ESP SPIs: ce87de01_i c0bd6c13_o<br> vpn1{10}: AES_GCM_12_256, 23088 bytes_i \
(222 pkts, 0s ago), 23816 bytes_o (229 pkts, 0s ago), rekeying in 8 minutes<br> \
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64<br> vpn1{10}: \
INSTALLED, TUNNEL, ESP SPIs: c83839f6_i c5bee9c4_o<br> vpn1{10}: \
AES_GCM_12_256, 2392 bytes_i (23 pkts, 0s ago), 3120 bytes_o (30 pkts, 0s ago), \
rekeying in 10 minutes<br> vpn1{10}: 2001:db8:de5c::134/128 === \
2001:db8:cab2::/64<br> vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: c4f3ff51_i \
ce1cb4f4_o<br> vpn1{10}: AES_GCM_12_256, 40872 bytes_i (393 pkts, 0s ago), \
41600 bytes_o (400 pkts, 0s ago), rekeying in 9 minutes<br> vpn1{10}: \
2001:db8:de5c::134/128 === 2001:db8:cab2::/64<br> vpn1{10}: INSTALLED, TUNNEL, \
ESP SPIs: cce7630b_i c125f156_o<br> vpn1{10}: AES_GCM_12_256, 10712 bytes_i \
(103 pkts, 0s ago), 11440 bytes_o (110 pkts, 0s ago), rekeying in 11 minutes<br> \
vpn1{10}: 2001:db8:de5c::134/128 === 2001:db8:cab2::/64<br> vpn1{10}: \
INSTALLED, TUNNEL, ESP SPIs: c106eb4e_i cdeae2d2_o<br> vpn1{10}: \
AES_GCM_12_256, 34528 bytes_i (332 pkts, 0s ago), 35152 bytes_o (338 pkts, 0s ago), \
rekeying in 9 minutes<br> vpn1{10}: 2001:db8:de5c::134/128 === \
2001:db8:cab2::/64<br> vpn1{10}: INSTALLED, TUNNEL, ESP SPIs: cc5b9dd0_i \
c3954198_o<br> vpn1{10}: AES_GCM_12_256, 662792 bytes_i (6373 pkts, 0s ago), \
662792 bytes_o (6373 pkts, 0s ago), rekeying in 10 minutes<br> vpn1{10}: \
2001:db8:de5c::134/128 === 2001:db8:cab2::/64<br><br><br> This is after 22 hours \
of working tunnel in which for test purposes goes icmp traffic (~10 requests/sec). As \
the time goes by, the number of CHILD_SA created grows up. There is of course only \
one CHILD_SA just after the tunnel is established.<br> I could not find a \
solution but I've found an option "inactivity" which "defines the \
timeout interval, after which a CHILD_SA is closed if it did not send or receive any \
traffic". I've got other device with sswan 4.5.2 (wheezy, armel) with \
inactivity set to 3m and there I do not observe many CHILD_SA now, but here they are. \
As I execute "ipsec statusall" every few seconds I see that only one \
CHILD_SA is used for traffic at a time and others have unchanged number of bytes \
transferred but the time elapsed since particular CHILD_SA was used is very often 0s \
after execute "ipsec statusall" (as you can see above) and is increasing \
after subsequent calls but never reaches the 5m, it falls back to 0 after no more \
than ~200seconds.<br> <br> The remote device was an ikev2 initiator.<br> \
<br> Does anyone know what might be causing the problem?<br> <br> \
Normally I am using longer key life times but they were shortened during the tests \
which probably increase the number of CHILD_SA in a particular period of time.<br> \
<br> Configurations:<br> <br> remote device config:<br> <br>conn \
vpn1<br> left=2001:db8:de5c::134<br> \
right=2001:db8:cab1::201<br> rightsubnet=2001:db8:cab2::201/64<br> \
ike=aes256gcm12-aes256-sha256-modp2048!<br> \
esp=aes256gcm12-aes256-sha256-modp2048!<br> keyexchange=ikev2<br> \
ikelifetime=100m<br> lifetime=30m<br> inactivity=5m<br> \
reauth=no<br> rekeymargin=300s<br> rekeyfuzz=100%<br> \
mobike=no<br> auto=route<br> reqid=10<br> \
leftauth=pubkey<br> rightauth=pubkey<br> \
leftcert=d1.crt<br> rightid="C=AA, O=Test-co, CN=dev2"<br> \
leftid="C=AA, O=Test-co, CN=dev1"<br><br><br> <br>gate config: \
<br> <br> conn toClient1-ipv6<br> left=2001:db8:cab1::201<br> \
leftsubnet=2001:db8:cab2::/64<br> right=2001:db8:de5c::134<br> \
ike=aes256gcm16-sha512-modp2048!<br> \
esp=aes256gcm12-sha256-modp2048!<br> keyexchange=ikev2<br> \
ikelifetime=180m<br> lifetime=60m<br> \
rekeymargin=300s<br> rekeyfuzz=100%<br> mobike=no<br> \
auto=route<br> leftauth=pubkey<br> rightauth=pubkey<br> \
rightid="%any"<br> leftcert=gate.crt<br> \
reqid=10<br><br><br></div>
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic