[strongSwan] Multiple Child SA after only 14 minutes
trymes at rymes.com
trymes at rymes.com
Thu Feb 12 19:36:33 CET 2015
On Tue, 10 Feb 2015 01:02:17 +0100
Noel Kuntze <noel at familie-kuntze.de> wrote:
<SNIP>
> This advice applies to all connections and is good
>advice in general.
Thanks for the advice (specifically to set only one end of
the tunnel to dpdaction=restart), Noel. I have done this,
but I am still seeing multiple child SAs spring up:
[root at ipfire ~]# ipsec statusall HostB
Status of IKE charon daemon (strongSwan 5.2.0, Linux
3.10.44-ipfire, i686):
uptime: 17 hours, since Feb 11 19:30:06 2015
malloc: sbrk 525200, mmap 0, used 387408, free 137792
worker threads: 11 of 16 idle, 5/0/0/0 working, job
queue: 0/0/0/0, scheduled: 60
loaded plugins: charon curl aes des rc2 sha1 sha2 md5
random nonce x509 revocation constraints pubkey pkcs1
pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt
fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve
socket-default farp stroke updown eap-identity
eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap
xauth-generic xauth-eap xauth-noauth dhcp
Listening IP addresses:
10.100.0.1
IPA.DDR.ESS.A
IPA.DDR.ESS.A2
IPA.DDR.ESS.A3
10.100.1.1
Connections:
HostB: IPA.DDR.ESS.A...IPA.DDR.ESS.B IKEv2,
dpddelay=120s
HostB: local: [C=US, ST=UT, O=MyOrg, OU=Engineering
Dept, CN=MyOrg.com] uses public key authentication
HostB: cert: "C=US, ST=UT, O=MyOrg, OU=Engineering
Dept, CN=MyOrg.com"
HostB: remote: [C=US, ST=UT, O=MyOrg, OU=Engineering
Dept, CN=HostB.MyOrg.com] uses public key authentication
HostB: cert: "C=US, ST=UT, O=MyOrg, OU=Engineering
Dept, CN=HostB.MyOrg.com"
HostB: child: 10.100.0.0/23 === 10.2.0.0/16 TUNNEL,
dpdaction=clear
Routed Connections:
HostB{10}: ROUTED, TUNNEL
HostB{10}: 10.100.0.0/23 === 10.2.0.0/16
Security Associations (15 up, 0 connecting):
HostB[164]: ESTABLISHED 2 hours ago,
IPA.DDR.ESS.A[C=US, ST=UT, O=MyOrg, OU=Engineering Dept,
CN=MyOrg.com]...IPA.DDR.ESS.B[C=US, ST=UT, O=MyOrg,
OU=Engineering Dept, CN=HostB.MyOrg.com]
HostB[164]: IKEv2 SPIs: 1083250bd152df93_i
aa0b0cf822e2a48a_r*, public key reauthentication in 5
hours
HostB[164]: IKE proposal:
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_512_BP
HostB{10}: INSTALLED, TUNNEL, ESP SPIs: ca493aee_i
cd5a7958_o, IPCOMP CPIs: b621_i e57d_o
HostB{10}: AES_CBC_256/HMAC_SHA2_256_128, 530419
bytes_i (3503 pkts, 0s ago), 1580851 bytes_o (3824 pkts,
0s ago), rekeying in 29 minutes
HostB{10}: 10.100.0.0/23 === 10.2.0.0/16
HostB{10}: INSTALLED, TUNNEL, ESP SPIs: c8746473_i
c4dd84bb_o, IPCOMP CPIs: 3ac6_i 3e51_o
HostB{10}: AES_CBC_256/HMAC_SHA2_256_128, 2917676
bytes_i (32813 pkts, 0s ago), 2781420 bytes_o (32677 pkts,
0s ago), rekeying in 31 minutes
HostB{10}: 10.100.0.0/23 === 10.2.0.0/16
HostB{10}: INSTALLED, TUNNEL, ESP SPIs: ca68d731_i
cbc5df84_o, IPCOMP CPIs: 1d57_i 6be8_o
HostB{10}: AES_CBC_256/HMAC_SHA2_256_128, 2658017
bytes_i (28452 pkts, 0s ago), 2816354 bytes_o (28267 pkts,
0s ago), rekeying in 38 minutes
HostB{10}: 10.100.0.0/23 === 10.2.0.0/16
Also, I noticed that these three Child SAs were all set to
expire and they all re-keyed. They will all stay open (and
even multiply) as long as the tunnel stays up. If I force
it down and then bring it back up, it will come back up
with only one SA, and others will show up on a seemingly
random basis. I had originally thought that a new SA was
created each time it rekeyed phase2, but there were three
before the last re-key and three after, so I am not
flummoxed.
Id this just normal behavior, or am I missing something?
The other side looks like this:
[root at HostB ~]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux
3.10.44-ipfire-pae, i686):
uptime: 10 days, since Feb 01 15:21:58 2015
malloc: sbrk 394896, mmap 0, used 242208, free 152688
worker threads: 11 of 16 idle, 5/0/0/0 working, job
queue: 0/0/0/0, scheduled: 6
loaded plugins: charon aes des rc2 sha1 sha2 md5 random
nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8
pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp
xcbc cmac hmac curl attr kernel-netlink resolve
socket-default farp stroke updown eap-identity
eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap
xauth-generic xauth-eap xauth-noauth dhcp
Listening IP addresses:
10.2.0.1
IPA.DDR.ESS.B
Connections:
Data: IPA.DDR.ESS.B...IPA.DDR.ESS.A IKEv2,
dpddelay=120s
Data: local: [C=US, ST=UT, O=MyOrg,
OU=Engineering Dept, CN=HostB.MyOrg.com] uses public key
authentication
Data: cert: "C=US, ST=UT, O=MyOrg,
OU=Engineering Dept, CN=HostB.MyOrg.com"
Data: remote: [C=US, ST=UT, O=MyOrg,
OU=Engineering Dept, CN=MyOrg.com] uses public key
authentication
Data: cert: "C=US, ST=UT, O=MyOrg,
OU=Engineering Dept, CN=MyOrg.com"
Data: child: 10.2.0.0/16 === 10.100.0.0/23
TUNNEL, dpdaction=restart
Routed Connections:
Data{23}: ROUTED, TUNNEL
Data{23}: 10.2.0.0/16 === 10.100.0.0/23
Security Associations (1 up, 0 connecting):
Data[74]: ESTABLISHED 2 hours ago,
IPA.DDR.ESS.B[C=US, ST=UT, O=MyOrg, OU=Engineering Dept,
CN=HostB.MyOrg.com]...IPA.DDR.ESS.A[C=US, ST=UT, O=MyOrg,
OU=Engineering Dept, CN=MyOrg.com]
Data[74]: IKEv2 SPIs: 1083250bd152df93_i*
aa0b0cf822e2a48a_r, public key reauthentication in 4 hours
Data[74]: IKE proposal:
AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_512_BP
Data{23}: INSTALLED, TUNNEL, ESP SPIs:
cd5a7958_i ca493aee_o, IPCOMP CPIs: e57d_i b621_o
Data{23}: AES_CBC_256/HMAC_SHA2_256_128, 1580851
bytes_i (3824 pkts, 0s ago), 530419 bytes_o (3503 pkts, 0s
ago), rekeying in 8 minutes
Data{23}: 10.2.0.0/16 === 10.100.0.0/23
Data{23}: INSTALLED, TUNNEL, ESP SPIs:
c4dd84bb_i c8746473_o, IPCOMP CPIs: 3e51_i 3ac6_o
Data{23}: AES_CBC_256/HMAC_SHA2_256_128, 2781300
bytes_i (32675 pkts, 0s ago), 2917676 bytes_o (32813 pkts,
0s ago), rekeying in 11 minutes
Data{23}: 10.2.0.0/16 === 10.100.0.0/23
Data{23}: INSTALLED, TUNNEL, ESP SPIs:
cbc5df84_i ca68d731_o, IPCOMP CPIs: 6be8_i 1d57_o
Data{23}: AES_CBC_256/HMAC_SHA2_256_128,
11157640 bytes_i (99787 pkts, 0s ago), 9056257 bytes_o
(99744 pkts, 0s ago), rekeying in 14 minutes
Data{23}: 10.2.0.0/16 === 10.100.0.0/23
>Furthermore, please take care to always address the list
>as well, not just me.
Yes, my apologies, I am accustomed to lists that
automatically set the reply-to address to be the list.
Tom
More information about the Users
mailing list