Configure and test Sophos Firewall SD-WAN routes

SD-WAN routes on Sophos Firewall control which path specific traffic should take. This is useful with multiple WAN links, MPLS, route-based IPsec VPNs, VoIP, cloud services or applications that must use a specific provider.

In practice, SD-WAN problems rarely come from the button itself. The usual causes are criteria that are too broad, gateways evaluated incorrectly, NAT rules that do not fit, unexpected route precedence or tests that are too vague. This article therefore covers not only the click path, but also planning, validation and typical troubleshooting.

Video Guide

Short answer

Create an SD-WAN route under Routing > SD-WAN routes. Before doing so, it should be clear:

• which traffic should be steered
• which source, destination, services and users are affected
• whether DSCP, application or user are truly stable match criteria
• which gateway or SD-WAN profile is used
• whether traffic may only use the specified gateways
• whether static routes, VPN routes or route precedence compete with it
• whether NAT matches the route
• whether existing connections can really continue during failover
• how the path is verified in Log viewer and Packet capture

A good SD-WAN route is narrow enough to steer only the intended traffic. A broad route with Any can otherwise suddenly affect internal networks, management access or VPN traffic.

When SD-WAN routes make sense

SD-WAN routes are policy routing. They are used when the normal routing table alone cannot express which traffic should use which path.

Typical scenarios:

• Two or more internet links: send specific applications over a preferred link or failover path.
• VoIP or Teams: prefer a link with low latency or low jitter.
• Cloud services: deliberately steer Microsoft 365, ERP or backup traffic.
• Route-based IPsec VPN: steer traffic through an XFRM interface or gateway profile.
• MPLS or site link: reach internal destination networks over a dedicated path.
• Provider with source IP binding: send traffic through exactly the WAN interface that matches the allowed public IP.

If only one static destination network must be reached through a clear next hop, a static route can be simpler and more robust. SD-WAN is useful when criteria, gateway selection, failover or performance evaluation are required.

How Sophos SD-WAN routes are evaluated

Sophos Firewall processes SD-WAN routes according to a clear logic, not as a loose collection of rules:

1. Check the order in Routing > SD-WAN routes. Rules are checked from top to bottom. The first matching route wins.
2. Check the match criteria. Incoming interface, DSCP, source, destination, service, user or application decide whether the route matches.
3. Check gateway selection. The route uses fixed primary/backup gateways or an SD-WAN profile.
4. Include gateway and SLA status. With SD-WAN profiles, latency, jitter, packet loss and health check targets can influence the decision.
5. Check route precedence. Static, SD-WAN and VPN are evaluated according to the global order.
6. Understand fallback behaviour. If no matching SD-WAN path is available, another SD-WAN route or the default route may be used depending on the design.

That is why opening only the individual route is not enough. Order, gateway status, SLA, NAT, firewall rule and route precedence must be checked together.

Planning and requirements

Before creating the route, describe the desired data flow concretely. A sentence like “Teams should go over WAN2” is too vague. A small matrix is better:

• Source zone: LAN
• Source network: Client_Net_10.20.0.0_24
• Destination: Microsoft 365 destination group, Internet IPv4 group, FQDN group or specific network
• Services: HTTPS, UDP 3478-3481 or defined services
• DSCP or application: only use if marking or application detection can be verified reliably
• User/group: optional, only if user matching is stable
• Primary gateway: WAN2
• Fallback: WAN1
• Fallback rule: allow default route or enforce Route only through specified gateways
• NAT: MASQ or fixed SNAT IP matching the gateway
• Test: client IP, destination, expected gateway, expected log entry

The clearer this matrix is, the less guesswork is needed later. Especially with VoIP, VPN, cloud services and multiple sites, do not start with Any just because it is quicker to click.

Requirements

• Sophos Firewall in gateway mode.
• At least one configured gateway under Network > WAN link manager or a suitable VPN/XFRM path.
• Known source and destination networks.
• Matching firewall rules for the traffic.
• Matching NAT rules if traffic must be translated.
• Logging on the relevant firewall rules.
• Access to Log viewer and Diagnostics > Packet capture.

For zones, interfaces and gateways, see Configure Sophos Firewall zones and interfaces. If the SD-WAN route involves a route-based IPsec VPN, also read Create IPsec route on Sophos Firewall.

Configuration and dependencies

Create SD-WAN route

Menu path:

Routing > SD-WAN routes

Procedure:

1. Open Add.
2. Select IPv4 or IPv6.
3. Use a clear name, for example Clients_M365_WAN2.
4. Select Incoming interface or the source context to match the design. With route-based IPsec, this can also be an XFRM interface.
5. Optionally select DSCP if incoming packets are marked reliably.
6. Set source networks or users only as broadly as needed.
7. Select destination networks, FQDN hosts, internet services or the Internet IPv4 group deliberately.
8. Limit services to the required protocols.
9. Use application objects only if application detection and the first connection can be tested.
10. Select the gateway or SD-WAN profile.
11. Decide whether Route only through specified gateways should be active.
12. Save the rule and place it correctly in the order.
13. Test with a defined client.

The exact interface can vary slightly depending on the SFOS version. What matters is that the route matches the intended flow and does not accidentally capture more traffic than planned.

For internet destinations, Destination networks should not be left as Any for convenience. Sophos recommends the standard Internet IPv4 group or the individual standard ranges such as Internet IPv4 (1-9) for public IPv4 destinations. This reduces the risk that internal networks suddenly go toward a WAN gateway because of a broad SD-WAN route.

Application objects are useful, but not as deterministic as a destination network and a service. Sophos Firewall uses details from the first session to assign later sessions of an application to an SD-WAN route. This application session information has a TTL of 3600 seconds from the start of the session. For critical paths, test with real application traffic, not only with a single ping or policy test.

Choose gateway and SD-WAN profile

SD-WAN routes can point directly to gateways or use SD-WAN profiles. The right choice depends on the goal.

• Fixed gateway: useful when traffic should deliberately use one link.
• Gateway with backup: useful when one link is preferred but failover should be possible.
• SD-WAN profile with First available gateway: useful when gateways should be checked in a defined order.
• SD-WAN profile with Load balancing: useful when several links should be used at the same time and session persistence or weighting fits the service.
• SD-WAN profile with SLA: useful when latency, jitter or packet loss should decide gateway selection.
• XFRM interface or VPN path: useful when route-based IPsec is part of the routing design.

With multiple WAN links, also check whether gateway monitoring, failover criteria and provider routing are realistic. A gateway can be technically “up” even though a specific target application does not work correctly through that provider.

For SD-WAN profiles, the health check target should match the application. A generic ping to the internet does not prove that Microsoft 365, VoIP, a cloud ERP or a remote gateway works cleanly through this provider. For critical applications, a short baseline helps: normal latency, jitter, packet loss, expected gateway and behaviour during provider failure.

With First available gateway, the firewall checks gateways in the defined order and takes the first available path. With Load balancing, it distributes traffic across several suitable gateways; Session Persistence and Gateway Weights then decide how stable a session stays on the same gateway and how strongly individual links are weighted.

With Best quality, the firewall evaluates only the selected criterion, such as latency or packet loss. With Custom SLA, the defined thresholds for latency, jitter and packet loss must match. If no gateway meets the SLA, the decision falls back to the selected routing strategy. This should be deliberately provoked during testing; otherwise, behaviour during an outage is only guessed.

If Route only through specified gateways is active, traffic is dropped when the specified gateways or profile are unavailable. If the option isn’t active, the firewall can use other matching SD-WAN routes or ultimately the default route. Both can be correct: hard dropping is often better for compliance or provider IP binding, while another fallback is usually desired for normal internet failover.

Another operational case is easy to miss: If a backup gateway is deleted, Sophos Firewall sets the backup value to None. If the primary gateway fails, the firewall uses the backup gateway. When the primary later becomes available again, new connections use the primary again, but existing connections can remain on the backup. If a primary gateway or SD-WAN profile is deleted, however, the corresponding route can disappear and traffic can fall back to the default route.

Sophos describes dynamic switching as zero-impact failover. In practice, don’t read this as a guarantee for every application. For normal connections, reroute-connection can preserve connections during a gateway change. With SNAT, the limitation is clearer: If MASQ or Override Source Translation with different translated source IPs is used, the firewall deliberately doesn’t reroute those SNAT connections because the changed source IP would lead to communication failures. For provider IP bindings, SIP/RTP, banking portals, cloud APIs and fixed allowlists, failover should therefore be tested with real application traffic.

Check order and route precedence

SD-WAN routes do not stand alone. Depending on the design, they compete with directly connected networks, static routes, VPN routes and global route precedence.

Important questions:

• Is there a more specific static route to the destination?
• Does a broader SD-WAN route match higher up?
• Should SD-WAN be evaluated before or after Static?
• Is a policy-based or route-based IPsec VPN involved?
• Is SSL VPN traffic affected, which belongs to the static category from a routing perspective?
• Does the route affect only forwarded client traffic or also reply packets and system-generated traffic?

The global order is explained in Safely change Sophos Firewall route precedence. For the special cases Reply Packets and System Traffic, see Check Sophos Firewall SD-WAN routing for reply packets and system traffic.

Enable and use SD-WAN logs

For pure path tests, firewall logs are often not enough. Sophos Firewall can also write SD-WAN-specific logs that make health check status, SLA decisions, profile events and route changes more visible.

Check:

1. Open System services > Log settings.
2. Enable logging for SD-WAN.
3. Enable SD-WAN profile, SD-WAN SLA and SD-WAN route as needed.
4. In Log viewer, check the SD-WAN module.
5. In firewall logs, open the extended log selections and display SD-WAN information.

This is particularly useful when a gateway appears available in WAN Link Manager, but the SD-WAN route switches to another path because of SLA, health check or profile decisions.

Do not forget NAT

Routing decides where a packet goes. NAT decides whether the source or destination address is changed. Both must fit together.

Typical examples:

• Internet traffic through WAN2 may need MASQ or a fixed SNAT IP on WAN2.
• Providers or cloud services may allow only one specific public IP.
• For internal networks or VPNs, NAT is often wrong because the real source IP should be preserved.
• After failover, the public source IP can change and remote systems may drop sessions.

If an SD-WAN route looks correct but the application still fails, check NAT early. The basics are covered in Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Validation and troubleshooting

Test and validation

A green gateway status does not prove that the SD-WAN route hits the expected traffic. The test must check a real flow.

Useful process:

1. Use a test client with a known IP.
2. Define destination and service exactly.
3. Enable firewall rule logging.
4. Start the connection.
5. In Log viewer, check source, destination, service, rule ID, NAT ID and gateway.
6. Check the usage counter of the SD-WAN route.
7. With SD-WAN profiles, also check SD-WAN logs for SLA or health check decisions.
8. If unclear, use Diagnostics > Packet capture with a narrow filter.
9. Temporarily fail the primary gateway if failover must be validated.
10. After failback, check whether sessions and new connections behave as expected.

For packet flow analysis, see Test Sophos Firewall rules with Log Viewer, Policy Test and Packet Capture. Important: The Policy Tester does not replace a real packet flow test for SD-WAN.

Common mistakes

• Destination Any for convenience: Too much traffic is captured by SD-WAN. Better choose target networks, FQDN hosts or internet services more narrowly.
• Internet traffic with Any instead of Internet IPv4 group: Internal destinations can be matched too, especially if route precedence places SD-WAN before Static.
• SD-WAN route is too high: A more specific application or route is overridden. Better check order and hit counters.
• NAT does not match the gateway: The application sees the wrong source IP or the return path breaks. Better check NAT rule and MASQ/SNAT.
• Gateway monitoring is too broad: The gateway appears active although the target application is not reachable. Better choose SLA/monitoring targets that match the service.
• Application objects misunderstood: Application-based routes require real application traffic and can depend on the first session. Better validate with destination, service, Log Viewer and repeated tests.
• Direct web proxy tested incorrectly: Direct web proxy traffic doesn’t match SD-WAN like normal HTTP/HTTPS client traffic. If clients use the direct proxy, a service match on HTTP/HTTPS is often not enough. Then the direct proxy port from Web > General settings > Web proxy listening port must be used as the service, or the special case must be deliberately tested with Any. For reply packets, source network and incoming interface also don’t always match expectations.
• SD-WAN logs are off: Path changes remain difficult to understand. Better enable SD-WAN profile, SLA and route logging.
• Route precedence ignored: A static route or VPN route behaves differently than expected. Better document and test route precedence.
• Reply traffic classified incorrectly: Replies do not use the expected path. Better check Packet Capture and the reply packet option.
• Usage counter misread: The counter only shows traffic matching the route’s source and destination. Reply traffic can use the same path and still not appear in the expected counter.
• Deleted gateway or deleted profile: An SD-WAN route can change or disappear when dependent gateways or profiles are deleted. Traffic may then fall back to the default route.
• Several changes at once: The cause remains unclear. Better make one change, test it and then continue.

Troubleshooting

If the SD-WAN route does not work as expected, do not immediately “solve” the issue by making rules broader. A clean isolation is better.

Check:

1. Does the packet reach the firewall at all?
2. Does it hit the expected firewall rule?
3. Does the SD-WAN route match according to the counter?
4. Is another SD-WAN route higher up more specific or broader?
5. Does the service really match, for example TCP/UDP and port?
6. Is NAT applied, and is that intended?
7. Does the packet leave the firewall through the expected gateway?
8. Does the reply come back?
9. Is there a static route, VPN route or route precedence setting influencing the path?
10. Do SD-WAN logs show an SLA, health check or profile change?
11. Is Route only through specified gateways active and is traffic therefore deliberately dropped?
12. Was a gateway, SD-WAN profile or migrated linked firewall rule deleted?
13. With Direct Web Proxy: Is the direct proxy port checked instead of only HTTP/HTTPS?
14. With SNAT/MASQ: Does the translated source IP change during failover?

If Packet Capture does not see a packet at all, the issue is before the firewall: client gateway, VLAN, switch, local routing or incorrect test. If the packet arrives but uses the wrong path, SD-WAN criteria, order, NAT and route precedence are the next checkpoints.

Operational check

SD-WAN routes should be documented and checked regularly after introduction. This is especially important when providers change, new VPNs are added, additional WAN links are introduced or cloud services change.

Document:

• purpose of the route
• source and destination criteria
• DSCP, user or application matching if used
• services
• gateway or SD-WAN profile
• setting for Route only through specified gateways
• NAT expectation
• failover behaviour
• test client and test destination
• owner and review date

For business-critical applications, it should also be clear who reacts to provider outages, failover issues or changed public IPs.

Checklist

• Traffic goal and route intent clearly described.
• Source, destination and services are not unnecessarily broad.
• Internet destinations are not modelled unnecessarily with Any, but with internet groups or specific destinations.
• DSCP, user and application matching are only used if the real traffic was tested with them.
• Gateway or SD-WAN profile deliberately selected.
• Route only through specified gateways deliberately enabled or disabled.
• Firewall rule and NAT rule match the route.
• Route precedence checked.
• SD-WAN logs enabled for acceptance or troubleshooting.
• Reply packets and system-generated traffic included only when needed.
• Log Viewer and Packet Capture used for validation.
• Failover and failback tested if they are part of the design.
• Route documented and assigned to an owner.

Frequently asked questions