IPSEC Configuration cache not flushing properly in some instances
I work for the IT dept of a services company that is using pfsense as its gateway software.
One of our gateways, which is hosted on a dedicated server at OVH (French hosting company) inside a vRack is used to provide ipsec tunnels to most of our clients and all of our corporate locations.
There is a the moment 58 first phases configured, and about 200 P2.
Some are IKEv1, some v2.
We are in the process of migrating more tunnels to that pfs box.
I tend to use the webgui to configure the phases, then I use the console (ipsec up con<xxxxx>) to bring them up once the remote side tells me that we are aligned, since the console output is in my opinion easier to read when diagnosing mismatches.
During the last migration. I made a mistake : We had two P2, one of which was X.X.X.X/29 and the other X.X.X.X/32, but I wrote them both as /32s.
I brought the tunnel up, then saw my mistaked, and attempted to change it (while the tunnel was up (in status/ipsec) and the configurations enabled (in vpn/ipsec)).
I applied the new config, then brought the tunnel down, disabled the config, reenabled it and brought it up again.
The new tunnel was unchanged, the two P2 were still /32.
I checked in the console (ipsec statusall conXX), also both /32.
I then checked the /var/etc/ipsec/ipsec.conf. Here the configuration was correct (/29 and /32).
So I tried a "ipsec reload" to no avail.
I then tried to restart the service through the webgui, but the service never stopped and as a result didn't restart.
I killed everything ipsec related with a kill -9 in console, then restarted the service (/usr/local/libexec/ipsec/starter).
Doing this fixed the situation.
This happened twice already, with us unable to pinpoint a particular similarity between the two events.
The first time, we realised soon after that the subnet in one of the P2 was overlapping one of our internal ones, we fixed that.
The second time, I am positive that no overlap was present.
I expect that the P1/P2 configs are cached somewhere I didn't find. and that this cache superseds the ipsec.conf file, even after running the "ipsec reload" command.
I am sorry that I am not able at this time to provide an exact reproduction method, but with some of your ideas, I may be able to in the end.