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 Central should generate the route-based tunnels and site paths for multiple managed firewalls, use Set up and verify a Sophos Central 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.

Configure the SD-WAN route

Define match criteria

  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.

Select a gateway or SD-WAN profile

Primary/backup gateways are sufficient for one preferred path and one fallback. To use an SD-WAN profile, create at least two gateways, then create the profile under Routing > SD-WAN profiles and select it in the route. A profile is useful when multiple paths, load balancing or SLA criteria are required:

  • First available gateway uses the first available gateway in the defined order.
  • Load balancing distributes connections; session persistence and gateway weights control affinity and distribution.
  • Best quality compares exactly one criterion: latency, jitter or packet loss.
  • Custom SLA requires thresholds for all three criteria and uses the selected routing strategy if the thresholds are not met.

Health checks use ping or TCP to test up to two probe targets. These targets should represent the relevant path, but they do not prove that a complete application works. With Best Quality, failback also occurs only when the original gateway is better by 10 ms for latency or by 5 ms for jitter; there is no such margin for packet loss.

A profile can contain between two and eight gateways. With Load balancing, you can use round-robin or session persistence based on source IP, destination IP, source and destination, or an individual connection; optional gateway weights represent different link capacities. If two probe targets are configured, SFOS tests the first target first. If it doesn’t respond, the firewall switches to the second target and stays with it while it responds. The return of the first target alone doesn’t cause an immediate switch back.

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.

Align route precedence and NAT

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.

Test and accept the route

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.

Evaluate SD-WAN performance

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

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.

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.

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 after a firmware update, check the current SFOS 22.0 release notes before making extensive rule changes. SFOS 22.0 MR1 fixes, among other issues, intermittent SD-WAN interruptions and one-way audio over a route-based VPN with SD-WAN routing.

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