VPN Session / Routing issue

[willmays]

Hi all - your thoughts on the below issue would be appreciated! I have a problem with sessions ' sticking' to a WAN interface when they should be going through a VPN tunnel. Not sure if this is more appropriate for the VPN or Firewall forums. We have a site-to-site VPN with a third party. Fortigate 80CM our end, Cisco VPN Concentrator their end. Their internet connection is not very reliable and hence the VPN will drop a couple of times per week. This VPN is configured in interface mode. Diagram:

                 +-------------+                     +--------------+
                 |             |      IPSec VPN      |              |
  10.0.0.0/24    |Fortigate 80C|<------------------->| Cisco        |    172.16.0.0/24
    Internal     |             |WAN1                 |              |      Their App
                 |             |                     |              |
                 +-------------+                     +--------------+

When the VPN is up, an application on our end (10.0.0.0 network) will communicate with a server on their end (172.16.0.0 network). We also have network monitoring software that pings their application server every second (whilst this issue is ongoing). When reviewing the session monitor, traffic is going out on the correct firewall policies (i.e. internal -> VPN_P2 = over the VPN) When the VPN goes down, our network monitoring software notes the outage. Our ping to their VPN concentrator may come back within 60 seconds - but viewing the session monitor still shows the traffic (both ICMP and HTTP) going out over an internal -> WAN1 policy i.e. straight to the internet. It can take up to an hour before the sessions to WAN1 time out and traffic resumes over the VPN. I have a suspicion this is to do with the session timeout on the Fortigate, but don' t want to alter it from defaults (3600 seconds) in case I affect other traffic. Any ideas on how I can get the VPN-bound traffic to go back over the VPN as soon as it comes back up? Happy to provide any other information you need to give me a pointer in the right direction! Thanks in advance, Will

[ede_pfau]

Hi, you should have " Dead peer detection" enabled in the phase1 setup screen, last item at the bottom. This will make the FGT tear down the route immediately when the tunnel fails. Secondl<, I' ve got all RFC1918 private networks routed to the blackhole device. Of course, with the highest distance of 254 so that they only become active if there' s no other, less costly route. So after a tunnel-down event the real route to the remote subnet is deleted from the routing table, and the blackhole route kicks in. No traffic will ever leak to the WAN. The point is that blackhole routes will not be cached. Here' s it:

     edit 0
         set blackhole enable
         set distance 254
         set dst 10.0.0.0 255.0.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 192.168.0.0 255.255.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 172.16.0.0 255.240.0.0
     next
 

Other than that I do not have anything else configured, and tunnel traffic comes up in seconds after an interruption. Esp, I do not have a DENY policy to WAN in place blocking the private networks. This article describes it: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=13842

[rwpatterson]

ORIGINAL: ede_pfau Here' s it:

     edit 0
         set blackhole enable
         set distance 254
         set dst 10.0.0.0 255.0.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 192.168.0.0 255.255.0.0
     next
     edit 0
         set blackhole enable
         set distance 254
         set dst 172.16.0.0 255.240.0.0
     next
 

Beware, at least in version 4.2.12, this wreaks havoc with policy based VPNs. I do have a few legacy ones that I have yet to migrate over. Everything looked normal, but I had to delete the above routes and then drop/enable the policies again to get communications back up. What a pain in the a$$...

[willmays]

Ede Thanks for your reply - that appears to be exactly what I need! Already had dead peer detection on all IPSec VPN Phase 1 configurations. Adding an additional blackhole route for each VPN route per your configuration sample seems to have worked - with a manual test. Now I just have to wait for a real outage and see if it works! I haven' t done the Deny policy either. Many thanks for your help, I will post back here with some more feedback in a week or so! Will

[ede_pfau]

hear, hear - why? how do PBR and (real) blackhole routes interfere? Must be a bug. I' ve got the hint straight from the horse' s mouth (the KB that is). Would you care to open a ticket for this?

[rwpatterson]

Not a show stopper for me. If someone else has an issue, I' ll do it.