Bug #12493
closed
IPsec continues to intercept traffic even after Phase II is removed
0%
Description
pfSense version:
pfSense community edition
Version 2.5.2-Release (amd64)
FreeBSD 12.2-Stable
The issue:
We are replacing an IPsec connection with a dataline. The dataline is active, and to relay the traffic from the IPsec to the dataline we added the necessary entry in the routing table, and then disconnected, disabled, and removed the Phase II entry. I'd like to add, this connection has activity on it, as it is used, amongst other things, for SNMP monitoring.
Even after removing the Phase II entry, the traffic was not routed through the dataline. Packet Capture showed the traffic coming, however, although firewall rules allow, the traffic didn't go out.
The only action we found so far to solve this is to add the necessary rule to "Additional IPsec bypass" under "VPN/IPSec - Advanced Settings".
Updated by Viktor Gurov
Updated by Chaim Robinson almost 4 years ago
This issue has been marked as Duplicate, and I would like to point out that this marking is not totally true.
I read the description of issue 6624, and a workaround is described there, namely to disconnect the connection manually in the Status/IPsec page. Unfortunately, in this case, this workaround does not work.
We took external measures to block the relevant traffic, to ensure the P2 would not automatically get connected. Then, we disconnected the P2 in Status/IPsec, disabled it in the config, applied the disable change, deleted the P2, applied the deletion, disconnected the owning P1, and restarted the IPsec service. After these steps, we removed the P2 from the other end of the IPsec (where it was already configured not to connect automatically, in order to avoid trouble from that direction).
We wanted to make sure this P2 was genuinely gone.
At this point, we released the external blocks stopping the traffic. Unfortunately, even under these circumstances, the traffic was not directed to the dataline as expected. As an experiment, we defined the P2 again - only at the other end of the IPsec. Abra cadabra - up it came connected to pfSense where it wasn't supposed to exist.
I might add, that even hours after applying the solution of excluding this P2 traffic from IPsec in the advanced settings, we attempted to remove this advanced configuration to see if the traffic would continue to flow as expected. It did not. We were forced to restore the exclusion rule.
Updated by Jim Pingle almost 4 years ago
Whether or not traffic is "captured" depends on the presence of policies in the security policy database (SPD, which you can check with setkey -DP). At least on snapshots of 2.6.0/22.01 if I remove a P2 it is removed from the SPD and thus the traffic is no longer captured. Whether or not the IPsec daemon has a P2 remaining active doesn't matter so much, the other end may be confused as well.
The other issue is definitely the same root cause as far as I can see, even if the proposed workaround didn't work identically, since that may not cover all scenarios.