Configure and test Sophos Firewall WAN failover

A second internet connection does not automatically become a backup link on Sophos Firewall. A newly created WAN gateway is Active by default and therefore participates in load balancing. For a conventional primary/backup design, change the second gateway to Backup in the WAN link manager.

The quick approach for one primary and one backup connection:

Fully configure both WAN interfaces under Network > Interfaces and test each one separately.
Under Network > WAN link manager, set the primary gateway to Active and the backup gateway to Backup.
For the backup gateway, select Activate this gateway: If active gateway fails: ANY.
Configure reliable Failover rules for both gateways.
Test failover and failback—the return to the primary connection—with real DNS, HTTPS and application traffic.

This simple default internet failover does not require a separate SD-WAN route. SD-WAN is required when specific traffic must use selected paths or when path selection must be based on latency, jitter and packet loss.

Load balancing and failover are available for both IPv4 and IPv6. In an active/backup setup, both gateways use the same IP family as the traffic: two IPv4 gateways for IPv4 traffic or two IPv6 gateways for IPv6 traffic.

Understand Active, Backup and load balancing

The gateway type determines whether a connection normally carries internet traffic:

Active: When several active gateways are available, the firewall distributes new sessions according to the configured weights.
Backup: The gateway takes over only when its activation condition is met.

An active/active setup also provides failover. If an active gateway fails, the firewall redirects traffic to the remaining active gateways, where new sessions follow the configured load-balancing method. A backup gateway is not essential for this. Active/backup is the better choice when the second connection should deliberately carry no traffic during normal operation.

At least one WAN gateway must remain Active. If all gateways are marked only as backup, there is no normal default WAN path; traffic generated by the firewall in particular can then no longer be forwarded.

The Weight does not represent bandwidth. In weighted round-robin mode, a ratio of 2 to 1 means that the firewall assigns two new sessions to the first gateway and the next session to the second gateway. This does not split an individual download across both connections, and the volume of data transferred can differ considerably from this ratio.

The descriptions for SFOS 22 and 23 are not consistent about the default load-balancing method: The gateway detail description names Session Persistence, while the overview and setup descriptions present weighted round-robin. These descriptions alone do not reliably establish the method active on an installation. Session Persistence keeps more than a single existing connection on the same WAN link: Depending on the persistence factor, additional sessions from the same source IP can also be assigned to that link. After signing in, view the current method under Option 4: Device Console with this read-only command:

show routing wan-load-balancing

The command changes nothing. It shows whether Session Persistence or weighted round-robin is active and therefore helps explain unexpected path distribution. For a pure active/backup design, the method is usually of secondary importance because only one intended path is available in either the normal or failure state.

Change the load-balancing method deliberately

When several active links are in use, the global method can be changed in the Device Console. This changes path selection for new sessions across the affected IPv4 gateways, not just the backup link. Save the current state first and choose a suitable change window. The following IPv4 examples are alternatives: run only the command for the method you want, not both in succession.

set routing wan-load-balancing weighted-round-robin ip-family ipv4
set routing wan-load-balancing session-persistence source-only ip-family ipv4

Weighted round-robin distributes new sessions according to the weights of the active gateways. Session Persistence instead determines the gateway by hashing the selected persistence factor. SFOS supports source IP, destination IP, the combination of source and destination, and the individual connection made up of IPs, ports and protocol. With source-IP persistence, all sessions from the same source IP therefore use the same WAN link. If the most even possible distribution is more important, Sophos recommends not using Session Persistence.

Before making the change, save the output of show routing wan-load-balancing. Then use several new sessions to verify which gateway they actually take. The setting applies globally to the selected IP family, so it is not an isolated change to a single gateway.

To roll back, restore the recorded original setting for each changed IP family with the corresponding set routing wan-load-balancing ... ip-family ... command. If Session Persistence was active before the change, restore the exact factor, such as source-only, as well. Finally, confirm the restored setting with show routing wan-load-balancing.

WAN failover is not the same as HA failover. The WAN link manager changes the internet path on the same firewall. A Sophos Firewall HA cluster, by contrast, takes over when an appliance or monitored port fails.

Prepare WAN failover

Both provider connections must work independently first. The fundamentals of the WAN zone, IP assignment and gateways are covered in Plan Sophos Firewall zones and interfaces.

A simple example looks like this:

WAN1 Fiber: primary connection, gateway gw-fiber, Type: Active, Weight: 1
WAN2 DSL: backup connection, gateway gw-dsl, Type: Backup
Backup activation: If active gateway fails: ANY
Action on activation: Inherit weight of the failed active gateway
Action on return: Serve new connections through restored gateway

The names can be chosen freely and should clearly identify the connection. The gateway type and actions, however, are functional settings. Before failover, the backup gateway should already have a green status and real client traffic should have been tested successfully over the connection.

A safe return path for administration is also required. If the firewall is being changed remotely, WebAdmin should not be reachable only through the connection that will be disconnected during the test. A current configuration backup, a maintenance window and either someone on site or an independent management path prevent a simple failover test from becoming a prolonged outage.

Beforehand, also record all services that are tied to a public IP address. These include DNAT publications, IPsec peers, Remote Access, provider allowlists, mail servers and external monitoring systems. Outbound internet access may already work while these services remain unreachable or unauthorised through the new public address.

Configure primary/backup

Check WAN interfaces and gateway status

Under Network > Interfaces, configure both WAN ports with the static, DHCP or PPPoE settings supplied by the provider. When the interface is saved, its physical WAN gateway is created automatically in the WAN link manager.

For an additional physical connection, select an unbound port, for example PortD, and open its settings. Set Network zone to WAN and, for IPv4, complete IPv4 configuration, IP assignment, IPv4/Network mask, Gateway name and Gateway ID to match the provider connection. PortD is only an example port; use the provider’s addresses and netmask, not values from someone else’s configuration example. Select Save, then confirm that the corresponding gateway appears in the list. In the gateway editor, IP address means the gateway address and Interface means the interface address; do not confuse the two.

A new gateway is initially Active. After adding a pure backup connection, change its type immediately so that production traffic is not unintentionally distributed across both providers.

Custom gateways from Routing > Gateways, for example for XFRM, RED or MPLS, do not appear in the WAN link manager. They belong to a different routing design and are not treated as physical ISP gateways for this simple scenario.

Two physical WAN interfaces in the same subnet with the same gateway can cause routing and gateway instability. Sophos recommends a LAG instead of two independent WAN ports for this topology. If the provider assigns a WAN address outside the gateway subnet, the WAN interface additionally needs an alias IP within the subnet specified by the provider. Test both links separately in either case before testing failover.

When updating a physical WAN gateway through the XML API, use the following associations to troubleshoot Update Gateway in SFOS 23. These refer to the API Status, not the HTTP status; the Message.* names are message keys, not the exact displayed message text:

504 → Message.GatewayIpAndInterfaceIpIsSame: Check whether the gateway IP equals the selected interface’s address.
505 → Message.GatewayIpNotInInterfaceIpRange: Compare the gateway IP with the selected interface’s network.

Before retrying, check the interface address and its netmask or prefix, along with the next hop specified by the provider. For the provider addressing described above, also account for the required alias IP; do not simply substitute an arbitrary gateway address. After a correction, recheck gateway status and real client traffic. These documented associations do not establish that the validation was introduced in SFOS 23.

Select Data transfer on the gateway to open the gateway traffic report for a predefined or custom period. The graph updates hourly and the table daily. This view is useful for capacity and historical checks, but it is not real-time proof of the failover just triggered; gateway status, logs, and new test traffic remain decisive.

For your own reporting period, select Custom, set the start and end dates, and select Show to update the graph and table.

Configure the backup gateway

Under Network > WAN link manager, edit the gateway for the backup connection and set the following values:

Type: Backup
Activate this gateway: If active gateway fails
With one primary connection: ANY
Action on activation: Inherit weight of the failed active gateway
Action on failback: Serve new connections through restored gateway
Save the settings and check the gateway status.

With exactly one active gateway, ANY and ALL have practically the same effect. The distinction becomes important with several active connections:

ANY: The backup is activated as soon as one of the active gateways fails. This is appropriate when lost capacity should be replaced immediately.
ALL: The backup is activated only after all active gateways have failed. This is more suitable for a slow or expensive emergency connection.

With Manually, the gateway remains inactive until an administrator changes Type from Backup to Active in the WAN link manager. Use this option only if someone can detect the outage promptly and is authorised to enable the backup by hand.

Action on activation determines the weight of the backup gateway when it becomes active alongside other available gateways. Inherit weight of the failed active gateway is intuitive for a straightforward replacement scenario. Use configured weight is useful when the backup has deliberately lower or higher capacity and operates alongside remaining active connections.

For failback, Serve new connections through restored gateway is the less disruptive operational choice. New sessions use the primary connection again, while existing sessions remain on the backup path until they time out or disconnect. Serve all connections through restored gateway re-establishes existing connections and can interrupt them.

For SD-WAN routes, the result also depends on the route’s Primary Gateway. With WAN link load balance as Primary, Serve all connections through restored gateway re-establishes existing connections. With an individual active WAN link as Primary, only new traffic uses the restored gateway. If a backup WAN link itself is Primary, the firewall re-establishes the connections and continues to route them through that backup link. Test failback with both new and existing traffic on the affected SD-WAN route, not only by looking at gateway status.

When several active gateways fail in succession, Inherit weight of the failed active gateway takes the weight of the last active gateway to fail, not the sum of all lost weights. To set explicit weights, edit each affected gateway under Network > WAN link manager and set Weight. Capacity helps choose the ratio; the result remains session distribution, not a bandwidth reservation. Both methods can be configured for IPv4, IPv6 or both families; the commands above change only IPv4.

Choose suitable failover rules

The Failover rules determine when a gateway is considered unreachable. The available settings are:

Testing method: Ping or TCP
IP address
for TCP, additionally Port
combine multiple failure conditions with AND or OR

A physical cable failure is already detected at the interface. The default ping check of the gateway IP additionally verifies whether the directly connected provider device or first provider hop is reachable. However, it can remain green even when internet access beyond the reachable provider router is no longer working. Sophos therefore recommends a known public IP target for WAN/ISP gateways, such as 8.8.8.8 or 8.8.4.4.

In the gateway editor, under Failover rules, use Edit to change an existing rule or Add to create another. Specify Testing method, IP address and, for TCP, Port, then check the combination and saved values. For custom RBVPN, RED or MPLS gateways, choose a probe target behind the gateway rather than an arbitrary public internet address. For WWAN, a rule for 8.8.8.8 is created automatically in addition to the leased gateway IP check. This allows cellular monitoring when the provider does not permit pings to the leased gateway address; inspect both rules and their combination before making changes.

For IPv6, Sophos lists 2001:4860:4860::8888 as a public example. To check the upstream device, use the gateway’s IPv6 address rather than its link-local address.

A single target is not a complete health check either. For a more robust starting point, use two permanently reachable public IP addresses that are permitted by the organisation:

AND: Failover is triggered only when all linked checks fail. This reduces false failovers caused by a single unreachable target.
OR: A single failed check can trigger failover. This is more sensitive, but increases the risk of unnecessary switching.

8.8.8.8 and 8.8.4.4 are specific examples from Sophos, but they belong to the same operator and do not represent completely independent failure domains. In an important environment, two approved targets operated by different organisations are better. A ping target must answer ICMP reliably; for TCP, use a stable service whose port may be probed.

ANY/ALL on the backup gateway and AND/OR in the probe rules answer different questions. ANY/ALL determines how many active gateways must fail. AND/OR determines how several checks assess the failure of one gateway.

The global Gateway failover timeout value in the WAN link manager determines when the firewall treats an unresponsive link as failed. There is no universally correct value. A short timeout reacts faster, but packet loss or a brief issue with a probe target can cause unnecessary failover. Among other uses, the value also serves as the health-check interval for IPsec failover groups and should therefore not be changed in isolation for a single WAN link. Document the initial value, test it in a controlled manner and adjust it only afterwards based on the measured failover time.

Select Apply to apply a change to Gateway failover timeout. Recheck the displayed value afterwards; to roll back, restore the recorded original value and select Apply again.

Test failover and failback in a controlled manner

A cable test checks only for a local link failure. A provider outage behind a router that remains reachable becomes visible only when the configured public probe targets can no longer be reached. Ideally, test both cases separately.

Confirm the maintenance window, rollback plan and alternative administrator access.
Under Network > WAN link manager, document the status of the primary and backup gateways.
From a test client, check DNS, HTTPS and an important application. Also record the public outbound address currently in use.
For the link test, disconnect the primary WAN cable in a controlled manner. For the actual monitoring test, leave the firewall link up and interrupt the upstream connection beyond the provider device, where this can be done safely.
Wait longer than the configured Gateway failover timeout.
Check that the primary gateway is shown as failed and the backup gateway as active.
Start new DNS, HTTPS, VPN and application sessions. Check the firewall rule, NAT, destination reachability and new public outbound address.
Check gateway up/down events in Log viewer. For deeper analysis, dgd.log contains events related to WAN gateway management and link failover.
Restore the primary connection and test existing and new sessions separately. This shows whether the configured failback behaviour actually occurs.
Document the final status, applications and external reachability.

A successful ping proves only that the probe target responds. It confirms neither DNS nor NAT, VPN, published services or a business application. Packet Capture in Sophos Firewall WebAdmin helps verify the actual packet path; Sophos Firewall service logs explains dgd.log and other files.

Common errors and limitations

The backup connection already carries production traffic: The new gateway is still Active. For a pure backup, change it to Backup.
The backup does not become active when a connection fails: Check the gateway status, type, ANY/ALL, failover rules and Gateway failover timeout. With several active gateways, ALL can deliberately prevent activation while another active path remains available.
The gateway is green, but the internet does not work: The probe target is reachable while DNS, routing, the firewall rule, NAT or the application is failing. Check real traffic, Log Viewer and Packet Capture.
The firewall switches without a real provider outage: A single probe target is not responding, OR is too sensitive or the timeout is too short for the connection quality. Check the probe targets and measured packet loss.
Existing sessions break during the switch: The public source address or NAT state changes, so remote systems may reject the connection. WAN failover does not automatically provide zero downtime.
Outbound traffic works, but inbound services do not: The second provider requires suitable public reachability, DNS or Dynamic DNS, DNAT, firewall rules and, where applicable, certificates. DNAT for published servers and NAT fundamentals help isolate the issue.
VPN works only through the primary connection: The Remote Gateway, local listening address, FQDN, identities, tunnel configuration and return route must also match the backup path. Simple WAN failover does not create a second VPN connection. For policy-based tunnels and route-based tunnels with Traffic Selectors, configure and test an IPsec failover group explains the redundant design.

If applications, user groups or destination networks should use different connections, or if latency, jitter and packet loss should govern path selection, put the decision in Sophos Firewall SD-WAN routes and profiles. A mobile backup also introduces considerations such as the SIM, APN, data volume, CGNAT and signal quality; these are covered in Cellular WAN and 4G/5G failover.

Operations

Send gateway status changes by email where required. First configure the mail server, sender and recipient under Administration > Notification settings. Then enable the global Email notifications switch under System services > Notification list and select the Gateway status event under System. Selecting an event row alone does not send an email.
Check the gateway status and dgd.log after unplanned failovers.
Test failover and failback at least quarterly and after provider, interface, NAT, routing or firmware changes.
Document public IP dependencies, VPN peers, allowlists and inbound services.
Assign responsibility for provider outages, escalation and the return to normal operation.
Review probe targets regularly; a permanently changed or unreachable target must not silently determine the failover logic.
With several active connections, assess weights and Session Persistence against actual usage, not only nominal bandwidth.