IPsec VPN, TTL and ruting when VPN is down

[Yngve0]

We have 5 VPN' s in Interface-mode from HQ to 5 regional offices. When one of the VPN-nodes is down for å short moment, I see that trafic for this node is trying to use the next possible path from routingtable, which normally is the default gateway (=> WAN). When the link and VPN is re-etablished, those sessions have tendense to hang according to TTL-parameter for this session. Due to increased TTL-value and aggressive polling (WhatsUp), those sessions will hang for ever. I have therefor added a new " DENY => internal-address" -rule first in my firewallset for Internal - WAN, (I guess this should have been there initially?). But I have had similar issues on nodes where I have allowed failover-VPNs with lower priority; also here I have seen that sessions are " hanging" on secondary VPN-route even after primary VPN is re-etablished. This result in inconsistent routing and dropped packages. Whats is best (and failproof) praxis for this issue? Yngve

[FortiRack_Eric]

The recommend way is to create a black hole route for segments on the vpn. config router static edit 0 set dst <segment/subnet> set blackhole enable set distance 254 end Cheers, Eric

[Yngve0]

Thanks; I wasnt aware of the Blackhole-routing function. But what about the scenario with alternative, secondary link:

But I have had similar issues on nodes where I have allowed failover-VPNs with lower priority; also here I have seen that sessions are " hanging" on secondary VPN-route even after primary VPN is re-etablished. This result in inconsistent routing and dropped packages.

[FortiRack_Eric]

Well, that' s one reason to certify, I always elaborate on this issue during 301 class. For your other scenario, one way is to have different metrics for the pri and sec vpn route. You can also use OSPF on the vpn network, if you have route based VPN' s Cheers, Eric

[Yngve0]

For your other scenario, one way is to have different metrics for the pri and sec vpn route. You can also use OSPF on the vpn network, if you have route based VPN' s

I will try to set it up with OSPF, it may be easier than I first expected. But; There are one (big?) challange here; I need to route all internet-trafic (0.0.0.0/0) from remote site via HQ due to IP-restriction on several WEB-services and -subscribtion. Today this is solved with policy based VPN in " remote" -end and interface based VPN in HQ-end. Can I use 0.0.0.0/0 (DefGW) as " Network" in OSPF and have a static route with lower metric for HQ WAN-IP.

[FortiRack_Eric]

Yes, you can. Use a static metric of 200 (or so) for the static route. The OSPF route will have a metric of 110. Cheers, Eric

[Yngve0]

Thank for help, but only partly succeeded. . . . I can now see that routes are distributed but I got double of all routing entries; - one heading for the remote VPN-interface - one heading for the remote wan interface which is carrying the VPN-tunnel. Seems like it try to route all trafic against the remote WAN interface instead throught the tunnel. Which is of course not allowed according fw-rules and therefor fail. I have only the VPN-interface' s in the OSPF-conf, not OSPF-entry for any wan-interfaces. . . What could be wrong?

FG200A (OSPF-Test) # get rou info ospf nei
 
 OSPF process 0:
 Neighbor ID     Pri   State           Dead Time   Address         Interface
 10.10.88.2        1   Init/ -         00:00:38    10.255.255.238  VPN_Internal4
 10.10.88.1        1   Full/ -         00:00:33    10.255.255.242  VPN_Internal3
 10.10.88.2        1   Full/Backup     00:00:33    10.255.255.250  internal4
 10.10.88.1        1   Full/Backup     00:00:39    10.255.255.254  internal3
 
 
 FG200A-VetInst (OSPF-Test) #
 

Part of reply on get rou info rout all

 O       10.10.88.1/32 [110/110] via 10.255.255.242, VPN_Internal3, 00:20:04
                       [110/110] via 10.255.255.254, internal3, 00:20:04
 O       10.10.88.2/32 [110/110] via 10.255.255.238, VPN_Internal4, 00:01:58
                       [110/110] via 10.255.255.250, internal4, 00:01:58
 

Confusement (inconsistent) in the ip-structur, due to LAB-enviroment. I presume it will never occur in real life, SORRY . . Yngve

[Yngve0]

OSPF solved 95% of it, but I still need some additonal, static routes. I see that the static routing entry sometimes disappear from the monitor when the assigned VPN-tunnel is down. Other times, the static route are still in monitor and it try to route trafic over a VPN that is down. Anybody who can clarify how this should work? Y