A VPN that only fails over when the internet circuit is completely dead is not a resilient VPN. Most business-impacting faults sit in the grey area: packet loss, upstream routing issues, failed DNS, or a carrier hand-off that remains electrically up but cannot reach the applications users need. To configure FortiGate VPN failover properly, the firewall must detect loss of useful connectivity, select an alternate path, and restore the preferred path without creating unstable tunnel behaviour.
For Australian organisations connecting branches, warehouses, project sites and cloud workloads, this is a practical continuity requirement. The right design protects business traffic when an NBN service, fibre circuit, 4G or 5G backup link, or remote ISP suffers a partial failure. It also keeps security policy, inspection and routing controlled by the FortiGate rather than leaving failover to chance.
Start with the right FortiGate VPN failover design
The most reliable approach is usually route-based IPsec VPNs combined with SD-WAN. Each site has two or more underlay paths - for example, a primary fibre service and a secondary business-grade 4G/5G connection - and an IPsec tunnel is established across each viable path. SD-WAN then uses performance checks and service rules to choose the preferred tunnel for each traffic type.
This design is more flexible than relying only on static route distance. A static route can withdraw traffic when an interface disappears, but it may not recognise that the WAN link is still up while the path beyond the modem, carrier network or remote endpoint has failed. SD-WAN health checks can test a meaningful destination and make a decision based on latency, jitter, packet loss or reachability.
A smaller deployment can use two IPsec tunnels with different route distances and administrative priorities. That can be sufficient where there is one remote site, simple traffic flows and clear separation between primary and backup links. The trade-off is reduced visibility and less control over application-aware routing. For multi-site networks, SD-WAN is generally the cleaner operational choice.
Before configuring anything, confirm that both sites can support the intended topology. A head office FortiGate with two WAN services does not automatically provide full resilience if the branch has only one WAN service. True path diversity requires independent underlays at both ends. Where possible, avoid placing both services through the same carrier equipment, building entry point or physical exchange path.
Build stable IPsec tunnels before adding failover logic
Create a separate route-based IPsec tunnel for each transport path. The primary tunnel might use WAN1 at both sites, while the secondary tunnel uses WAN2, or an alternate public IP address, at each end. This arrangement makes path selection clear and allows each tunnel to be monitored independently.
Use consistent Phase 1 and Phase 2 settings across paired tunnels unless a provider constraint requires otherwise. Modern, mutually supported encryption suites, strong authentication, appropriate Diffie-Hellman groups and defined rekey timers reduce avoidable negotiation failures. Enable Dead Peer Detection so the FortiGate can identify an unresponsive peer and clear stale security associations.
However, Dead Peer Detection is not a substitute for a service-level health check. It answers whether the VPN peer is responding, not whether users can reach a line-of-business application, cloud service or internal DNS server through the tunnel. A tunnel can remain technically established while the practical service is unavailable.
Assign tunnel interfaces clearly, using names that show the destination and transport path. Names such as `melbourne-primary` and `melbourne-backup` are far more useful during an outage than generic labels. Apply least-privilege firewall policies between local and remote subnets, and ensure security profiles are aligned across both paths. A backup tunnel should not become an uninspected bypass around the primary security design.
Configure FortiGate VPN failover with SD-WAN health checks
Add the VPN tunnel interfaces to the SD-WAN zone used for site-to-site traffic. In many designs, the physical WAN interfaces also belong to an SD-WAN zone for internet-bound traffic, while the overlay tunnels are members of a separate zone. This keeps decisions about internet egress distinct from decisions about encrypted branch connectivity.
Create a health check that tests a stable, relevant target beyond the remote FortiGate. A remote internal gateway, DNS server or application endpoint is often a better choice than the peer's public IP address. The test target should represent the service users actually require, while remaining reliable enough to avoid false alarms.
Set performance thresholds that suit the application, rather than using arbitrary aggressive values. Voice and real-time operational systems are sensitive to jitter and loss. File transfers and routine business applications may tolerate more variation. If a 4G backup service naturally has higher latency, do not configure a threshold that declares it failed simply because it behaves like a mobile service.
Then create an SD-WAN rule for traffic destined to the remote networks. Select the primary VPN tunnel as the preferred member and the secondary tunnel as the alternate, using the health check to determine eligibility. This is commonly configured as priority-based selection where predictable primary-versus-backup behaviour is wanted. Load balancing can be valuable for large environments, but it adds design considerations around session handling, bandwidth symmetry and application behaviour.
Advertise or install routes to remote networks through the SD-WAN zone, rather than retaining conflicting direct routes to individual tunnel interfaces. The exact routing method depends on the design. Static routes work well for straightforward branch networks, while BGP is usually a stronger choice for larger estates, multiple hubs, cloud connectivity or changing prefixes. Whatever method is used, route preference must reflect the intended active path.
Prevent common failover faults
The most common fault is monitoring the wrong thing. A successful ping to a public IP does not prove that the branch LAN, remote applications or return routing are available. Health checks need to validate the business path, not merely the carrier path.
Return traffic is the next issue. Both sites must agree on how to reach each other's protected subnets through the active tunnel. If the branch fails over but the head office continues returning traffic through the old path, sessions will break. Dynamic routing can reduce this risk in complex networks, but only when route advertisements, filtering and preferences are deliberately designed.
NAT is another frequent source of confusion. Traffic between protected site-to-site subnets should normally be exempt from source NAT. Internet-bound traffic may use NAT, but it should not be confused with VPN routing. Review policies in both directions and validate that the central NAT or policy NAT approach is consistent across primary and backup paths.
Also consider stateful sessions. Existing TCP sessions may need to reconnect when traffic moves to another tunnel, particularly where public IP addresses, NAT mappings or application security controls differ. This is expected in many failover events. The objective is fast recovery, not the unrealistic promise that every active session will survive every carrier outage.
Test the failure scenarios that matter
A configuration is not complete when both tunnels show green. Test it during an approved change window and record the actual recovery time. Start with controlled tests: disable the primary tunnel, disconnect the primary WAN service, and verify that remote subnet traffic uses the backup tunnel. Then restore the preferred path and confirm that routing returns as intended without repeated flapping.
Test partial failures as well. Block the health-check destination, simulate loss beyond the ISP gateway where practical, and confirm that the FortiGate marks the primary path unhealthy. Review SD-WAN health-check status, routing tables, VPN event logs and firewall logs while the test is running. These records are the evidence needed to troubleshoot a real incident later.
A useful validation runbook should confirm four outcomes:
- Primary tunnel traffic reaches required remote services under normal conditions.
- Backup tunnel traffic reaches the same services after a primary-path failure.
- Return traffic follows a valid path and does not encounter NAT or policy failures.
- The preferred tunnel resumes only after it meets the defined health criteria.
FortiOS features and menu locations can vary by release, so configuration should be checked against the specific firewall model, FortiOS version and network design. For organisations that need resilient connectivity without trial-and-error implementation, FortiSecure Store can pair genuine Fortinet solutions with certified Australian configuration support. The best failover design is the one that has been tested against your actual applications, carrier services and recovery expectations before the outage makes those details urgent.