IPSEC VPN Tunnels going offline

[#1]

I just implemented my 200A over the weekend... and for the most part everything went really well... had a few rules that I missed that I cleaned up on Monday morning. However I have noticed that some tunnels are not as stable as I like. I have about two dozen branch offices that connect in to this 200A, most of them are running WatchGuard SOHO 6tc units. I have upgraded the firmware on all of the SOHOs (thought that that might help) but some of the tunnels are still flakey. About 4 of these sites so far have been upgraded to Fortigate 60s. Those tunnels are quite stable. All of the sites have the exact same configuration. Phase I Aggressive Mode key life = 79200 seconds (phase 1 and phase 2) and 0 bytes NAT Traversal is on Dead Peer Detection is on Phase II Replay detection is on PFS is on Key life = 79200 Auto keep alive is on The rest of the configs (encryption, etc) match up on both ends. The odd part is that not all of the tunnels are having issues. Two of the sites (running SOHOs) will drop within a few minutes if I stop pinging a unit on their end. I can usually bring the tunnels up again but without a stream of data... it will drop again (very annoying). My PC is constantly pinging a few sites for now just to keep the tunnels up but I would like to get away from this. I thought at first that it might be the NAT traversal... but according to WG, the SOHOs support this feature. I don' t see anywhere where I can turn it on or off... but the config file from the unit does show options for NAT Traversal and it does appear to be enabled. I have also checked for a corelation between hardware or anything else at problem sites but haven' t found anything. Now I am thinking it might be the keylife... I saw here that some people reported better performance with a shorter keylife. Not sure how that would be... but at this piont I am willing to try anything. Thankfully I have a fully functioning WG SOHO here that I can use for testing. I just wanted to know if anyone else has come across this and / or if anyone had any suggestions. Please let me know! Thank you

[abelio]

Hi, We had good experiences with WG Fireboxes using keys with " Negotiation Timeouts: 8192 kilobytes, 24 hours" (in Fortinet that' s " Keylife: Both 86400 Seconds 8192 KBytes" ) If you run fortios 2.80, use " ping generator" to keep traffic alive between peers If you run fortios 3.0, edit phase2 FortiGate' s VPN with CLI and try with the command:

set auto-negotiate enable

hope it helps.

[#3]

I enabled the auto-renegotiation for my two most troublesome tunnels and they seem to be much more stable. It' s only been 30 minutes... but before they would have dropped within a few minutes if I wasn' t sending constant data across. I can see that they have renegotiated a few times already... but that doesn' t matter as long as they are available. I am going to go through and set this on the rest of my tunnels. Thanks Abel!

[#4]

Will this work with the Fortigate 60 as well? I have multiple tunnels and they keep dropping out when there is no activity. I have the autokey keep alive checked. I' m not that familiar with the CLI. do you have to enable for each tunnel? Thanks.

[#5]

Yes it does have to be enabled for each Phase 2 tunnel (as far as I know) and it does work on the 60M. Not sure if there are any firmware level requirements... but my 60Ms have the latest MR3 memopt firmware and it works on them. It is tedious but you can use the up arrow key to repeat the steps and go through all of your tunnels pretty quickly. I had to do about 40 of them and it took me about 20 minutes.

[#6]

The commands are as follows: config vpn ipsec phase2 (assuming you' re using IPSEC) edit Tunnel_Name set auto-negotiate enable end

[#7]

Schooner. Thanks for the " how-to" . I' m testing it now. on a couple of the tunnels.