An ISP outage can stop cloud applications, payment terminals, VPN access, and customer communication even when the firewall itself is working correctly. When you configure WAN failover properly on a FortiGate firewall, traffic moves to a healthy secondary internet connection based on measured link performance, not simply because a physical port still appears to be up.
For businesses with cloud services, remote teams, and security-sensitive operations, failover is not a feature to enable and forget. It is a continuity design that needs the right circuits, monitoring targets, routing rules, security policies, and testing. A second ISP connection only protects the business when the firewall can accurately detect a real failure and direct traffic through the alternate path without creating routing or VPN problems.
Why WAN Failover Requires More Than Two Internet Links
A common mistake is assuming that WAN1 is healthy because its Ethernet link remains active. The local modem may still be connected while the ISP has a routing issue, a DNS failure, severe packet loss, or an upstream outage. From the users’ perspective, the internet is unavailable, but the firewall may continue sending traffic to WAN1 unless it is checking meaningful external targets.
FortiGate appliances can use link-monitoring and SD-WAN health checks to assess latency, jitter, packet loss, and reachability. These measurements allow the firewall to remove or deprioritize a poor-quality path and use the backup circuit when required. This is especially useful for voice, video meetings, cloud ERP platforms, and VPN traffic, where a slow or unstable line may be as damaging as a complete outage.
The preferred approach for most current FortiGate deployments is SD-WAN. It provides clearer control over link quality, application-aware routing, and failback behavior than a basic pair of static default routes. Static routing can still be appropriate for a small network with straightforward outbound traffic, but it offers less flexibility as business requirements grow.
Plan the Failover Design Before Configuration
Start by confirming what each WAN circuit can support. Identify its public IP addressing, gateway, bandwidth, contract type, and whether it uses DHCP, PPPoE, or a static configuration. If the backup link is 5G or LTE, confirm its data allowance, carrier NAT behavior, and whether it provides a fixed public IP. A mobile connection may be ideal for keeping cloud applications and email available, but it may not support inbound services or site-to-site VPNs in the same way as a fiber circuit.
Decide which traffic must remain available during a failure. Many organizations want all internet traffic to move to the secondary WAN. Others need higher control: business applications, DNS, email, and VPN traffic should use the backup link, while guest Wi-Fi, large downloads, and nonessential updates are restricted. This decision protects a limited backup connection from being consumed by low-priority use.
You should also identify services that rely on a public IP address. Remote-access VPN portals, published web applications, email gateways, and IP allowlists may require separate planning. Outbound failover is relatively simple. Inbound continuity may require secondary DNS records, a cloud load-balancing service, a second VPN endpoint, or a service provider that supports the required routing design.
Configure WAN Failover with FortiGate SD-WAN
The precise menu names can vary by FortiOS version, but the operating principle remains the same. Configure both internet interfaces first and verify that each has independent internet access before placing them in an SD-WAN zone.
Add and verify both WAN interfaces
Configure WAN1 and WAN2 with the information supplied by each ISP. Confirm the interface status, default gateway, DNS resolution, and direct connectivity from the FortiGate. Do not proceed based only on a green link indicator. Test access to multiple external destinations from each connection.
If the second connection is intended solely for emergencies, it should still be tested under expected load. A low-cost backup circuit may have limited upload capacity or high latency that affects voice calls, cloud backups, and remote desktop sessions.
Create the SD-WAN zone and add members
Enable SD-WAN and add WAN1 and WAN2 as members of the SD-WAN zone. Assign an appropriate cost or priority according to the desired design. In a primary-backup arrangement, WAN1 is normally preferred and WAN2 is used only when WAN1 fails its health check. In an active-active arrangement, both links can carry traffic according to performance or load-balancing rules.
Update the default route so that outbound traffic uses the SD-WAN zone rather than a single physical WAN interface. Firewall policies that previously pointed directly to WAN1 must also be reviewed and adjusted to use the SD-WAN zone. Missing this step is one of the most frequent reasons a backup circuit is installed but never used.
Build health checks that detect actual service failure
Create an SD-WAN health check using reliable public targets. One target alone can create false alarms if that destination has a temporary issue, so use more than one where possible. Common choices include stable public DNS addresses and trusted cloud endpoints relevant to the business.
Set thresholds that reflect how users experience the connection. Packet loss, latency, and jitter limits should be realistic for the available circuits. Extremely aggressive thresholds can cause unnecessary switching between links. Thresholds that are too relaxed may leave users on a degraded connection for too long.
A sensible design checks reachability as well as performance. For example, WAN1 can remain preferred while it meets latency and packet-loss expectations. If it becomes unreachable or fails the agreed thresholds, FortiGate redirects matching traffic to WAN2. When WAN1 recovers, the firewall can return traffic to it based on the selected failback settings.
Define SD-WAN rules by business priority
For a simple primary-backup configuration, create an SD-WAN rule that selects WAN1 first and WAN2 second. Attach the health check so FortiGate only selects a member that is meeting the required service level.
Organizations with more demanding workloads should use separate rules. Voice and video traffic may select the link with the lowest jitter. Business SaaS applications may prefer the most reliable circuit. General web browsing can use either available WAN, while guest traffic can be limited to the secondary link during an outage.
This is where failover becomes a business-control tool rather than a basic connectivity feature. The best rule set depends on the applications, link capacity, and risk tolerance of the organization.
Keep Security Policies, VPNs, and DNS Aligned
WAN failover does not weaken FortiGate security inspection when policies are configured correctly. Outbound policies should continue to apply web filtering, antivirus, IPS, application control, and logging as required. Review NAT settings as well, because each ISP connection may use a different public IP address.
VPNs need special attention. An IPsec tunnel tied to a single WAN interface may not automatically rebuild through the secondary circuit without additional configuration. Depending on the topology, you may need redundant tunnels, dial-up VPN design, dynamic routing, or peer definitions that account for both ISP addresses. Remote-access VPN users also need a documented alternate connection method if the primary public IP becomes unreachable.
DNS deserves equal care. If your organization hosts services externally, public DNS records may point only to the primary WAN address. Failover for outbound users will work, but customers or remote employees may still be unable to reach the published service. Design inbound resilience separately rather than assuming WAN failover solves both directions of traffic.
Test Failure Scenarios Before You Need Them
A failover design is only proven after controlled testing. Schedule the test during an approved maintenance window and monitor the FortiGate event logs, SD-WAN health-check status, session behavior, and application availability.
Disconnect the primary circuit or disable its interface, then confirm that traffic uses WAN2. Test business-critical applications, DNS resolution, cloud services, remote access, and site-to-site VPNs. Restore the primary connection and verify the intended failback behavior. Some sessions will reset during a path change, which is normal for many internet connections. The objective is to minimize interruption and confirm that essential operations recover quickly.
Repeat this test after major ISP changes, firewall upgrades, new VPN deployments, or changes to cloud security controls. Documentation should include interface details, health-check targets, SD-WAN rules, public IP information, support contacts, and the tested recovery process.
When Static Routes May Be Enough
A basic configuration with two default routes of different administrative distance can work for a small office with simple outbound browsing requirements. FortiGate uses the preferred route until it is removed or considered unavailable, then it uses the route with the higher distance.
The limitation is that static routes alone may not detect every upstream failure. They also do not offer the same visibility or policy-based steering available with SD-WAN. For a business that depends on cloud platforms, hosted telephony, multiple sites, or remote users, SD-WAN is usually the better long-term choice.
Digital World Technology can help UAE businesses select the appropriate FortiGate model, verify ISP requirements, configure SD-WAN failover, and test the result before an outage forces the issue. The right design keeps staff productive while maintaining the inspection and access controls that protect the network.
A backup WAN connection is most valuable on the day nobody has time to troubleshoot it. Build the rules carefully, test them under controlled conditions, and keep the configuration reviewed as your applications and connectivity needs change.