pfSense

Jim Pingle wrote:

That page outputs what is given to it by strongSwan. Check the output of "ipsec statusall" from the console when it's in this state and you may see the same extra output, and perhaps why. Attach that output here.

Output is below.


Status of IKE charon daemon (strongSwan 5.5.0, FreeBSD 10.3-RELEASE-p9, amd64):
uptime: 3 days, since Nov 25 14:51:29 2016
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 9
loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 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 vici 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
Listening IP addresses:
130.226.230.201
130.226.230.200
130.226.230.208
130.226.230.204
192.168.17.1
10.4.80.7
10.4.80.6
10.8.0.2
10.8.0.1
10.7.0.2
10.7.0.1
130.226.224.2
130.226.224.1
10.88.4.2
10.88.4.1
10.12.4.21
10.12.4.20
10.106.0.2
10.106.0.1
130.226.228.2
130.226.228.1
130.226.228.66
130.226.228.65
10.5.0.2
10.5.0.1
10.106.100.1
Connections:
bypasslan: %any...%any IKEv1/2
bypasslan: local: uses public key authentication
bypasslan: remote: uses public key authentication
bypasslan: child: 10.106.0.0/22|/0 === 10.106.0.0/22|/0 PASS
con1000: 130.226.230.200...130.225.226.4 IKEv1, dpddelay=10s
con1000: local: [130.226.230.200] uses pre-shared key authentication
con1000: remote: [130.225.226.4] uses pre-shared key authentication
con1000: child: 130.226.220.0/22|/0 === 10.77.0.10/32|/0 TUNNEL, dpdaction=restart
con1001: child: 130.226.220.0/22|/0 === 10.77.0.97/32|/0 TUNNEL, dpdaction=restart
con1002: child: 130.226.220.0/22|/0 === 10.77.128.106/32|/0 TUNNEL, dpdaction=restart
con1003: child: 130.226.220.0/22|/0 === 10.77.160.106/32|/0 TUNNEL, dpdaction=restart
con2000: 130.226.230.200...130.225.247.66 IKEv2, dpddelay=10s
con2000: local: [130.226.230.200] uses pre-shared key authentication
con2000: remote: [130.225.247.66] uses pre-shared key authentication
con2000: child: 10.106.0.0/22|/0 === 130.225.24.0/23|/0 TUNNEL, dpdaction=restart
con2001: child: 10.5.0.0/22|/0 === 172.18.0.0/16|/0 TUNNEL, dpdaction=restart
con2002: child: 10.6.0.0/16|/0 === 130.225.24.0/23|/0 TUNNEL, dpdaction=restart
con2003: child: 130.226.220.0/22|/0 === 172.18.0.0/16|/0 TUNNEL, dpdaction=restart
con2004: child: 130.226.229.0/24|/0 === 130.225.24.0/23|/0 TUNNEL, dpdaction=restart
con2005: child: 130.226.220.0/22|/0 === 130.225.24.0/23|/0 TUNNEL, dpdaction=restart
Shunted Connections:
bypasslan: 10.106.0.0/22|/0 === 10.106.0.0/22|/0 PASS
Routed Connections:
con2005{10}: ROUTED, TUNNEL, reqid 10
con2005{10}: 130.226.220.0/22|/0 === 130.225.24.0/23|/0
con2004{9}: ROUTED, TUNNEL, reqid 9
con2004{9}: 130.226.229.0/24|/0 === 130.225.24.0/23|/0
con2003{8}: ROUTED, TUNNEL, reqid 8
con2003{8}: 130.226.220.0/22|/0 === 172.18.0.0/16|/0
con2002{7}: ROUTED, TUNNEL, reqid 7
con2002{7}: 10.6.0.0/16|/0 === 130.225.24.0/23|/0
con2001{6}: ROUTED, TUNNEL, reqid 6
con2001{6}: 10.5.0.0/22|/0 === 172.18.0.0/16|/0
con2000{5}: ROUTED, TUNNEL, reqid 5
con2000{5}: 10.106.0.0/22|/0 === 130.225.24.0/23|/0
con1003{4}: ROUTED, TUNNEL, reqid 4
con1003{4}: 130.226.220.0/22|/0 === 10.77.160.106/32|/0
con1002{3}: ROUTED, TUNNEL, reqid 3
con1002{3}: 130.226.220.0/22|/0 === 10.77.128.106/32|/0
con1001{2}: ROUTED, TUNNEL, reqid 2
con1001{2}: 130.226.220.0/22|/0 === 10.77.0.97/32|/0
con1000{1}: ROUTED, TUNNEL, reqid 1
con1000{1}: 130.226.220.0/22|/0 === 10.77.0.10/32|/0
Security Associations (1 up, 0 connecting):
con2000[10]: ESTABLISHED 2 hours ago, 130.226.230.200[130.226.230.200]...130.225.247.66[130.225.247.66]
con2000[10]: IKEv2 SPIs: 1855656b8087ac0f_i* 91e33ac00125aa95_r, pre-shared key reauthentication in 21 hours
con2000[10]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
con2005{78}: INSTALLED, TUNNEL, reqid 10, ESP SPIs: c58717b8_i 9a2a0a1d_o
con2005{78}: AES_CBC_256/HMAC_MD5_96, 1160152 bytes_i (5994 pkts, 9s ago), 1266576 bytes_o (4882 pkts, 9s ago), rekeying in 5 hours
con2005{78}: 130.226.220.0/22|/0 === 130.225.24.0/23|/0
con2004{79}: INSTALLED, TUNNEL, reqid 9, ESP SPIs: caa9faf7_i 6c516f7d_o
con2004{79}: AES_CBC_256/HMAC_MD5_96, 92662978 bytes_i (557758 pkts, 0s ago), 150988840 bytes_o (748379 pkts, 0s ago), rekeying in 5 hours
con2004{79}: 130.226.229.0/24|/0 === 130.225.24.0/23|/0
con2002{80}: INSTALLED, TUNNEL, reqid 7, ESP SPIs: c84bd60e_i 1c04dbb3_o
con2002{80}: AES_CBC_256/HMAC_MD5_96, 15053882 bytes_i (16226 pkts, 2s ago), 2180616 bytes_o (8887 pkts, 2s ago), rekeying in 5 hours
con2002{80}: 10.6.0.0/16|/0 === 130.225.24.0/23|/0


I've seen a similar issue on a production system with IKEv2 and split connections ticked (Enable this to split connection entries with multiple phase 2 configurations. Required for remote endpoints that support only a single traffic selector per child SA.)

Attempting to reproduce on a couple of test systems.

Suspect either getting bad data in response to list-sa or build_ipsec_sa_array is mangling something. But that's just a guess at this point.

Reproduced issue with two test VMs. Setup a simple IKEv2 between the two with one child sa. When split connections is ticked the problem appears. Take split connections off, disconnect and connect the vpn and the status page looks normal.

Looks like this is caused because there's a mismatch between the ikeid in $config['ipsec']['phase1'] and the ikeid returned by ipsec_list_sa.
In this case the config says id 1 and list_sa says id 1000.

This means that ipsec_get_descr can't find a description for id 1000
Then id 1 is seen as disconnected and output by the second part of print_ipsec_body

pull request for fix on github
https://github.com/pfsense/pfsense/pull/3522