Hi there. Well, I have a scenario where I want to have 2 IPsec VPNs from lets say FW1 to FW2 and the one VPN being the primary and the other the secondary. Everything seem to work just fine by just enabling DPD but DPD convergence is way too slow (>1min). I have read that you can speed up converge time by enabling Link health monitor. So i did try to set it up but there is one problem. Although link monitor works when it detects a link failure and it fails over to the secondary VPN very fast I cant figure out how to get back to the primary VPN when the link comes up again. Everything I try result both VPN being up and traffic passed through the secondary. The problem as i see it is the link monitor itself since after link recovery always fails via primary VPN since there is no route (I have enabled update-static-route option). I am missing something here? Does anyone successfully configured such a scenario? Appreciate any help.
You don’t need a link monitor. Configure the secondary phase 1 to monitor the primary and adjust your DPD timers according to your needs. With the default settings you have 3 tries with a 20 second interval, meaning one minute. Set the interval to 5 and you’re at 15 seconds.
With this configuration you also have an automatic failback if the primary is up again.
Thanks guys for your responses. Indeed changing the timers of the DPD does the trick and fails over fast. Anyone used this with a fortigate to cisco site to site vpn? Any reason for this to not work? And lastly ok DPD works and its easy but any idea why link monitor isn’t working properly?
Alternatively, if you need faster convergence in routing, could you just have both VPNs up at the same time and just configure a preferred priority on your main VPN? Should be fairly straight forward to do if you are connecting two FGTs together.
Yes I tried the same following the exact video tutorial but for some reason it doesn’t work. Although it fails over to the backup VPN it doesn’t recover. Do you have a configuration to share please?
Aggregates aren’t the right choice if you want an active/backup or primary/secondary type routing over your tunnels. Aggregates either use some variation of load balancing or “whichever tunnel is up first is used until that tunnel is not available and then I’ll switch to the other tunnel and stay using that tunnel until I am forced to switch back”. There’s no way to guarantee a specific tunnel is always used as your preferred tunnel.
This is entirely automatic since it’s based on route priority. Let’s say primary tunnel route has a priority of 0 and backup tunnel route has priority of 10. When both of your links are available both tunnels are going to be up. The route table will have both routes in it (due to same distance) but will send traffic using the route with the better priority (primary tunnel)
When the primary tunnel goes down for some reason (ie. the ISP link is down) then routing falls to backup tunnel because it’s the only available route. When the primary tunnel comes back up, the route table see two routes again and that the route associated with the primary tunnel has better priority then the route it was previously using so it flips back to using the primary tunnel
You do need to make sure you do this on both sides (same distance, different priority using the preferred tunnel as best priority) so the incoming traffic from the opposite firewall is coming in over the preferred tunnel as well.
Yeah did that but when I tried to recover the primary VPN the link monitor always failed although the VPN was up. I believe the problem is that the is no route because link monitor itself removed it.
IMO, the easiest method, by far, is to change the route priority but leave the distance the same on both routes.
When you change the distance then only the route with better distance is in the route table. When you keep distance the same and change priority both routes are in the route table but the better priority always wins. There is no route table updates to deal with if you do same distance/different priority due to both routes always being in the table.
One catch here would be if you’re not using a FGT on the other side. Since a same distance/different priority overlapping route in a FGT means both routes are IN the routing table, your worse priority route can still accept ingress traffic from the remote side of the tunnel. If that remote side firewall can’t do similar routing concepts when both tunnels are up, you might not have desired routing both ways.
HDClown is exactly right on how this works. Sorry I’m a little late to the party…
Link monitors have absolutely nothing to do with prioritizing routes, and are only there to help determine of an interface is up or down. Even without a link monitor in place, a tunnel will either be “Up” or “Down”. If the tunnel goes down, the Fortigate automatically disables routes for that tunnel, no link monitor needed. When creating the tunnel, don’t bother using the Wizard, in this case it will just make your life harder and the configuration look a mess. Do a custom tunnel and manually set everything up. As long as both ends match, it will work. In Phase 2 advances, leave local/remote subnets as 0.0.0.0 and make sure to check the “Auto-Negotiate” box. This way the routes and firewall determine what goes over the tunnel, not the tunnels subnets.
If you have two tunnels, one over the primary ISP, one over the secondary ISP.
Configure the “Primary tunnel” with distance of 10, priority of 0 on both ends of the tunnel.
Configure the “Secondary tunnel” with a distance or 10, priority of 5 (or any higher number than 0) on both ends of the tunnel.
You also need the firewall policy in place for BOTH tunnels on BOTH ends. You may want to consider using a zone for this to make it easier. Before adding your policy, you can make a Interface Zone called “Remote Office” and assign both tunnels to that zone. (on both ends of the tunnel). In the firewall policy, do from Internal/LAN to Remote Office, Any source, Any destination, no NAT.
Then do the same again, From Remote Office to Internal/LAN, Any source, Any destination, no NAT.
I have done this exact thing in no less than 80 firewall installs. This assumes Fortigate on both ends and assumes you want to allow all traffic across the tunnel. This configuration is very different when other firewall vendors are involved.
When you say “the tunnel fails” or “dead VPN” you mean the tunnel goes down, right?
In that case, the fortigate knows the tunnel is down.
You have two IPsec tunnels and one static route for each of them with the same distance but different priority, so the traffic will always go through the primary vpn ( using the route with less priority value).
If the primary vpn goes down, fortigate will mark it as down and the route pointing to it will be removed from the routing table. Because when an interface goes down (in fortigate, VPNs represent virtual interfaces), all the associated routes are removed from routing table.
And it will be used the next available route in the table for that destination, which is the one pointing to the secondary vpn.
If the primary vpn recovers, its associated route will be available in the routing table again, and the traffic will go throught primary vpn.
If otherwise you mean the tunnel is up but not working. Yes, you need link monitor to make the firewall send packet probes through the tunnel to see if it can reach the other side network, and with that information the firewall determines if the tunnel is not functional and removes the static route from the table.
