Project

General

Profile

Bug #8674

Switching IPsec phase one to vti from Tunnel IPv4 and back yields unexpected behavior

Added by James Dekker over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
07/20/2018
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:

Description

On 2.4.4.a.20180720.1418, create a site-to-site IPsec tunnel, with Tunnel IPv4 selected as the mode for the phase two. After saving and applying changes, confirm the tunnel established correctly.

Add a rule on the IPsec interface to allow any traffic.

Initiate a ping across the tunnel from a host on one side, to the firewall itself or another host on the other side. The ping will succeed.

Change the phase two's mode to vti, save, apply changes, stop and start the service.

The pings will fail. (as expected)

Visit Interfaces > Assignments and see that the ipsec1000 interface is ready to be assigned. Do not assign it.

Go back to the IPsec tunnel and change the phase two mode back to Tunnel IPv4, save, apply changes, stop and start the service.

The pings will continue to fail, despite the phase two mode being changed back to Tunnel IPv4 from vti.

Visit Interfaces > Assignments and see that the ipsec1000 interface is still ready to be assigned. Although it should no longer be available for assignment since the phase two mode is no longer vti.

Go back to the IPsec tunnel and delete it.

Go back to the Interfaces > Assignment page and the ipsec1000 interface is still ready to be assigned.

Recreating the tunnel has no effect, the phase one and phase two will come up, traffic will come in from either side but it will not pass through pfSense.

Associated revisions

Revision 7c4e29cb (diff)
Added by Jim Pingle over 1 year ago

VTI input validation. Fixes #8674

Add input validation to prevent switching away from VTI or deleting a
VTI P1/P2 which belongs to an assigned interface, since this would break
the interface assignment and cause an interface mismatch at the next
boot.

Revision b66b72d0 (diff)
Added by Jim Pingle over 1 year ago

Add VTI validation check for disable in the P2 edit screen. Fixes #8674

Revision bb4b80c8 (diff)
Added by Jim Pingle over 1 year ago

Prevent disabling IPsec P1 with assigned VTI P2. Fixes #8674

History

#1 Updated by James Dekker over 1 year ago

  • Category set to IPsec

#2 Updated by Jim Thompson over 1 year ago

  • Assignee set to Jim Pingle

#3 Updated by Jim Thompson over 1 year ago

  • Target version set to 2.4.4

#4 Updated by Jim Pingle over 1 year ago

  • Status changed from New to Assigned

#5 Updated by Jim Pingle over 1 year ago

  • % Done changed from 0 to 70

Partially done with 2c3ac0b381a5d1ed6e81105158fa7cceb682dc95 - Still needs some input validation to prevent a user from taking an action that would remove an assigned ipsecXXXX interface.

#6 Updated by James Dekker over 1 year ago

With the patch provided, applied, the behavior appears to be corrected. That is, when you switch back to Tunnel IPv4 from vti, the (ipsec1000) interface is no longer available for assignment and traffic begins to flow again.

#7 Updated by Jim Pingle over 1 year ago

I just pushed some extra input validation which does the following:

  • Prevents from switching VTI to another P2 mode with an assigned interface
  • Prevents disabling a VTI P2 with an assigned interface
  • Prevents deleting a VTI P2 with an assigned interface
  • Prevents deleting a P1 which contains a VTI P2 with an assigned interface

#8 Updated by Jim Pingle over 1 year ago

  • Status changed from Assigned to Feedback

#9 Updated by Jim Pingle over 1 year ago

  • % Done changed from 70 to 100

#10 Updated by James Dekker over 1 year ago

On 2.4.4.a.20180724.1715, unable to switch from VTI to another P2 mode with an assigned interface; unable to disable a VTI P2 with an assigned interface; unable to delete a VTI P2 with an assigned interface; unable to delete a P1 which contains a VTI P2 with an assigned interface. Looks good.

#11 Updated by Jim Pingle over 1 year ago

There was one more disable case I missed yesterday: Checking disable in the P2 settings screen instead of using the button on the P1 list. I just pushed a fix for that.

#12 Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to Assigned

Looks like it's still possible to disable a P1 containing a VTI P2 which leads to the problem case. That also must be prevented. See #8691

#13 Updated by Jim Pingle over 1 year ago

  • Status changed from Assigned to Feedback

#14 Updated by James Dekker over 1 year ago

On 2.4.4.a.20180725.0317 with patches b66b72d0ae725392b0158de3a0ec0731d71cd793 and cc240e3259d90ed236872de5cba346fe092eda85 applied, the user is unable to disable a Phase one with a Phase two configured with VTI and it's VTI interface assigned. The user is also unable to edit the Phase two configured with VTI and it's interface assigned, to check the box to disable.

Looks good.

#15 Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF