Multiple Phase 2 SA in pfSense 2.2.3
-
I have 2 issues to report and I'm using IKEv2 for tunnels:
1. Phase 2 SAs are not properly expiring
2. Cannot delete phase 2 SAs from the web pageIssue #1
pfSense 2.2.3 fixed some issues I was having using GRE over IPsec, tunnels come up now and remain stable. However it seems as though there is still an issue with phase 2 SAs where they don't expire properly. I am using IKEv2. Phase 1 rekeys every 24 hours, phase 2 rekeys every hour.
The tunnel I tested was up for almost a week, and had 5 phase 2 SAs which built up slowly over the course of the week. At no point was the tunnel inoperative, traffic still flowed through the tunnel and the other side of the tunnel wasn't seeing the additional SAs, only one of them was valid. However I think this behavior will eventually lead to an outage of the tunnel.
I found a few issues related to strongSwan that might explain the leftover phase 2 SAs. It has something to do with how the kernel is notifying on an expired SA. I post them for reference to validate if they have been included or are applicable in pfSense:
https://wiki.strongswan.org/issues/951
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200282
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200283Issue #2
I attempted to delete the SAs that should have expired manually, but am unable to do so. Also, if I attempt to delete an active phase 2 SA, it is the same result. The web page refreshes, but the SA remains. I checked in the IPsec log and found this any time I attempt to delete a phase 2 SA (regardless if active or expired):
Jul 11 07:28:21 charon: 11[CFG] received stroke: terminate 'con2{3}' Jul 11 07:28:21 charon: 12[IKE] unable to terminate, CHILD_SA with ID 3 not found Jul 11 07:28:21 charon: 12[IKE] unable to terminate, CHILD_SA with ID 3 not found
I reset phase 1, and the phase 2 SAs were cleared (and I'm kicking myself for not getting a screen shot of it first).
-
The links from issue #1 were confirmed fixed in 2.2.3. That sounds like it could be a similar issue though with a different root cause possibly. What does the output of 'ipsec statusall' show when you have additional SAs there?
-
Good to know on #1, I read in the release notes that multiple SAs were fixed and was surprised to see them.
Here is the output of the 'ipsec statusall' command. I sanitized the output to remove IPs with generic tags. I am using GRE over IPsec in this config, so WAN IPs on both ends of the tunnel are used. The req ID seems to match for both phase 2 entries.
Status of IKE charon daemon (strongSwan 5.3.2, FreeBSD 10.1-RELEASE-p13, amd64): uptime: 7 days, since Jul 07 06:29:17 2015 worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 5 loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke smp updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unity Listening IP addresses: WAN_IP LAN_IP GRE0_IP GRE1_IP Connections: bypasslan: %any...%any IKEv1/2 bypasslan: local: uses public key authentication bypasslan: remote: uses public key authentication bypasslan: child: LAN_IP/32|/0 === LAN_SUBNET/24|/0 PASS con2: WAN_IP...REMOTE_VPN_IP IKEv2, dpddelay=10s con2: local: [WAN_IP] uses pre-shared key authentication con2: remote: [REMOTE_VPN_IP] uses pre-shared key authentication con2: child: WAN_IP/32|/0 === REMOTE_VPN_IP/32|/0 TRANSPORT, dpdaction=restart Shunted Connections: bypasslan: LAN_IP/32|/0 === LAN_SUBNET/24|/0 PASS Routed Connections: con2{673}: ROUTED, TRANSPORT, reqid 3 con2{673}: WAN_IP/32|/0 === REMOTE_VPN_IP/32|/0 Security Associations (1 up, 0 connecting): con2[259]: ESTABLISHED 2 hours ago, WAN_IP[WAN_IP]...REMOTE_VPN_IP[REMOTE_VPN_IP] con2[259]: IKEv2 SPIs: d9c66224642e44f1_i* 556a40596a638866_r, pre-shared key reauthentication in 21 hours con2[259]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 con2{681}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: c9c0c968_i 0998556b_o con2{681}: AES_CBC_256/HMAC_SHA1_96, 5140 bytes_i (45 pkts, 5s ago), 0 bytes_o, rekeying in 13 minutes con2{681}: WAN_IP/32|/0 === REMOTE_VPN_IP/32|/0 con2{682}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: c3994c0a_i 0b20ac51_o con2{682}: AES_CBC_256/HMAC_SHA1_96, 395804 bytes_i (3468 pkts, 1s ago), 551528 bytes_o (3445 pkts, 1s ago), rekeying in 19 minutes con2{682}: WAN_IP/32|/0 === REMOTE_VPN_IP/32|/0
-
I didn't include Phase1/2 timeouts previously. Phase 1 is 86400 seconds, Phase 2 is 3600 seconds. Let me know if there is any other info I need to dump out to post. I'll keep my own speculation to a minimum and report findings.
It seems like another Phase 2 SA is added every 2-3 days. I put together another output from 'ipsec statusall' similar to the previous post, 2 days afterwards. The tunnel was not reset on either side in this time frame and another Phase 2 SA was added. (3 total) The last Phase 2 SA with lines starting with "con2{932}" is the active SA and is the only SA on the other end of the tunnel.
I can wait another few days and post more output to see if the last Phase 2 SA is the active one and we have more than 3 Phase 2 SAs.
Status of IKE charon daemon (strongSwan 5.3.2, FreeBSD 10.1-RELEASE-p13, amd64): uptime: 10 days, since Jul 07 06:29:17 2015 worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 3 loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke smp updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unity Listening IP addresses: WAN_IP LAN_IP GRE0_IP GRE1_IP Connections: bypasslan: %any...%any IKEv1/2 bypasslan: local: uses public key authentication bypasslan: remote: uses public key authentication bypasslan: child: LAN_IP/32|/0 === LAN_SUBNET/24|/0 PASS con2: WAN_IP...REMOTE_WAN_IP IKEv2, dpddelay=10s con2: local: [WAN_IP] uses pre-shared key authentication con2: remote: [REMOTE_WAN_IP] uses pre-shared key authentication con2: child: WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0 TRANSPORT, dpdaction=restart Shunted Connections: bypasslan: LAN_IP/32|/0 === LAN_SUBNET/24|/0 PASS Routed Connections: con2{918}: ROUTED, TRANSPORT, reqid 3 con2{918}: WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0 Security Associations (1 up, 0 connecting): con2[264]: ESTABLISHED 16 hours ago, WAN_IP[WAN_IP]...REMOTE_WAN_IP[REMOTE_WAN_IP] con2[264]: IKEv2 SPIs: 18e88abe7009344e_i* 59878b639d3fc838_r, pre-shared key reauthentication in 7 hours con2[264]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 con2{930}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: cf75d264_i 0f545298_o con2{930}: AES_CBC_256/HMAC_SHA1_96, 6688 bytes_i (54 pkts, 10s ago), 0 bytes_o, rekeying in 20 minutes con2{930}: WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0 con2{931}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: ce9b2f7f_i 09b24fbe_o con2{931}: AES_CBC_256/HMAC_SHA1_96, 22796 bytes_i (184 pkts, 10s ago), 0 bytes_o, rekeying in 21 minutes con2{931}: WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0 con2{932}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: cf4df9d9_i 0567be16_o con2{932}: AES_CBC_256/HMAC_SHA1_96, 141348 bytes_i (1141 pkts, 1s ago), 189168 bytes_o (1126 pkts, 1s ago), rekeying in 27 minutes con2{932}: WAN_IP/32|/0 === REMOTE_WAN_IP/32|/0