Project

General

Profile

Actions

Bug #12198

closed

Disabling an IPsec phase 1 entry does not disable related phase 2 entries

Added by Viktor Gurov over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

0%

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

Description

How to reproduce:
1) Create IPsec PH1 with several PH2 VTI entries
2) Toggle "disable" button on the vpn_ipsec.php page
3) <phase1> has a <disable> entry in config.xml, but not <phase2>
4) If you try to make any changes to this PH1 disabled entry on the vpn_ipsec_phase1.php page, you'll get an error:

Cannot disable a Phase 1 which contains an active VTI Phase 2 with an interface assigned. Remove the interface assignment before deleting this P1.


Related issues

Related to Bug #11792: Cannot disable IPsec P1 when related P2s are in VTI mode and enabled ClosedViktor Gurov04/08/2021

Actions
Actions #1

Updated by Viktor Gurov over 3 years ago

  • Related to Bug #11792: Cannot disable IPsec P1 when related P2s are in VTI mode and enabled added
Actions #2

Updated by Jim Pingle over 3 years ago

IMO, the P2s should not get their own disabled flag set in this case. The code should assume they are disabled if their P1 is disabled, but otherwise it would become tedious to manage them if there are many P2s and someone wants to temporarily disable the P1. They would have to only click disable on the P1 but to enable they'd have to manually enable every P1. Automatically enabling every P2 would likewise be a bad approach because the user may have one out of many P2s explicitly disabled and after toggling the P1 it would end up in an enabled state unexpectedly.

Actions #3

Updated by Viktor Gurov over 3 years ago

Jim Pingle wrote in #note-2:

IMO, the P2s should not get their own disabled flag set in this case. The code should assume they are disabled if their P1 is disabled, but otherwise it would become tedious to manage them if there are many P2s and someone wants to temporarily disable the P1. They would have to only click disable on the P1 but to enable they'd have to manually enable every P1. Automatically enabling every P2 would likewise be a bad approach because the user may have one out of many P2s explicitly disabled and after toggling the P1 it would end up in an enabled state unexpectedly.

Right,
fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/318

Actions #4

Updated by Jim Pingle over 3 years ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.6.0
  • Plus Target Version set to 21.09
Actions #5

Updated by Viktor Gurov over 3 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Viktor Gurov

Merged

Actions #6

Updated by Alhusein Zawi over 3 years ago

  • Status changed from Feedback to Resolved

fixed

I was able to make changes in disabled P1 without errors

2.6.0.a.20210814.1404

Actions #7

Updated by Jim Pingle over 3 years ago

  • Subject changed from IPsec PH2 related entries are not disabled after PH1 disable button is pressed to Disabling an IPsec Phase 1 entry does not disable related Phase 2 entries

Updating subject for release notes.

Actions #8

Updated by Jim Pingle over 3 years ago

  • Subject changed from Disabling an IPsec Phase 1 entry does not disable related Phase 2 entries to Disabling an IPsec phase 1 entry does not disable related phase 2 entries
Actions #9

Updated by Jim Pingle about 3 years ago

  • Plus Target Version changed from 21.09 to 22.01
Actions

Also available in: Atom PDF