This is the next in a series of labs I designed and implemented while studying for the Fortinet NSE 4 7.2 exam.
Primary Tunnel Configuration — I used Custom configuration vs. using a Wizard, but most values are default. I am including the configuration from only the 61E.
I didn’t have the “Add Route” feature enabled so that I could try to configure my own static routes. In practice, you should either enable this feature or use a dynamic routing protocol. Interestingly, once you have built the configuration and go back to it, “Add Route” will be automatically enabled.
As the documentation suggested, I left the Phase 2 selectors (Local and Remote Address settings) default and let the firewall policy control which traffic traverses the tunnel.
Tunnel comes up. I verify I can ping and ssh to the server from the client.
Backup Tunnel Configuration. I intentionally misconfigured the Phase 1 and Phase 2 SA’s to generate errors.
Backup tunnel static route. Note priority is higher than primary’s static. The Fortigate will prefer the higher priority route as long as it is active.
As expected, we get Phase I error in the VPN Events log. Fortinet documentation suggests using “debug application ike -1” to troubleshoot IKE.
CLI troubleshooting. Note differences between working Prim tunnel and not working Bck tunnel.
Fix the Phase 1 encryption to match. Interestingly, we get different log messages at either end of the tunnel. The 61E is still complaining about Phase I errors but showing Phase 2 attempt to negotiate. The 201F logs show the behavior I expected: Phase 1 completing, but Phase 2 erroring.
Fix the Phase 2 SA’s to have matching encryption and now the tunnel comes up.
Routing table shows both static routes. Note routes have different priorities, which should send traffic over the primary tunnel.
I tested failing the backup tunnel by disconnecting the cable between the devices. With the default Dead Peer Detection setting of “On Demand” the tunnel never went down even though the interface was down. I changed the DPD setting to “On Idle” and the tunnel went down around 90 seconds after disconnecting the cable, which makes sense based on the timers.
Check the routing table again and note the static route via the Backup tunnel has been removed.
I successfully tested tunnel failover by disconnecting the primary connection between firewalls. After several tests, I was able to get more consistent results with DPD set to “On Idle” (with On Demand, failover did happen, but both tunnels didn’t always go down) and was able to get quicker failover by tuning the DPD timers. I’m sure we could eventually get more consistent behavior with DPD “On Demand”, but troubleshooting DPD is out of the scope of this lab exercise. With the primary tunnel down, note the routing table contains only the route via the backup tunnel.
Log notes the DPD failure, removal of the SA’s, and subsequent failed attempts to bring the tunnel back up.
Add Policy Route to send SSH traffic over backup tunnel.
Policy route is preferred over RIB route. Sniffer shows ssh packets going over backup tunnel despite the fact the primary tunnel has best route in routing table.
