Project

General

Profile

Actions
Copy link

Regression #12052

closed

IPsec status IKE disconnect button drops all connections for the IKE ID, not a specific IKE SA ID

Added by Geovane Gonçalves over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Jim Pingle
Category:
IPsec
Target version:
2.6.0
Start date:
06/17/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.01
Release Notes:
Default
Affected Version:
2.5.1
Affected Architecture:
amd64

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

Actions
Copy link
 #1

Updated by Jim Pingle over 3 years ago

  • Tracker changed from Bug to Regression
  • Assignee set to Jim Pingle

To me for testing/confirmation.

Actions
Copy link
 #2

Updated by Jim Pingle over 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.

Actions
Copy link
 #3

Updated by Jim Pingle over 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Max Leighton over 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.

Actions
Copy link
 #5

Updated by Geovane Gonçalves over 3 years ago

The patch works in my 2.5.1 Version. Thanks.

Geovane

Actions
Copy link
 #6

Updated by Jim Pingle over 3 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #7

Updated by Jim Pingle about 3 years ago

  • Plus Target Version changed from 21.09 to 22.01
Actions
Copy link

Also available in: Atom PDF