VPN between Checkpoint and Fortigate fails

[JaapHoetmer]

Hello, One of my customers has a couple of IPSEC VPNs between sites that all work fine, until recently one of them started to misbehave. This one connects the Fortigate 50B they have with a CheckPoint device at a remote site; last week this VPN went down, and no messages related to this VPN were shown in the log anymore (other log messages continued to appear though). Trying to force the VPN up did not work, and again, no messages were logged on the log server about the actions performed on that VPN. Since the other VPNs continued to work I decided (after consulting with the peer site engineer) to delete and recreate the VPN, which made the log messages appear again. The VPN did not work at first, so I tried multiple times to recreate the VPN but only the next day the VPN started to work, without anyone intervening. Today, 5 days later, the VPN stopped working again, but the Fortigate VPN monitor and the peer partner Checkpoint both show the VPN as UP. However, as of 13:50 today, no messages traverse the VPN anymore. Stopping and starting the VPN has no result (but does show the normal messages of the VPN going down and up being logged). I am suspecting a problem with the device or the software, so I am trying to post this message to see if anyone has any similar experiences, or any suggestions as to what to do next. I am about to delete the VPN again, and recreate it, to see if that helps. Failing that I could make use of a spare unit I have, configure it to replace the existing unit, and see if that helps to get the VPN stable again. I hope anyone has additional suggestions. Fortigate 50B Firmware: Fortigate-50B 3.00-b0668(MR6 Patch 2) Many thanks, kind regards, Jaap Hoetmer

[rwpatterson]

Welcome to the forums. 3 things come to mind: 1) Upgrade. That code is ancient. If you like the green interface, use v4.1.10. If you wish to tinker with the newer white interface, hit v4.2.8. 2) In the VPN setup, are the phase 2 keylives the same? They should be so they rekey at the same time, or close. 3) In the phase 2 definition (from the CLI) add in ' set auto-negotiate enable' . That should attempt to keep the tunnel up after the keylife expires. Hope that helps.

[ede_pfau]

Hi, I' d suggest upgrading as well, maybe to 3.00MR7patch10 to keep the config as close to the original as possible. But this will not be the reason for the loss of traffic across the tunnel. Fiddling with the VPN parameters can induce a lot of problems - as long as you SEE that the tunnel is up (but no traffic passing) I wouldn' t do that. What you see is that the tunnel works OK, can be set up and down etc. and logging works as expected. There must be a reason for the traffic ending up somewhere else. I' d suspect that the routing has gone haywire. Are there any routers on the remote network? Could it be that the address ranges of both tunnel sides overlap? Maybe someone added a DHCP server lately. I' d look into these kind of recent changes. For debugging, I' d look into where the traffic goes to: use traceroute, from each side. If the VPN setup itself has been working for a long time, and you have recently rebooted both VPN gateways (just to be cautious) then this shouldn' t be your primary target of investigation: VPN parameters don' t deteriorate over time. For the same reason an upgrade will most probably not change the situation but make troubleshooting in a longer perspective easier.

[JaapHoetmer]

Thanks Bob and Ede for your useful suggestions. Bob, to answer your questions: 1) Upgrade does often seem to be a useful ' fix' , be it that I am always cautious when hit with a situation that first worked and then started to fail without any intervention or apparent trigger. 2) Yes, keylifes are the same both ends of the tunnel. Phase 1 keylife is 86400 seconds (24 hours), phase 2 is one hour. 3) Is that not the same as the GUI option Autokey Keepalive? If not, what is the difference? Ede: Agree with your comment about the upgrade probably not resolving the issue. But useful nonetheless. Routing does seem to be a strong contender for the fact messages do not end up at the other end of the tunnel. However, the log messages from the firewall clearly indicate that the firewall forwarded the packets through the defined tunnel. The routing into that tunnel is defined by the firewall policy. There are no other routers on our network, at least not before the firewall, only the router behind the firewall that connects to the internet; the peer site engineer verified directly on their Checkpoint, which terminates the VPN, so if the packets do not appear there they haven' t probably left here. I did use ping and traceroute yesterday to see where the packets went, and they were stopped at the local firewall. This morning at 8h47 local time (CET) the VPN started to work and messages from us were appearing at the peer site (probably because someone started their day job). It is unclear though at what time the connection became ' valid' ; the last unsuccessful attempt to get anything across was yesterday at 16:58, after that the log shows successful hourly phase 2 renewals and the first request traversing the vpn this morning was successful at 08:47... Today traceroute shows the full path through the tunnel and pings are successful with 14 msec rtt. The gateways are never rebooted unless necessary, the last system restart of our device dates from 9th June 2010. The upgrades, where can I obtain more information on this, through the reseller or directly via Fortinet? Thanks for your help. Kind regards, Jaap Hoetmer

[ede_pfau]

I am glad I could fix your problem But seriously: I would not expect that the fault will not come up again. If I had to debug this I' d a) let the sniffer show me the packets entering the tunnel (' diag sniffer packet ...' ) b) start a ' diag debug flow' to see how packets are handled and routed The policy itself will not route anything; routes do. I' ve seen networks where the active route was not the defined one but the one proposed by ICMP redirection. And that' s a factor outside the firewall and thus hard to keep in view. Firmware updates are downloaded manually from support.fortinet.com where you identify yourself by your user account. To create one, you have to register your FGT' s serial number. Updates and upgrades are for free, lifetime. The 50B is an old workhorse and as such is supported in the newer firmware versions. Versions generally seen as stable are 3.7.10, 4.1.10 and 4.2.8 (read: version, MR, patch).

[JaapHoetmer]

:) if only you had! I will try to set up some monitoring and when this happens again I can use your suggestions to try to debug the problem. As for routing, the only place where the routing via the tunnel is set is via the policy. The remote addresses are grouped, the group is then used in a policy, which directs the traffic down the VPN. Thus, the policy governs the routing required for it to use the VPN. Correct? I have tried to register the devices on the support site, but no downloads are provided for it - no support entitlements, no warranty. Thanks again, appreciated.

[ede_pfau]

OK, so I guess you' re using policy based VPNs - a policy with action ENCRYPT? That makes a difference. Again, it worked before so you shouldn' t be forced to recreate the policy to make it work again. Strange that you don' t have ANY options on the support site after registering the unit. What does your reseller say? But again, upgrading is not a priority. About the routing...what I mean is that somewhere on your LAN there might be an interference causing packets to divert...sounds fishy but things happen. Before we/you delve deeper into crystal ball looking you should get the sniffer going. You might play around with it for a while to get to know all options (use the ' ?' often). So you' ll be prepared when the traffic stalls again. Too bad it' s up and running all the time now...

[JaapHoetmer]

Thanks, Ede, for your replies. Yes, exactly, I am using policy-based routing for the VPNs. I have since been in contact with a reseller, and he explained that the basic services require a yearly fee of CHF 92 per device. He also says these devices will reach end of life soon. I will dive into the sniffing and diagnostics capabilities of the devices, promising a fun exercise. I like these little boxes more and more.

[ede_pfau]

You' ll get more info on the diag commands I mentioned earlier from a search on the forums. Diag commands are ' inofficial' and as such not documented on Fortinet' s website. But indispensable at times. The ' basic' FortiCare contract covers hardware return to factory (to Nice, France) and firmware updates. If the unit has been out of support for a longer period, Fortinet will use up to 6 months of the new contract to cover the gap between the expiry date and the new registration (so as to encourage seamless support contract renewals).

[JaapHoetmer]

Hi again I noticed after the FortiOS upgrade on a spare device that PPTP VPNs have disappeared, between the version I was running and the latest version. I was using PPTP VPNs but that would mean I would have to use SSL VPNs. Any idea why the PPTP VPNs were removed? Thanks, Jaap