Is it bug? IPSEC child SA entries too much, olds not deleted
-
One thing I did notice is that when the P1 reauthenticates, the new P1 is created and installed, but the old P1 is the one that adopts the existing P2's. Then the old P1 gets destroyed. Seemed odd to me, unless the description in the log is misleading.
Forgive my misuse of terms, I'm no IPSec guru.
-
If you lose connectivity something else is going on.
If you can pinpoint the time of connectivity loss and post the IPsec logs for that connection surrounding that, something might stand out.
-
I'm experiencing the same issues multiple P2's which causes the tunnel to get stuck as the old P2's have not been removed. I have to manually disconnect the P2's which are stuck and traffic starts to flow internally via the tunnel again.
https://forum.netgate.com/topic/132900/ipsec-phase-2-duplicate-causes-vpn-tunnel-to-get-stuck
-
Derelict, what is the default value of margintime field if it's leave blank in IKE v1?
-
Again, the IPsec logs show you exactly what is going on. If there are multiple P2 tunnels and the "wrong one" is selected, it is probably the other side has deleted the one you are trying to use that should be the newest one created.
Do any of you seeing this have the Disable rekey checkbox checked on the P1 in question?
IKEv1 or IKEv2?
-
@derelict Disabled rekey unchecked, IKE V1
Mine affects the VPN can not ping through to main site. What commands and logs can I run/ look at to then post on here?
https://forum.netgate.com/topic/132900/ipsec-phase-2-duplicate-causes-vpn-tunnel-to-get-stuck
-
Do you have more than one IPsec tunnel? If only one, Status > System Logs, IPsec.
In this case you will want to look at the logs surrounding the time the traffic stopped flowing.
If you can't decipher them, you'll want to sanitize them if you're sensitive to that and post them here.
You can look at the traffic selectors in the SPDs tab in Status > IPsec. Find the one that matches the traffic in question.
You can evaluate the counters in the P2s in Status > IPsec. That might show something interesting.
You can look at Diagnostics > Command Prompt executing
ipsec statusall
there. See what that shows. and if anything is "strange."There was an issue with Status > IPsec that was patched. I cannot remember exactly what it was. Perhaps not showing all information necessary if split tunneling was enabled. But one of the by-products of the fix was to display ALL active tunnels. I believe these connections were always there but just filtered for display and just the newest one displayed.
The general behavior is to re-key at a random interval prior to the lifetime expiry. In order to provide seamless traffic flow while this is happening, the old SPD hangs around so if any traffic from the other side arrives to it, it can be decrypted and forwarded. When the full lifetime expires, the SPD is deleted. If one or the other sides request deletion, it is deleted immediately. So the key to figuring out why yours is hanging is to look at the logs surrounding these re-keys and figuring out where the breakdown is. Then once you know what it is, see if there is a way to fix it.
Chasing the multiple displayed P2 entries might be sort of a red herring.
-
@derelict Thank you for the response. I have split tunnel on the one which is being affected causing loss of service.
When it happens again tomorrow I will take a screenshot of everything and if possible send it over to you for a review?
I will run the she'll command as advised, I will check the tabs on Ipsec status, what's very strange is when I manually delete the P2 which looks like traffic has stopped flowing it brings the service back up, almost like the P2s are not being deleted.
EDIT I've just remoted in checked and I think you are right, when the issue occurs I will check the IPSEC logs and System logs. Obviously when the timer has finished the old P2 should be removed and I've just seen this happen on another VPN.
Excited to test tomorrow!
-
@Derelict In my case, I have an IPSEC tunnel which the disconnection happens at random times, so I need to go to Status -> IPSEC to disconnect and reconnect the P1 manually, even with status "Established" displayed, is not respecting the 8h rekey of P1. After this action I'm able to ping the remote hosts.
Both sides have the same P1 and P2 key lifetime. The Disabled rekey is unchecked, IKE V1, and today I configured Margintime to 300 seconds.
Since the disconnection happens at random times, what is the command to save all logs to a file so I can analyze it?
-
The best thing to do is log to a remote log server.
If adjusting the number of log entries visible using the filter in that view is insufficient, you can use this command to save all IPsec logs:
clog /var/log/ipsec.log > /tmp/ipsec.log.txt
Execute that in Diagnostics > System Command
Then, on that same page, Download File
/tmp/ipsec.log.txt
The logs kept on the firewall are circular, however, meaning old entries are overwritten by newer entries. The amount of logging kept is set in Status > System Logs, Settings, Log file size (Bytes). What you can do there depends on your disk size. I have mine set to
50000000
(50MB) on a system with a 30GB mSATA and it is still 90% free (about 3GB usedDisk space currently used by log files is: 1.2G Remaining disk space for log files: 22G
). You have to reset all logs further down on that page for this to take effect.You can save a lot of the system state in a status output file. That is taken by navigating to
https://firewall.address/status.php
and downoading the resulting file. On busy firewalls that might take a moment to run. And for IPsec issues the logs saved there are often insufficient so the status output should be coupled with anipsec.log.txt
file as described above.If you have more than one tunnel it is often beneficial to get the conXXXX number of the tunnel from
ipsec statusall
so you can filter on it (and filter out other tunnel logs) usinggrep
, etc.