All the VPNs without traffic/routing, every week or so

[DamiIngu]

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!

[mnantel_FTNT · Accepted solution]

Hi Damiano,

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' 1.2.3.4:64916  selectors(total,up): 3/3  rx(pkt,err): 274/0  tx(pkt,err): 434/0

MN140D-1 # diag debug flow filter addr 1.2.3.4

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.

Mat

--

Mathieu Nantel

Principal Presales Security Expert

[DamiIngu]

Hi Mat,

  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

[HectSalg]

Hi Diamano!!

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 feature

Auto  negotiate
An 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
    set auto-negotiate enable
  end

Also is recommendable to enable Keepalive feature.

The phase 2 security association (SA) has a fixed duration. If there is traffic on the VPN as the SA nears expiry, a new SA is negotiated and the VPN switches to the new SA with no interruption. If there is no traffic, the SA expires and the VPN tunnel goes down.

To enable Keepalive - Web-based manager

    Go to VPN > IPSEC > Auto Key (IKE).

    Select the Edit icon for your phase 2 configuration.

    Select Advanced.

    Select Autokey Keep Alive.

    Select OK.

To enable Keepalive - CLI

config vpn ipsec phase2
  edit
    set keepalive enable
  end

Also is recommendable to enable the uto

config vpn ipsec phase2
  edit
    set auto-negotiate enable
  end

http://kb.fortinet.com/kb/documentLink.do?externalID=12069

thanks in advance

Best Regards

[DamiIngu]

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!

Damiano

[mnantel_FTNT]

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.

--

Mathieu Nantel

Principal Presales Security Expert