I'm pretty desperate with the 60D (FW 5.4.4) I have to manage.
There are about 50 IPSec VPNs, CPU and memory usage is quite low, everything works for about a week.
Then the servers connected to the firewall still reachable with RDP, the web server are ok, but the VPN are up but without traffic. Restating the VPN individually with "bring down" or globally with flush have no effect: the remote machines renegotiate the SA, the VPN is again up but uncapable to deliver data.
After a FW reboot everything is again ok, no need to touch the configuration or doing anything else on the remote side or so.
I don't want to open a ticket, send every possible logs and confs, try to reset even the front panel logo... and wait for the next release!!
I am the only one with this problem (that in some ancient release did not exist)??
Thank you for your answers!
While this isnt a support forum by any means and TAC really is the right avenue for raising issues like this, I am compelled to try and provide some commands to help you figure out what might be going wrong here. You did not specify whether those tunnels were site to site or remote access clients but I think I understand they are the later case.
Your best friends for troubleshooting VPNs is "diag debug app ike -1", if the issue is related to IPSec or IKE themselves:
diag debug enable
diag debug app ike -1
The output of that command is rather verbose and provides diagnostics from the VPN system which are just about always necessary in order to assess what might be wrong with a given setup. What it might not inform you of is related to decisions taken on traffic, which leads us to "diag debug flow". If you take the IP assigned to one of your VPN clients, you can obtain the sequence of decisions taken by the firewall on any packet coming in. E.g.:
MN140D-1 # get vpn ipsec tunnel summary
'RASVPN_1' 184.108.40.206:64916 selectors(total,up): 3/3 rx(pkt,err): 274/0 tx(pkt,err): 434/0
MN140D-1 # diag debug flow filter addr 220.127.116.11
MN140D-1 # diag debug flow show console enable
MN140D-1 # diag debug flow trace start 100
That "100" value represents how many hits you want the command to show you - running this command scrolls a lot and it really needs a limit to stop :)
Armed with the information from these two commands, we might get a better idea or at least a starting point as to why you are experiencing these issues. However if you are experiencing them all at once, for all 50 clients, it may be worthwhile to open a case in order to accelerate your resolution.
Principal Presales Security Expert
thank you for your detailed answer!
I'll try to use some 'diag vpn' commands but I'm afraid I don't know what to looking for: when the VPNs are working... I'm afraid there is nothing special to see... and when not I'm pretty sure that the negotiation is correct and completed, as the SA was use to work, but there is no traffic.
However if this is not a "common" or "frequent" issue... I'll open the ticket, hoping that this time will be somehow useful and not just the usal "send me a log" "here the log" "try to chang the time zone pretending you live on the moon" "done" "send me a log" "here the log"... :-)
Thank you again,Damiano
I think that you have an issue with auto negotiate, sometimes when you leave the vpn up without traffic I recommend you to enable the auto negotiate featureAuto negotiateAn IPSec VPN creates an encrypted security association (SA) between two peers. This is done in two phases. By default, the phase 2 SA is not negotiated until a peer attempts to send data. When enabled, auto-negotiate initiates the phase 2 SA negotiation automatically, repeating every five seconds until the SA is established.config vpn ipsec phase2 edit
thanks in advance
Thank you Hector for your answer!
I'm afaid that a problem with autonegotiation is not my case because I have a constant traffic on each VPN.
And, in any case, a problem on one VPN can explain a glitch on that SA but not on all the VPNs on a firewall at the same time.
I've opened a ticket but we are not at the end of the (VPN) tunnel yet!
I let you know the solution (...if any :) and thank you again for your time and for some useful debug commands!
One clarification regarding auto-negotiate and keepalive: activating the former automatically enables the later.
Auto-negotiate on your phase2 configurations will cause the SAs to be always up irrespective of traffic being present and causes them to come up right away as soon as the phase1 comes up.
Keepalive ensures that at the time the SAs are up for rekeying, they are rekeyed even if the SA is idle (has no traffic).
The distinction primarily lies in whether there is a need or not for that very initial "interesting traffic" to be sent down the tunnel. Once the SA is up, having either feature enabled will result in the SA being maintained.