Skip to content
Avanet

Configure and test Sophos Firewall SD-WAN routes

Sophos Firewall

With an SD-WAN route, you control which gateway a defined traffic flow uses on Sophos Firewall. This is useful with multiple internet connections, MPLS, route-based IPsec VPNs, VoIP or cloud services. The route must be narrowly defined and tested with real traffic; otherwise, it can easily capture internal networks or use the wrong public IP during failover.

If Sophos Fusion (formerly Sophos Central) should generate the route-based tunnels and site paths for multiple managed firewalls, use Set up and verify a Sophos Fusion SD-WAN connection group instead. This article explains the local SD-WAN route, which also remains important when validating centrally deployed paths.

Short answer

Create an SD-WAN route here:

Routing > SD-WAN routes > IPv4 / IPv6 > Add

Four points must be clear beforehand:

  • which traffic should match based on incoming interface, source, destination and service
  • which primary/backup gateway or SD-WAN profile should be used
  • whether only these gateways are allowed and which NAT configuration matches them
  • how to verify the route, gateway and return path with Log Viewer and Packet Capture

For public IPv4 destinations, avoid using Any indiscriminately. Use the Internet IPv4 group or specific destinations whenever possible. If SD-WAN precedes Static in route precedence, a broad Any route can otherwise send internal traffic to the WAN gateway as well.

The video complements the guide to planning, configuring and validating SD-WAN routes on Sophos Firewall.

Use cases and planning

When SD-WAN is preferable to a static route

A static route is sufficient when a destination network is always reachable through a fixed next hop. SD-WAN routes add criteria such as source, service, user or application and can select gateways based on availability or quality.

Typical use cases include:

  • sending specific clients or services through WAN2 and failing over to WAN1
  • sending VoIP or cloud applications through a path with low latency and packet loss
  • using MPLS, LTE/5G or a route-based IPsec tunnel as the primary or backup path
  • binding traffic to a provider whose public IP is allowlisted by a remote system

Planning example and requirements

Before creating the route, describe a specific traffic flow. For Microsoft 365 traffic, the plan could look like this:

  • Incoming interface: internal LAN interface
  • Source network: Client_Net_10.20.0.0_24
  • Destination: a self-maintained Microsoft 365 destination group or Internet IPv4 group
  • Services: HTTPS and, if required, a service group for UDP 3478-3481
  • Primary gateway: WAN2
  • Backup gateway: WAN1
  • Fallback: allow the default route or enable Route only through specified gateways
  • NAT: MASQ or a fixed SNAT IP matching the selected gateway
  • Test: defined client IP, destination, expected gateway and expected log entry

You also need appropriate firewall rules, NAT rules for traffic that must be translated, firewall logging enabled and access to Log viewer and Diagnostics > Packet capture. WAN gateways are listed under Network > WAN link manager; custom gateways for MPLS, RED or XFRM are created under Routing > Gateways.

Configure Sophos Firewall WAN failover explains the general active/backup behaviour of the default WAN path; for interface and gateway fundamentals, see Configure Sophos Firewall zones and interfaces.

With route-based IPsec, direction matters: An XFRM interface selected as the Incoming interface matches traffic entering from the tunnel. For LAN-to-VPN traffic, select the gateway of the XFRM interface as the primary gateway or add it to an SD-WAN profile. The tunnel and routing fundamentals are covered in Create an IPsec route on Sophos Firewall.

For a narrower Teams example, add the fictional group Sales_Team under Users or groups and Teams_VoIP under Application objects. Replace both names with your own user group and the applications actually required. Together with the LAN interface, Client_Net_10.20.0.0_24, the intended destinations and services, this steers only the matching flow through WAN2/WAN1. Separately check a narrow allow rule from LAN to WAN for this source, destinations and services, the intended user authorization, and NAT on both paths. The SD-WAN route does not grant access; the test must show the planned user, application, Firewall Rule ID and NAT ID.

MPLS between a branch and head office

A bounded example connects 10.20.0.0/24 at the branch to web servers in the head-office network 10.30.0.0/24: the incoming interface is the branch LAN, the primary gateway is MPLS-1, the backup is MPLS-2, and services are limited to the required TCP 80/TCP 443. The head-office firewall needs the corresponding return route from 10.30.0.0/24 to 10.20.0.0/24 through its own MPLS gateways. Networks, interfaces, gateways and services are example values to adapt to the actual topology. The separate branch firewall rule allows LAN to the actual MPLS zone, here MPLS_DMZ, only for these networks and services; head-office rules must also permit the intended flow. This routed design preserves the original private addresses without SNAT. It is not a universal NAT requirement for every MPLS deployment. Verify both directions and the unchanged source IP with real traffic on both firewalls.

Configure the SD-WAN route

Define match criteria

For IPv6, select specific destination IP hosts rather than a blanket Any destination. If a generic Any route must remain, create a route for the specific destination IP hosts and their intended gateway above it; keep incoming interface, source and services narrow as well. Before changing anything, record the installed order using system route_precedence show, along with route position and settings, verify independent management access, and plan how to restore these values. A more specific route is not a reason to reset global route precedence blindly.

  1. Open Routing > SD-WAN routes.
  2. Select IPv4 or IPv6 and click Add.
  3. Enter a unique name such as Clients_M365_WAN2.
  4. Select the Incoming interface on which the traffic to be controlled enters.
  5. Optionally select a DSCP value if incoming packets are marked reliably.
  6. Define Source networks and add Users or groups if required.
  7. Set Destination networks as narrowly as possible.
  8. Limit Services to the required protocols and ports.
  9. Optionally select Application objects.
  10. Under Link selection settings, select an SD-WAN profile or primary/backup gateways.
  11. Deliberately enable or disable Route only through specified gateways.
  12. Save the route and move it to the correct position; the first matching SD-WAN route wins.
  13. Test with a defined client and destination.

Application Objects require an active Web Protection License. The first connection is routed based on destination IP, port, protocol and incoming interface through another matching SD-WAN route or, failing that, through the default route. The Application Object only applies to subsequent connections after application detection. Classification data has a TTL of 3600 seconds from the start of the session. For Micro Apps, only DPI Engine Mode supports all applications, while Web Proxy Mode supports only Pattern Applications and Synchronized Security Applications.

In an HA cluster, SFOS synchronizes this application-routing cache over the dedicated HA link using multicast 226.1.1.1 on port 4455. A firewall restart clears the classification data. After a restart or HA issue, do not check only tunnel or gateway status; generate a first and a subsequent application connection again.

Create an Application Object

The DPI engine can reclassify an application within the same connection, for example when switching from a website to its chat. The new decision applies to subsequent connections, not as a promise to reroute the current connection. If no further session starts within the TTL of 3600 seconds from session start, the stored session details are purged.

Application objects can include web applications, micro apps, endpoint-discovered Synchronized Security Applications, custom applications and application categories. Choose the type according to the detection needed and retain the license and DPI/proxy restrictions above; a whole category is broader than a single required application.

An Application Object groups only the applications that should use the same SD-WAN path. Go to Applications > Application object, select Add, enter a name, and narrow the results by Category, Risk, Characteristics, Technology, Classification, or the name search. Then select the applications actually required and save the object. Sophos updates the available application list dynamically through IPS updates and Synchronized Application Control, so review the selection after pattern or application changes.

The Technology filter distinguishes browser-based, client-server, network protocol, P2P, and synchronized application control. Under Classification, the available values are new, sanctioned, unsanctioned, and tolerated. These criteria make selection easier, but they do not prove that the subsequent route works. That requires the initial classification connection followed by a new test connection.

For Microsoft 365, a single collective object is often too broad. An object such as Teams_VoIP can contain only the Teams applications intended for real-time communication, while OneDrive or SharePoint uses another path. Then select the saved object in the SD-WAN route’s Application objects field.

Select a gateway or SD-WAN profile

Primary/backup gateways are sufficient for one preferred path and one fallback. An SD-WAN profile separates two decisions: Routing strategy selects the path using First available gateway or Load balancing; the optional Service Level Agreement (SLA) adds quality measurements to that strategy. Best quality and Custom SLA are therefore not two additional routing strategies.

Configure an SD-WAN profile under Routing > SD-WAN profiles > Add as follows:

  1. Enter a name and description, then select First available gateway or Load balancing under Routing strategy.
  2. Assign two to eight gateways and drag them into the required order. Gateway weights appear only with load balancing; unequal weights can represent different link capacities.
  3. For load balancing, select Round-robin or an appropriate Session persistence type. Persistence can be based on source IP, destination IP, source and destination, or an individual connection.
  4. Enable SLA only if latency, jitter or packet loss should affect selection. Best quality compares exactly one criterion. Custom SLA checks latency, jitter and packet loss against the configured thresholds.
  5. Enable Health check, select Ping or TCP under Protocol, and enter up to two Probe targets. For TCP, also enter a port on which the target responds reliably. SFOS forces Health Check on when SLA is enabled.
  6. Set Interval between checks, Response time-out, Deactivate gateway after, Activate gateway after, and Sample size for SLA to suit the service. Lower or shorter values react faster but may switch unnecessarily during transient loss; higher or larger values are steadier but detect a genuine outage later.
  7. Save the profile, select it in the SD-WAN route, and verify the path with real traffic.

The two probe targets form one availability test: SFOS considers the gateway active if at least one responds. If the first target fails, it switches to the second and continues using it while it responds. The first target’s return alone does not trigger an immediate switch back. Probe targets should therefore sit behind the gateway and represent the relevant path; a successful ping does not prove that DNS, TLS, or the complete application works.

With Best quality, failback occurs only when the original gateway is better by 10 ms for latency or 5 ms for jitter; there is no corresponding margin for packet loss. Under Routing > SD-WAN profiles, an active profile means that at least one gateway is available. Link status summarizes the configuration, Historical performance opens the measurements, and Object usage shows which routes use the profile. Check these references before editing or deleting it.

If Route only through specified gateways is enabled, the firewall drops traffic when the specified paths are unavailable. Without this option, it checks additional SD-WAN routes and then the default route. If a backup gateway is deleted, Sophos Firewall sets it to None; deleting the primary gateway or SD-WAN profile deletes the route, after which the default route may take over.

With Load balancing and Best quality, traffic is distributed only if at least two gateways share the best performance for the selected criterion; not every reachable gateway qualifies. With Custom SLA, distribution is among gateways that meet the configured SLA thresholds. A reachable path outside the SLA is not the same as an unreachable gateway; this does not establish a universal fallback rule when no gateway meets the SLA.

Gateway weights describe a request ratio: in the documented example, 3:1 means three out of four requests through the first gateway and one through the second. Choose weights according to link capacity and resources; they guarantee neither the same byte share nor a particular throughput or link bonding.

For Custom SLA, Maximum latency and Maximum jitter are in milliseconds, and Maximum packet loss is in percentage points. Interval between checks sets the interval between probes, and Response time-out the permitted response time. Deactivate gateway after counts consecutive unsuccessful probe attempts; Activate gateway after counts consecutive successful responses. Sample size for SLA sets the number of probe samples used to determine average gateway performance. Choose these values for your service, rather than treating an isolated timing example as a universal default.

Align route precedence and NAT

The documented default is Static → SD-WAN → VPN. This is not necessarily the state of an existing installation: still check system route_precedence show before making decisions and do not apply the default automatically.

Route precedence determines the order of Static, SD-WAN and VPN. Directly connected networks and SSL VPN belong to the Static category. You can view the current order under Routing > SD-WAN routes or in the Device Console; changes and rollback are explained in Safely change Sophos Firewall route precedence.

Routing selects the path; NAT changes addresses. Internet traffic through WAN2 may therefore require MASQ or a fixed SNAT IP on that path. NAT is often undesirable for internal networks and VPNs, however. See Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT for the relationships involved.

DNAT to a server behind route-based IPsec

A public DNAT publication can point to an internal server that isn’t connected locally but is located behind a remote firewall over route-based IPsec. In this special case, the DNAT and SD-WAN route must identify the same incoming flow before translation, and the return path must lead back through the publishing firewall.

The reliable SFOS 22 workflow consists of five related parts:

  1. Create an exact IP object for the remote server under Hosts and services > IP host.
  2. Under Routing > Gateways, create a gateway with the remote gateway IP and the corresponding XFRM interface. Use a reliably reachable host behind this gateway as the monitoring target.
  3. Make the DNAT rule match the public WAN interface and the externally offered service, and select the remote server as Translated destination. The Sophos example uses MASQ so that replies return to the publishing firewall; however, this means the server no longer sees the original client IP.
  4. In the SD-WAN route, enter the same public WAN interface under Destination networks and the externally addressed port under Services. With PAT, this is explicitly the external port, not the translated internal destination port. Select the XFRM interface gateway as the primary gateway.
  5. Check a narrow firewall rule for the publication and test the flow from an external network. The expected NAT Rule ID, Firewall Rule ID, SD-WAN route, selected XFRM gateway, forward and return paths, and source IP visible on the server must match the design.

MASQ isn’t a cosmetic option here. In the documented example it resolves the return path, but it removes the real client IP from the target server. If the remote site has a verified return path to the original client networks and the original IP must be preserved, use a deliberately planned and separately tested routing design. The general publication and security workflow is described in Publish a server via DNAT on Sophos Firewall.

Multiple remote servers can use the same SD-WAN route if they are reachable through the same gateway and can be matched unambiguously by WAN address or external TCP port. If they use different gateways, configure separate SD-WAN routes. When the wrong port, WAN object, or gateway matches, don’t broaden the route to Any; first prove the pre-DNAT flow with Log Viewer and Packet Capture.

Test and accept the route

Check the route list and gateway status

Under Routing > SD-WAN routes, you can search by route name, object, or object value; for example, 443 finds routes using the HTTPS service. Drag and drop changes the order. This changes traffic handling because SFOS evaluates from top to bottom and stops at the first match.

Under More options, you can turn a route on or off, edit or clone it, reset its data counter, or delete it. Before a reset, record the counter and time. A cloned route is a separate route: check its name, match criteria, position, gateway, and NAT before saving or turning it on, then verify its actual On/Off status.

When an SD-WAN profile is used, the tooltip on the icon in the Active column shows states such as In use, Available, Unavailable, In use, but SLA isn't met, or Available and SLA isn't met. An available gateway or profile status proves neither that this route matched nor that the return path works.

With direct primary/backup selection, the Active icon distinguishes three states: at least one gateway is reachable and the route is live; the route is not live and Route only through specified gateways is off; or it is not live and the option is on. In the last case, traffic remains dropped when the specified paths are unreachable instead of using other gateways. Read the tooltip together with the checkbox, rather than equating it with a profile SLA status.

Standard test with real traffic

  1. Select a test client with a known IP and an unambiguous destination.
  2. Enable logging in the matching firewall rule.
  3. Start a real connection.
  4. In Log viewer, check source, destination, service, rule ID, NAT ID and gateway.
  5. Check the SD-WAN route’s traffic count: OUT counts requests and IN counts replies only if source and destination match the criteria for that direction.
  6. Under System services > Log settings, enable the SD-WAN type and check the SD-WAN module in Log Viewer for profile, SLA and route events.
  7. If anything remains unclear, set a narrow filter for client, destination and port under Diagnostics > Packet capture.

The Policy tester does not consider SD-WAN routes. It can check policy matches, but it cannot confirm the selected SD-WAN route or the actual gateway. For a complete packet flow analysis, see Test Sophos Firewall rules with Log Viewer, Policy Test and Packet Capture.

For profile and route logs within the firewall view, select the Firewall module in Log viewer, open the expanded selection using the expand button next to the module list, select the required SD-WAN logs, and click Apply. This complements the separate SD-WAN module view.

Evaluate SD-WAN performance

The quality graphs show time on the x-axis; the y-axis shows latency and jitter in milliseconds and packet loss in percentage points. Assigned weights for load balancing opens the assigned gateway weights. Measurements and weights do not constitute application acceptance.

Under Diagnostics > SD-WAN performance, select the SD-WAN profile in use. Alternatively, open Routing > SD-WAN profiles, select the profile, and under Status, click Historical performance. For each gateway, the view shows total connections, data transferred, assigned load-balancing weights, as well as latency, jitter, and packet loss for Live, 24h, 48h, Week, or Month.

According to Sophos, No data to display means that no route is using the selected profile yet or that no traffic is passing through such a route. The message therefore does not prove a monitoring fault. First generate a controlled flow over the expected route and confirm it with Log Viewer or Packet Capture.

Reset data transfer and connection count changes the counters. Record the values and time before resetting them. Even an unremarkable graph does not yet prove that the firewall rule, NAT, application, and return path work; these layers remain part of the real test.

Test failover and failback safely

Before making a change, record the route’s current position and On/Off status, its primary/backup gateways or profile, the profile’s gateway order, SLA and health-check settings, and the expected NAT translation. Roll back by restoring those exact values, then recheck status, logs, and real traffic.

Perform a controlled outage test during a maintenance window, with a documented rollback and an independent management path to the firewall. First, check the current read-only status values in the Device Console:

system route_precedence show
show routing reroute-connection
show routing reroute-snat-connection

Then start real application traffic, deliberately make the primary gateway unavailable, and check the path, sessions, public source IP and return path. Do not delete the primary gateway or SD-WAN profile for this test, because doing so removes the route and tests only fallback to the default route. Editing the route or profile, or changing route precedence, can also reroute existing connections and doesn’t belong in the same baseline test. With a direct primary/backup selection, new connections use the primary again after it returns; existing connections generally remain on the backup gateway.

reroute-connection is enabled by default and applies to connections without SNAT. SNAT connections are not rerouted by default; even with reroute-snat-connection enabled separately, this works only if both paths use the same translated source IP. With MASQ or different Override Source Translation addresses, the SNAT connection is not rerouted and the existing session breaks when the path fails.

Deliberately change rerouting

These switches change traffic handling; they are not prerequisites for the baseline test. Change them only in a maintenance window with verified independent management access and a documented rollback: first save both rerouting status values shown above and verify that both paths use the same translated source IP for SNAT. The following alternatives are available in the Device Console; execute only the command needed for the intended change, not all commands in sequence:

  • Enable without SNAT: set routing reroute-connection enable; disable: set routing reroute-connection disable.
  • Enable for SNAT: set routing reroute-snat-connection enable; disable: set routing reroute-snat-connection disable.

Then recheck with show routing reroute-connection and show routing reroute-snat-connection, and separately test sessions, source IP and both traffic directions. To roll back, restore each changed switch to its recorded enable/disable state and repeat the status and real-traffic tests. These documented commands and this rollback have not been tested here on a firewall; enabling SNAT rerouting does not remove the MASQ/IP restrictions.

Troubleshoot systematically

The route does not match

  • Compare the incoming interface, source network, destination and service with the actual flow.
  • Check the route order; the first matching SD-WAN route wins.
  • For application objects, check the license, DPI detection and a second connection after classification.
  • Do not use the traffic count as the sole proof, because requests and replies are counted only when source and destination criteria match.
  • With a direct web proxy, matching HTTP/HTTPS as the service is not enough: Use Any or a service for the port configured under Web > General settings > Web proxy listening port. For reply packets, source network and incoming interface do not match in this special case; the proxy’s return path also requires a WAN default gateway or a suitable static route.
  • For an SD-WAN route migrated from SFOS 17.5 or earlier, check whether its original firewall rule was deleted. These migrated routes remain linked to the old rule and are also removed when that rule is deleted.
  • For IPv6, Dead Gateway Detection in SD-WAN routes doesn’t monitor third-party network traffic such as SNMP. A missing third-party measurement is therefore not reliable proof of DGD status.

Set up Direct Web Proxy with a PAC file describes the listener, client deployment, protection rule, and real traffic test.

Separate switches and matching rules apply to reply packets and system-generated traffic. These special cases are explained in Check Sophos Firewall SD-WAN routing for reply packets and system traffic.

Web Admin and SSH become unreachable after a new route

One documented scenario combines four settings: SD-WAN precedes Static, a new route for a specific internal source network has destination Any, SD-WAN routing for system-generated traffic is enabled, and SD-WAN routing for reply packets is also enabled. Management access from the affected internal network can then be lost while remaining possible from other subnets. These are not necessary conditions for every management outage.

Using previously verified alternative access, check the route source, destination and precedence, plus these read-only values in the Device Console:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

First verify that management from an unaffected subnet is actually permitted and reachable. Then narrow the destination deliberately or restore one of the previously changed settings to its documented original value. Do not perform a blind global reset: save route position, settings and precedence beforehand, plan rollback, and recheck Web Admin, SSH and affected traffic afterwards. Without safe alternative access, do not continue the change remotely.

Traffic takes the wrong path

  • For public IPv4 destinations, replace Any with Internet IPv4 group or specific destinations.
  • Check route precedence, especially if internal, SSL VPN or policy-based IPsec networks are affected.
  • Check gateway and SLA status as well as health-check targets.
  • Compare the NAT rule and translated source IP with the gateway actually used.
  • Check whether a primary gateway or SD-WAN profile was deleted, removing the route with it.

The application or reply fails after failover

First, use Packet Capture to check whether the packet leaves through the expected gateway and whether the reply returns. Then check NAT, public-IP allowlists, session persistence, MTU/MSS and the status of the VPN or MPLS path. SIP/RTP, banking portals and APIs with a fixed source IP must be tested with real application traffic in particular.

If the problem began immediately after an upgrade to SFOS 22.0 GA, first verify the installed build. SFOS 22.0 MR1 Build 490 fixes NC-173667, in which an SD-WAN route disconnected randomly, and NC-177603, in which VoIP audio over a route-based VPN worked in only one direction after the upgrade to 22.0 GA. If MR1 or a later build is already installed, do not attribute the fault to the firmware version alone; repeat the real-traffic test above and verify the route, sessions, NAT and both traffic directions.

Operations and documentation

For every production SD-WAN route, document its purpose, incoming interface, source/destination, services, gateway or profile, fallback, NAT expectation, test client, test destination, owner and review date. After changes to a provider, VPN, interface or cloud service, verify matching, logs and failover again.

A route is accepted only when:

  • the match criteria capture only the planned traffic
  • the firewall rule, NAT and route precedence match the design
  • Log Viewer and Packet Capture confirm the expected path
  • failover, failback and public source IP behave as documented
  • an owner and next review date are recorded