Regression #12052
closed
IPsec status IKE disconnect button drops all connections for the IKE ID, not a specific IKE SA ID
100%
Description
Plataform:
Version 2.5.1-RELEASE (amd64) on VMWare
built on Mon Apr 12 07:50:14 EDT 2021
FreeBSD 12.2-STABLE
FreeBSD strongSwan U5.9.1/K12.2-STABLE
Description:
Menu Status->IPSec->Overview, "Disconnect Button" should only disconnect one user but it is dropping all mobile active connections (hundreds).
The problem occurred after upgrading from version 2.4.5 to 2.5.1.
We did a test in a second instance of PfSense and the problem repeated itself. The problem occurred on two different VPNs servers with the same version of PFSense.
Also, we tested killing a connection with the command "swanctl -t" and it worked perfectly, dropping only the target connection and not the others , as it happens in the PfSense GUI:
swanctl -t --ike-id 3880
[IKE] deleting IKE_SA con-mobile3880 between [x.x.x.x]...y.y.y.y
[IKE] sending DELETE for IKE_SA con-mobile3880
[ENC] generating INFORMATIONAL request 2 [ D ]
[NET] sending packet: from x.x.x.x4500 to y.y.y.y4500 (80 bytes)
[NET] received packet: from y.y.y.y4500 to x.x.x.x4500 (80 bytes)
[ENC] parsed INFORMATIONAL response 2 [ ]
[IKE] IKE_SA deleted
terminate completed successfully
So far, evidence seems to point to a BUG in PfSense management scripts.
Thanks,
Geovane
Jun 15 10:02:14 vpn4 charon71011: 15[IKE] <con-mobile|2722> sending DELETE for IKE_SA con-mobile2722
Jun 15 10:02:14 vpn4 charon71011: 13[IKE] <con-mobile|2690> sending DELETE for IKE_SA con-mobile2690
Jun 15 10:02:14 vpn4 charon71011: 07[IKE] <con-mobile|2642> sending DELETE for IKE_SA con-mobile2642
Jun 15 10:02:15 vpn4 charon71011: 12[IKE] <con-mobile|2602> sending DELETE for IKE_SA con-mobile2602
Jun 15 10:02:15 vpn4 charon71011: 11[IKE] <con-mobile|2592> sending DELETE for IKE_SA con-mobile2592
Jun 15 10:02:15 vpn4 charon71011: 11[IKE] <con-mobile|2924> sending DELETE for IKE_SA con-mobile2924
Jun 15 10:02:15 vpn4 charon71011: 11[IKE] <con-mobile|2922> sending DELETE for IKE_SA con-mobile2922
Jun 15 10:02:15 vpn4 charon71011: 07[IKE] <con-mobile|2889> sending DELETE for IKE_SA con-mobile2889
Jun 15 10:02:15 vpn4 charon71011: 10[IKE] <con-mobile|2884> sending DELETE for IKE_SA con-mobile2884
Jun 15 10:02:15 vpn4 charon71011: 07[IKE] <con-mobile|2882> sending DELETE for IKE_SA con-mobile2882
Jun 15 10:02:15 vpn4 charon71011: 07[IKE] <con-mobile|2859> sending DELETE for IKE_SA con-mobile2859
Jun 15 10:02:15 vpn4 charon71011: 15[IKE] <con-mobile|2820> sending DELETE for IKE_SA con-mobile2820
Jun 15 10:02:15 vpn4 charon71011: 13[IKE] <con-mobile|2812> sending DELETE for IKE_SA con-mobile2812
Jun 15 10:02:15 vpn4 charon71011: 13[IKE] <con-mobile|2798> sending DELETE for IKE_SA con-mobile2798
Jun 15 10:02:15 vpn4 charon71011: 08[IKE] <con-mobile|2650> sending DELETE for IKE_SA con-mobile2650
Jun 15 10:02:15 vpn4 charon71011: 06[IKE] <con-mobile|2613> sending DELETE for IKE_SA con-mobile2613
Jun 15 10:02:15 vpn4 charon71011: 12[IKE] <con-mobile|2909> sending DELETE for IKE_SA con-mobile2909
Jun 15 10:02:15 vpn4 charon71011: 10[IKE] <con-mobile|2878> sending DELETE for IKE_SA con-mobile2878
Jun 15 10:02:15 vpn4 charon71011: 09[IKE] <con-mobile|2857> sending DELETE for IKE_SA con-mobile2857
Jun 15 10:02:15 vpn4 charon71011: 11[IKE] <con-mobile|2836> sending DELETE for IKE_SA con-mobile2836
Jun 15 10:02:15 vpn4 charon71011: 07[IKE] <con-mobile|2827> sending DELETE for IKE_SA con-mobile2827
Jun 15 10:02:15 vpn4 charon71011: 09[IKE] <con-mobile|2819> sending DELETE for IKE_SA con-mobile2819
Jun 15 10:02:15 vpn4 charon71011: 09[IKE] <con-mobile|2794> sending DELETE for IKE_SA con-mobile2794
Jun 15 10:02:15 vpn4 charon71011: 09[IKE] <con-mobile|2727> sending DELETE for IKE_SA con-mobile2727
Jun 15 10:02:15 vpn4 charon71011: 10[IKE] <con-mobile|2579> sending DELETE for IKE_SA con-mobile2579
Jun 15 10:02:15 vpn4 charon71011: 10[IKE] <con-mobile|2903> sending DELETE for IKE_SA con-mobile2903
Jun 15 10:02:15 vpn4 charon71011: 11[IKE] <con-mobile|2890> sending DELETE for IKE_SA con-mobile2890
Jun 15 10:02:15 vpn4 charon71011: 13[IKE] <con-mobile|2875> sending DELETE for IKE_SA con-mobile2875
Jun 15 10:02:16 vpn4 charon71011: 06[IKE] <con-mobile|2874> sending DELETE for IKE_SA con-mobile2874
Jun 15 10:02:16 vpn4 charon71011: 06[IKE] <con-mobile|2809> sending DELETE for IKE_SA con-mobile2809
Updated by Jim Pingle almost 3 years ago
- Tracker changed from Bug to Regression
- Assignee set to Jim Pingle
To me for testing/confirmation.
Updated by Jim Pingle almost 3 years ago
- Subject changed from Status/IPsec/Overview mobile client "Disconnect Button" is dropping all active connections to IPsec status IKE disconnect button drops all connections for the IKE ID, not a specific IKE SA ID
- Status changed from New to In Progress
- Target version set to 2.6.0
- Plus Target Version set to 21.09
Looks like the behavior in strongSwan changed slightly. We are running this command:
/usr/local/sbin/swanctl --terminate --ike <p1 name, e.g. con-mobile> --ike-id <number>
That should be narrowing it down to only that ID number within connections matching that IKE name, but it appears to be treating it as an 'or' now instead of an 'and'. So when that command is run, it's killing anything under con-mobile. The same would happen for any IKE, but it's more obvious on con-mobile. For example if another tunnel has two IKE SAs open unintentionally and you want to clear an old/invalid one, it would kill both.
The IKE SA ID number we use for --ike-id is globally unique so as far as I can see it is safe to only use this command:
/usr/local/sbin/swanctl --terminate --ike-id <number>
Using that method only kills the one specific client in each case I've tested.
When terminating a child SA the behavior still appears to be the old way, but I'll update that as well in case strongSwan decides to "fix" that path the same way.
Patch coming soon.
Updated by Jim Pingle almost 3 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset 6cfa9d7498be390314b93fa40aea1704eb5a8eae.
Updated by Max Leighton almost 3 years ago
Tested in
21.09-DEVELOPMENT (arm64)
built on Sat Jul 24 01:10:30 EDT 2021
FreeBSD 12.2-STABLE
It works. I am able to disconnect a single user from Status>IPsec and other users will stay connected. I'll leave the ticket open to test in CE.
Updated by Geovane Gonçalves over 2 years ago
The patch works in my 2.5.1 Version. Thanks.
Geovane
Updated by Jim Pingle over 2 years ago
- Plus Target Version changed from 21.09 to 22.01