Bug #8674
closed
Switching IPsec phase one to vti from Tunnel IPv4 and back yields unexpected behavior
100%
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.
Updated by
Updated by Jim Pingle almost 6 years 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.
Updated by Anonymous almost 6 years 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.
Updated by Jim Pingle almost 6 years 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
Updated by Jim Pingle almost 6 years ago
- Status changed from Assigned to Feedback
Updated by Anonymous almost 6 years 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.
Updated by Jim Pingle over 5 years 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.
Updated by Jim Pingle over 5 years 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
Updated by Jim Pingle over 5 years ago
- Status changed from Assigned to Feedback
Applied in changeset bb4b80c856c29d5b60f712c23fd61ed928eb7c15.
Updated by Anonymous over 5 years 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.
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Resolved