Bug #15171
closed
Removing an IPsec Phase 1 entry can either remove the wrong Phase 2 entries or leave orphaned Phase 2 entries in the configuration
Added by Roland Kletzing 11 months ago. Updated 8 months ago.
100%
Description
when deleting p1 entry in ipsec, p2 entries below some totally unrelated p1 entry also being deletet
see reports at https://forum.netgate.com/topic/185385/bug-ipsec-p1-entry-deletion-deletes-all-p2-entries-from-another-p1-entry
Files
| clipboard-202401190855-xjdsk.png (250 KB) clipboard-202401190855-xjdsk.png | Danilo Zrenjanin, 01/19/2024 07:55 AM | ||
| clipboard-202401190857-1v8rd.png (120 KB) clipboard-202401190857-1v8rd.png | Danilo Zrenjanin, 01/19/2024 07:57 AM | ||
| IPSEC_BUG_disappear.mp4 (1.48 MB) IPSEC_BUG_disappear.mp4 | DBACORP DBACORP, 02/21/2024 04:37 PM |
Related issues
Updated by Danilo Zrenjanin 11 months ago
- Status changed from New to Confirmed
Tested against:
23.09.1-RELEASE (amd64) built on Wed Dec 20 18:27:00 UTC 2023 FreeBSD 14.0-CURRENT
I can confirm this behavior.
Updated by Danilo Zrenjanin 11 months ago
The IPsec config before removing the second Phase 1.
# This file is automatically generated. Do not edit
connections {
bypass {
remote_addrs = 127.0.0.1
children {
bypasslan {
local_ts = 192.168.10.0/24
remote_ts = 192.168.10.0/24
mode = pass
start_action = trap
}
}
}
con1 {
# P1 (ikeid 1): Node1
fragmentation = yes
unique = replace
version = 2
proposals = aes128-sha256-modp2048
dpd_delay = 10s
rekey_time = 25920s
reauth_time = 0s
over_time = 2880s
rand_time = 2880s
encap = no
mobike = no
local_addrs = 192.168.33.10
remote_addrs = 192.168.33.20
local {
id = 192.168.33.10
auth = psk
}
remote {
id = 192.168.33.20
auth = psk
}
children {
con1 {
# P2 (reqid 2): tunnel2Node1
# P2 (reqid 1): phase1Node1
mode = tunnel
policies = yes
life_time = 3600s
rekey_time = 3240s
rand_time = 360s
start_action = trap
remote_ts = 192.168.20.0/24,192.168.21.0/24
local_ts = 192.168.10.0/24,192.168.10.0/24
esp_proposals = aes128gcm128-modp2048,aes128-sha256-modp2048
dpd_action = trap
}
}
}
con2 {
# P1 (ikeid 2): Node2
fragmentation = yes
unique = replace
version = 2
proposals = aes128-sha256-modp2048
dpd_delay = 10s
rekey_time = 25920s
reauth_time = 0s
over_time = 2880s
rand_time = 2880s
encap = no
mobike = no
local_addrs = 192.168.33.10
remote_addrs = 192.168.33.30
local {
id = 192.168.33.10
auth = psk
}
remote {
id = 192.168.33.30
auth = psk
}
children {
con2 {
# P2 (reqid 4): tunnel2Node2
# P2 (reqid 3): tunnel1Node2
mode = tunnel
policies = yes
life_time = 3600s
rekey_time = 3240s
rand_time = 360s
start_action = trap
remote_ts = 192.168.30.0/24,192.168.31.0/24
local_ts = 192.168.10.0/24,192.168.10.0/24
esp_proposals = aes128gcm128-modp2048,aes128-sha256-modp2048
dpd_action = trap
}
}
}
}
secrets {
ike-0 {
secret = 0sZGFjYXpyZQ==
id-0 = %any
id-1 = 192.168.33.20
}
ike-1 {
secret = 0sZGFjYXpyZQ==
id-0 = %any
id-1 = 192.168.33.30
}
}
The IPsec config after removing the second Phase1.
# This file is automatically generated. Do not edit
connections {
bypass {
remote_addrs = 127.0.0.1
children {
bypasslan {
local_ts = 192.168.10.0/24
remote_ts = 192.168.10.0/24
mode = pass
start_action = trap
}
}
}
con1 {
# P1 (ikeid 1): Node1
fragmentation = yes
unique = replace
version = 2
proposals = aes128-sha256-modp2048
dpd_delay = 10s
rekey_time = 25920s
reauth_time = 0s
over_time = 2880s
rand_time = 2880s
encap = no
mobike = no
local_addrs = 192.168.33.10
remote_addrs = 192.168.33.20
local {
id = 192.168.33.10
auth = psk
}
remote {
id = 192.168.33.20
auth = psk
}
}
}
secrets {
ike-0 {
secret = 0sZGFjYXpyZQ==
id-0 = %any
id-1 = 192.168.33.20
}
}
Updated by Jim Pingle 11 months ago
- Status changed from Confirmed to Incomplete
How are these entries being deleted exactly? Using the trash can at the end of a row, or by checking the box(es) at the start of a row and clicking the red "Delete P1s" button? Try the other method, see if it behaves the same. It would help to know if only one method is affected.
Are delete operations being made on two separate browser tabs at the same time, or just one?
It would help more to see the config.xml section for IPsec before and after (with secret info redacted), the generated IPsec config doesn't contain enough information to say for sure what might have happened.
Updated by Jim Pingle 11 months ago
- Subject changed from ipsec p1 entry deletion deletes all p2 entries from another p1 entry to Removing an IPsec Phase 1 entry can either remove the wrong Phase 2 entries or leave orphaned Phase 2 entries in the configuration
- Status changed from Incomplete to In Progress
- Assignee set to Jim Pingle
- Target version set to 2.8.0
- Plus Target Version set to 24.03
I managed to reproduce a couple different issues here.
The original problem seems to be isolated to only the per-row trash can icon method of deleting a tunnel, the fix for that is fairly simple it's pulling the IKE ID from the wrong config path.
There is a second related issue where using the checkbox+button method is leaving P2 entries orphaned in the configuration.
Additionally, the per-row trash can icon delete method performs extra actions that the checkbox+button method does not, such as cleaning up routes and checking to ensure it's not removing an assigned VTI interface.
The two actions should be working the same way, so make sure they are brought into parity here.
Updated by Jim Pingle 11 months ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset 48aea6ee7e03b5b7f49dd143bd1993d33ba74f5b.
Updated by Danilo Zrenjanin 11 months ago
- File clipboard-202401190855-xjdsk.png clipboard-202401190855-xjdsk.png added
- File clipboard-202401190857-1v8rd.png clipboard-202401190857-1v8rd.png added
Jim Pingle wrote in #note-3:
How are these entries being deleted exactly? Using the trash can at the end of a row, or by checking the box(es) at the start of a row and clicking the red "Delete P1s" button? Try the other method, see if it behaves the same. It would help to know if only one method is affected.
Are delete operations being made on two separate browser tabs at the same time, or just one?
It would help more to see the config.xml section for IPsec before and after (with secret info redacted), the generated IPsec config doesn't contain enough information to say for sure what might have happened.
When conducting my tests, I deleted the second Phase 1 by clicking on the blue trash can:
That action resulted in the removal of both Phase 2 entries in the first Phase 1:
I used only one browser and one tab to perform the actions described above.
Updated by Danilo Zrenjanin 11 months ago
- Status changed from Feedback to Resolved
Tested the patch against:
23.09.1-RELEASE (amd64) built on Wed Dec 6 20:22:00 UTC 2023 FreeBSD 14.0-CURRENT
It fixes the issue.
After applying the patch, I tried to replicate the issue by:
- Deleting the second Phase 1 by clicking on the blue trash can.
- Deleting the second Phase 1 by selecting it and then clicking on the red Delete P1s button.
- Deleting one by one Phase 2 of the second Phase1
None of the previous attempts had any impact on the first Phase 1 and its tunnels.
I am closing this ticket as resolved.
Updated by Jim Pingle 10 months ago
- Has duplicate Bug #15279: When deleting phase 1 ipsec removes phase 2 of the other VPN's in the GUI and loses communication added
Updated by DBACORP DBACORP 10 months ago
- File IPSEC_BUG_disappear.mp4 IPSEC_BUG_disappear.mp4 added
Reproduced the same issue in PLUS version 23.09.1 and the issue persisted.
Follow the video of the BUG simulation in version 23.09.1.
Updated by Danilo Zrenjanin 8 months ago
DBACORP DBACORP wrote in #note-9:
Reproduced the same issue in PLUS version 23.09.1 and the issue persisted.
Follow the video of the BUG simulation in version 23.09.1.
The issue is currently present in version 23.09.1, but the upcoming release, version 24.03, will include the patch to fix it. In the meantime, you can resolve the issue in version 23.09.1 by applying the patch 48aea6ee7e03b5b7f49dd143bd1993d33ba74f5b.