WatchGuard Edge - VPN Troubles
Results 1 to 9 of 9

Thread: WatchGuard Edge - VPN Troubles

  1. #1
    Junior Member
    Join Date
    Apr 2006
    Posts
    14

    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.


    any help or insight would be appreciated.

  2. #2
    Senior Member RoadClosed's Avatar
    Join Date
    Jun 2003
    Posts
    3,834
    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.
    West of House
    You are standing in an open field west of a white house, with a boarded front door.
    There is a small mailbox here.

  3. #3
    Junior Member
    Join Date
    Apr 2006
    Posts
    14
    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.

  4. #4
    Senior Member
    Join Date
    Sep 2003
    Posts
    137
    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 :-)
    \"Common Sense, isn\'t that common\"
    \"It is a lot easier to raise a child then it is to repair an adult\"
    -Kruptos

  5. #5
    Senior Member
    Join Date
    Nov 2001
    Posts
    4,786
    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.
    Bukhari:V3B48N826 “The Prophet said, ‘Isn’t the witness of a woman equal to half of that of a man?’ The women said, ‘Yes.’ He said, ‘This is because of the deficiency of a woman’s mind.’”

  6. #6
    Junior Member
    Join Date
    Apr 2006
    Posts
    14
    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.

  7. #7
    Junior Member
    Join Date
    Apr 2006
    Posts
    14
    kruptos,

    what are the recommended Negotiation Timeouts?

    8192 kilobytes
    8064 hours

    ??

  8. #8
    Senior Member
    Join Date
    Sep 2003
    Posts
    137
    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.
    \"Common Sense, isn\'t that common\"
    \"It is a lot easier to raise a child then it is to repair an adult\"
    -Kruptos

  9. #9
    Junior Member
    Join Date
    Apr 2006
    Posts
    14
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •