WatchGuard Edge - VPN Troubles

Hello All,


I have a conflict. I have come across this problem twice in the last couple months and am hoping somebody might be able to shed some light.

I have a client using a WatchGuard Edge FireBox 700. I have a few site to site VPN tunnels set up. For some reason every 10 or so hours the VPN link goes down. I have spent hours playing with Keep Alive Values and it has not improved. It almost appears that after a certain amount of inactivity or a network hicup the VPN tunnel breaks. I am very aware that IPSEC tunnels are very sensitive (UDP) but this firewall does not seem to initiate an IKE handshake automatically to rebuild the tunnel.. so I am forced to manually reboot it to force a rebuild.
:confused:

any help or insight would be appreciated.

Not an easy task to t-shoot. There are several inactivity time outs.

Brain storm:

What type of internet connection do you have? Do you use failover (meaning more than one WAN port). Then there are internal configs. Which port, DMZ involved etc. I say internal because the Watchguard uses two methods to determine link status on the WAN. Ping and status of the next router. You could look in the logs to see if there are link interuptions just to eliminate a device outside the Watchguard, like your modem to either DSL or Cable.

They have a dedicated T1 line with a failover in place. I have reviewed log files on router and have found no suspect entries that would cause this. I am able to succesfully ping router both externally and internally. Everything looks fine.

Cryptocrack,

Are you using Main Mode or Aggressive mode for the tunnel negotiation? Do all locations have static IP or just the central location?

What are the firewalls you are using at the branch office locations? Watchguard, Sonicawall, Linux, Linksys, Netgear?

How much and what type of traffic is passing through the tunnel?

Let me know and Ill see if I can help. I run a x700 with fireware pro at our office with 2 branch offices, one terminating to a Netgear and the other to a Sonicwall TZ170. If I can help I will be more then happy to :-)

have you included the internal ips of the remote networks. with some soho6s this seemed to help, 2extrernal 4 internal

schedual a small file transfer ever 10-15 minuites at some locations this is the only thing that helped. i used perl -gui so a console wouldn't open over the work someone was doing man can that tick them

go for static ip's where ever possible WG sometimes seems to have trouble in picking up the new settings.

when does your cert expire ....make it 0kbs and 72 hours.

kruptos,

All sites are using static IP's.

Main Mode is being used on the firebox. All brach offices are using SOHO6's


Tedob1,

This site was not running certificates. It was using pre shared keys. I would have to confirm again that all internal ips of remote networks are on the sohos. Great idea.. I will be sure to take a look when I am back in there on Monday to get started on this project.

kruptos,

what are the recommended Negotiation Timeouts?

8192 kilobytes
8064 hours

??

Many people have many different opinions about that. The way that Watchguard and many other vendor impliment is to have it time out by a preset amount of time, or by an amount of bandwidth that has passed through the connection.

If you have shorted times and Kbs then the rekeying will cause more traffic but will be more secure, longer times will generate less traffic but will also be less secure.


Some people say rekey every hour, some people say every 8 hours and so on.

Personally I recommend 8 hours, or 28800 seconds, I really dont use the Kbs to e honest, but could if I wanted to. You can set the kilobytes to zero if you like but I think that if you look at the WatchGuard policy you will see the defaults, which is probably OK as well.

Remember that if you reach the kilobytes before the time then it will reset after hitting the kilobytes, and vice-versa.

Kruptos,


Sorry I have been unable to get back to you sooner. It was a hectic week. I resolved the issue late last week when I was able to gain access to the London firewall. The negotiation timeouts were not consistent with the settings in the Main Office. After re configuring settings to match on both ends the problem has gone away. The keys seem to re negotiate just fine. Thanks again for the insight.