Project

General

Profile

Bug #6966

Display bug in Status / IPsec / Overview

Added by Lars Jorgensen 5 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Low
Category:
IPsec
Target version:
Start date:
11/28/2016
Due date:
% Done:

100%

Affected version:
2.3.2
Affected Architecture:
i386

Description

I have to IPsec tunnels configured. If one goes up, it is reported as both connected and disconnected in two separate entries. Screenshot attached. That sad red line is supposed to point to the identical entries.

ipsec overview bug.png (94.7 KB) Lars Jorgensen, 11/28/2016 06:09 AM

status_ipsec.patch Magnifier (870 Bytes) Graham Collinson, 02/10/2017 06:44 AM

History

#1 Updated by Jim Pingle 5 months ago

  • Status changed from New to Feedback

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.

If it is not actually a normal/expected state output in "ipsec statusall" then it may need pursued upstream with strongSwan.

#2 Updated by Lars Jorgensen 5 months ago

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

#3 Updated by Graham Collinson 3 months ago

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.

#4 Updated by Graham Collinson 3 months ago

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.

#5 Updated by Graham Collinson 3 months ago

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

#6 Updated by Graham Collinson 3 months ago

This simple patch appears to work.
Might want to add in further checking or change the way of identifying whether its an ikev2 with a split connection.

(status_ipsec in /usr/local/www)

#7 Updated by Graham Collinson 3 months ago

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

#8 Updated by Jim Pingle 3 months ago

  • Status changed from Feedback to New
  • Target version set to 2.4.0

#9 Updated by Renato Botelho 3 months ago

  • Status changed from New to Feedback
  • Assignee set to Renato Botelho
  • Target version changed from 2.4.0 to 2.3.3
  • % Done changed from 0 to 100

PR has been merged, thanks!

#10 Updated by Renato Botelho 3 months ago

  • Status changed from Feedback to Resolved

works

Also available in: Atom PDF