[strongSwan] Multiple Child SA after only 14 minutes
Noel Kuntze
noel at familie-kuntze.de
Tue Feb 10 01:02:17 CET 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Tom,
In a roadwarrior scenario, you would place the "dpdaction=restart"
directive on the roadwarrior and the "dpdaction=clear" directive
on the IKE responder. The reason for that is, that the IKE connection
between the roadwarrior and the responder will be severed if the roadwarrior changes IPs
(in a mobile network or changing wireless networks, MOBIKE can not work around that.)
only the roadwarrior would have knowledge of its IP or logical network location,
not the responder, so he has to reestablish the connection.
If you have a site-to-site tunnel, you also need to take into consideration
if any side has (carrier grade) NAT (Network Address Translation) to the WAN (Wide Area Network, e.g. the
Internet). The side that has the NAT needs to have the dpdaction=restart, to reestablish the connection in case
the side's dynamic IP fails. Also, the nat mapping might vanish, so remote traffic won't go through the NAT gateway
and firewall, if it sends packets earlier than the local IKE initiator on the NATed side.
This advice applies to all connections and is good advice in general.
Furthermore, please take care to always address the list as well, not just me.
Mit freundlichen Grüßen/Regards,
Noel Kuntze
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Am 10.02.2015 um 00:39 schrieb trymes at rymes.com:
> Thanks, Noel. I will do that. Would it make sense to place the restart in the end that generally initiates data transfers (ie: users) or the end that serves those requests? Or does it not matter?
>
> Lastly, is this advice only recommended for connections with auto=route or is it also good practice in general?
>
> Thanks again,
>
> Tom
>
>
>> On Feb 9, 2015, at 3:44 PM, Noel Kuntze <noel at familie-kuntze.de> wrote:
>>
>>
> Hello Tom,
>
> The reason for your problem is probably the "dpdaction=restart".
> Having it on both sides causes the creation of duplicate IKE or CHILD_SAs.
> Please change the "dpdaction=restart" on one side to "dpdaction=clear".
>
> Mit freundlichen Grüßen/Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> >>> Am 09.02.2015 um 20:33 schrieb Tom Rymes:
> >>> Thanks, Noel,
> >>>
> >>> I think I may have narrowed this down to an issue where one of the devices loses internet connectivity periodically, for unknown reasons. This has happened in two different locations with similar situation, so I don't think it's a physical problem, it almost seems as if something is causing the machine to become non-responsive. Both machines are IPFire distro boxes running Strongswan (one 5.2.0, one 5.2.1).
> >>>
> >>> Here are the configs (/etc/ipsec.user.conf is empty on both machines):
> >>>
> >>> Host A ipsec.conf (the relevant part, there are a number of other tunnels on this machine):
> >>>
> >>> version 2
> >>>
> >>> conn %default
> >>> keyingtries=%forever
> >>>
> >>> include /etc/ipsec.user.conf
> >>>
> >>> conn HudsonNew
> >>> left=ipa.ddr.ess.a
> >>> leftsubnet=10.100.0.0/23
> >>> leftfirewall=yes
> >>> lefthostaccess=yes
> >>> right=ipa.ddr.ess.b
> >>> rightsubnet=192.168.0.0/21
> >>> leftcert=/var/ipfire/certs/hostcert.pem
> >>> rightcert=/var/ipfire/certs/hostbcert.pem
> >>> leftid="@hosta"
> >>> rightid="@hostb"
> >>>
> >>> ike=aes256-sha2_256-ecp512bp,aes256-sha2_256-ecp384bp,aes256-sha2_256-ecp256bp,aes256-sha2_256-ecp224bp,aes256-sha-ecp512bp,aes256-sha-ecp384bp,aes256-sha-ecp256bp,aes256-sha-ecp224bp,aes192-sha2_256-ecp512bp,aes192-sha2_256-ecp384bp,aes192-sha2_256-ecp256bp,aes192-sha2_256-ecp224bp,aes192-sha-ecp512bp,aes192-sha-ecp384bp,aes192-sha-ecp256bp,aes192-sha-ecp224bp,aes128-sha2_256-ecp512bp,aes128-sha2_256-ecp384bp,aes128-sha2_256-ecp256bp,aes128-sha2_256-ecp224bp,aes128-sha-ecp512bp,aes128-sha-ecp384bp,aes128-sha-ecp256bp,aes128-sha-ecp224bp,3des-sha2_256-ecp512bp,3des-sha2_256-ecp384bp,3des-sha2_256-ecp256bp,3des-sha2_256-ecp224bp,3des-sha-ecp512bp,3des-sha-ecp384bp,3des-sha-ecp256bp,3des-sha-ecp224bp
> >>>
> >>> esp=aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes256-sha1,aes256-sha1,aes256-sha1,aes256-sha1,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha1,aes192-sha1,aes192-sha1,aes192-sha1,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha1,aes128-sha1,aes128-sha1,aes128-sha1,3des-sha2_256,3des-sha2_256,3des-sha2_256,3des-sha2_256,3des-sha1,3des-sha1,3des-sha1,3des-sha1
> >>> keyexchange=ikev2
> >>> ikelifetime=3h
> >>> keylife=1h
> >>> compress=yes
> >>> dpdaction=restart
> >>> dpddelay=120
> >>> dpdtimeout=30
> >>> authby=rsasig
> >>> leftrsasigkey=%cert
> >>> rightrsasigkey=%cert
> >>> auto=route
> >>>
> >>> HostB ipsec.conf:
> >>>
> >>> version 2
> >>>
> >>> conn %default
> >>> keyingtries=%forever
> >>>
> >>> include /etc/ipsec.user.conf
> >>>
> >>> conn Data
> >>> left=ipa.ddr.ess.b
> >>> leftsubnet=192.168.0.0/21
> >>> leftfirewall=yes
> >>> lefthostaccess=yes
> >>> right=ipa.ddr.ess.a
> >>> rightsubnet=10.100.0.0/23
> >>> leftcert=/var/ipfire/certs/hostcert.pem
> >>> rightcert=/var/ipfire/certs/Datacert.pem
> >>> leftid="@hostb"
> >>> rightid="@hosta"
> >>>
> >>> ike=aes256-sha2_256-ecp512bp,aes256-sha2_256-ecp384bp,aes256-sha2_256-ecp256bp,aes256-sha2_256-ecp224bp,aes192-sha2_256-ecp512bp,aes192-sha2_256-ecp384bp,aes192-sha2_256-ecp256bp,aes192-sha2_256-ecp224bp,aes128-sha2_256-ecp512bp,aes128-sha2_256-ecp384bp,aes128-sha2_256-ecp256bp,aes128-sha2_256-ecp224bp
> >>>
> >>> esp=aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes256-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes192-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256,aes128-sha2_256
> >>> keyexchange=ikev2
> >>> ikelifetime=8h
> >>> keylife=1h
> >>> compress=yes
> >>> dpdaction=restart
> >>> dpddelay=120
> >>> dpdtimeout=30
> >>> authby=rsasig
> >>> leftrsasigkey=%cert
> >>> rightrsasigkey=%cert
> >>> auto=route
> >>>
> >>> "ipsec statusall" - HostA
> >>>
> >>> Status of IKE charon daemon (strongSwan 5.2.0, Linux 3.10.44-ipfire, i686):
> >>> uptime: 6 days, since Feb 02 18:00:21 2015
> >>> malloc: sbrk 633264, mmap 0, used 466616, free 166648
> >>> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 74
> >>> 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=NH, O=myorg, OU=Engineering Dept, CN=hosta] uses public key authentication
> >>> HostB: cert: "C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hosta"
> >>> HostB: remote: [C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb] uses public key authentication
> >>> HostB: cert: "C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb"
> >>> HostB: child: 10.100.0.0/23 === 192.168.0.0/21 TUNNEL, dpdaction=restart
> >>> <snip other tunnels' info>
> >>> Routed Connections:
> >>> <snip other tunnels' info>
> >>> HostB{97}: ROUTED, TUNNEL
> >>> HostB{97}: 10.100.0.0/23 === 192.168.0.0/21
> >>> Security Associations (18 up, 0 connecting):
> >>> HostB[523]: ESTABLISHED 16 minutes ago, ipa.ddr.ess.a[C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hosta]...ipa.ddr.ess.b[C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb]
> >>> HostB[523]: IKEv2 SPIs: ac9c3903368605b9_i 2ffb3cbb619e2554_r*, public key reauthentication in 2 hours
> >>> HostB[523]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_512_BP
> >>> HostB{97}: INSTALLED, TUNNEL, ESP SPIs: c08b54d4_i c1be347d_o, IPCOMP CPIs: 1cdd_i b684_o
> >>> HostB{97}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i (0 pkts, 78s ago), 0 bytes_o, rekeying in 28 minutes
> >>> HostB{97}: 10.100.0.0/23 === 192.168.0.0/21
> >>> HostB{97}: INSTALLED, TUNNEL, ESP SPIs: c9927655_i c5643be9_o, IPCOMP CPIs: 2482_i 1e6e_o
> >>> HostB{97}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i (0 pkts, 78s ago), 0 bytes_o, rekeying in 31 minutes
> >>> HostB{97}: 10.100.0.0/23 === 192.168.0.0/21
> >>> HostB{97}: INSTALLED, TUNNEL, ESP SPIs: cdf9dd8d_i c8050e08_o, IPCOMP CPIs: 331e_i 25d5_o
> >>> HostB{97}: AES_CBC_256/HMAC_SHA2_256_128, 3085845 bytes_i (9090 pkts, 0s ago), 1143622 bytes_o (9537 pkts, 0s ago), rekeying in 26 minutes
> >>> HostB{97}: 10.100.0.0/23 === 192.168.0.0/21
> >>> <snip other tunnels' info>
> >>>
> >>> "ipsec statusall" for Host B:
> >>>
> >>> Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.10.44-ipfire-pae, i686):
> >>> uptime: 50 minutes, since Feb 09 13:34:00 2015
> >>> malloc: sbrk 396112, mmap 0, used 251616, free 144496
> >>> worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 18
> >>> 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:
> >>> 192.168.0.253
> >>> ipa.ddr.ess.b
> >>> 10.12.0.1
> >>> Connections:
> >>> Data: ipa.ddr.ess.b...ipa.ddr.ess.a IKEv2, dpddelay=120s
> >>> Data: local: [C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb] uses public key authentication
> >>> Data: cert: "C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb"
> >>> Data: remote: [C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hosta] uses public key authentication
> >>> Data: cert: "C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb"
> >>> Data: child: 192.168.0.0/21 === 10.100.0.0/23 TUNNEL, dpdaction=restart
> >>> Routed Connections:
> >>> Data{1}: ROUTED, TUNNEL
> >>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>> Security Associations (1 up, 0 connecting):
> >>> Data[7]: ESTABLISHED 82 seconds ago, ipa.ddr.ess.b[C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hostb]...ipa.ddr.ess.a[C=US, ST=NH, O=myorg, OU=Engineering Dept, CN=hosta]
> >>> Data[7]: IKEv2 SPIs: de7ab61c0ce50234_i 2d475846703f10eb_r*, public key reauthentication in 7 hours
> >>> Data[7]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_512_BP
> >>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: c3198a6b_i c8770892_o, IPCOMP CPIs: 2cc8_i 82ca_o
> >>> Data{1}: AES_CBC_256/HMAC_SHA2_256_128, 100 bytes_i (2 pkts, 0s ago), 607 bytes_o (6 pkts, 0s ago), rekeying in 42 minutes
> >>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: cb7e3ddd_i cacf244e_o, IPCOMP CPIs: b0c5_i 7010_o
> >>> Data{1}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 41 minutes
> >>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: c806c097_i ced98f4d_o, IPCOMP CPIs: c411_i 071a_o
> >>> Data{1}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 41 minutes
> >>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: c981841d_i cce35b12_o, IPCOMP CPIs: 02d3_i a759_o
> >>> Data{1}: AES_CBC_256/HMAC_SHA2_256_128, 9267 bytes_i (97 pkts, 0s ago), 10527 bytes_o (89 pkts, 0s ago), rekeying in 43 minutes
> >>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>>
> >>>
> >>>> On 02/09/2015 1:22 PM, Noel Kuntze wrote:
> >>> Hello Tom,
> >>>
> >>> That looks like a problem on either of the peers involved.
> >>>
> >>> Please post your config, what software the other side uses, a log, preferrably showing the full tunnel setup and the
> >>> messages that show the creation of those duplicate SAs, as well as the output of "ipsec statusall".
> >>>
> >>> Mit freundlichen Grüßen/Regards,
> >>> Noel Kuntze
> >>>
> >>> GPG Key ID: 0x63EC6658
> >>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
> >>>
> >>> Am 09.02.2015 um 19:11 schrieb Tom Rymes:
> >>>>>> I am having some connectivity issues and I am not certain if this is a symptom or the cause. On one of my machines I see the following:
> >>>>>>
> >>>>>> [root at hudson ~]# ipsec status
> >>>>>> Routed Connections:
> >>>>>> Data{1}: ROUTED, TUNNEL
> >>>>>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>>>>> Security Associations (1 up, 0 connecting):
> >>>>>> Data[6]: ESTABLISHED 14 minutes ago, 50.255.159.181[C=US, ST=XX, O=something, OU=Some Dept, CN=hostname.domain.dom]...XX.YY.ZZ.XX[C=US, ST=XX, O=something, OU=Some Dept, CN=domain.dom]
> >>>>>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: c7efeef8_i c583fdba_o, IPCOMP CPIs: bf58_i c959_o
> >>>>>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>>>>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: c5f5025b_i cfeb18ba_o, IPCOMP CPIs: 0a35_i d9e7_o
> >>>>>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>>>>> Data{1}: INSTALLED, TUNNEL, ESP SPIs: c0f0123d_i c9452af2_o, IPCOMP CPIs: 5026_i cc69_o
> >>>>>> Data{1}: 192.168.0.0/21 === 10.100.0.0/23
> >>>>>>
> >>>>>> Why are there three Child SAs installed if the tunnel has only been up for 14 minutes and ikelifetime=8h and keylife=1h?
> >>>>>>
> >>>>>> Tom
> >>>>>> _______________________________________________
> >>>>>> Users mailing list
> >>>>>> Users at lists.strongswan.org
> >>>>>> https://lists.strongswan.org/mailman/listinfo/users
> >>>
> >>>>
> >>>> _______________________________________________
> >>>> Users mailing list
> >>>> Users at lists.strongswan.org
> >>>> https://lists.strongswan.org/mailman/listinfo/users
>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJU2UqGAAoJEDg5KY9j7GZYvYQP/2+FYJUDcGrp+xT671Jz+Ia6
93hOs6sDqVrOWEK3aMuzxBluxarAUzZVYe2XD74JrFyzqKXLdXig3DqTNESd+h2V
trJN4RSJOSZDxsaJ7l1cmTvhc2Dz6GydCG1+G/5+VdNyH5eEJ81tMMc9rSlSxZ5T
CGBQKBnUMNFfmFxAHSv1xhBbpdpmd59lxGLTTR7XtcgaIxfaBCp5cxrMj8aulUdu
oxUUUET6NkSF4HoqeKSHP6sRx3l5Wx4m2GbsRfyTiaHf8cLP6WMzuEHD695Cfad4
HG491qUHtVhjcCDaMui/GvyLtueRPJPQr+zyWo/8VMcOQKkKD5bP7lTRziLJjG+d
5NB0TiMTOWZUCuTNDoZFyvSg1LfXX7zB1n2sRuq+VVpfOUaP9Z9hifPUd/mWb053
lDARx09I1B/pFiN6UILalXhEwclyZW6DNCu9Znh/o5LBYycvSbJoRfpp4+Qdx5YN
2iJ+RVNX0CSKppSQ7ZVQWTG26SHDRglvTBsXGnmEpUx0wJ93uCv+r69Yn940e1AN
0McMWYdlZNPxkhGfOuzBvxFc+Sd3I08/5+Vdlke04Eh4ZxXKL58RBS95IgNdtaLS
20+V7kuN0grmLlZax3BUgouMbg8Jl3jW6WLcKnbgrqzLyEI3xzQPC5U8RwPc6YAY
FgozFEys/Rb8lw96KzVQ
=ZGFm
-----END PGP SIGNATURE-----
More information about the Users
mailing list