Configure and test Sophos Firewall SD-WAN routes
SD-WAN Routes on Sophos Firewall control which route certain traffic should take. This is helpful for multiple WAN lines, MPLS, route-based IPsec VPNs, VoIP, cloud services or applications that need to run through a specific provider.
In practice, SD-WAN problems rarely arise from the button itself. Criteria are usually too broad, gateways are incorrectly evaluated, NAT rules are not appropriate, route precedence is unexpected or tests are too imprecise. The article therefore not only covers the click path, but also planning, acceptance and typical troubleshooting.
Video Guide
Short answer
You create an SD-WAN route under Routing > SD-WAN routes. It should be clear beforehand:
- which traffic should be controlled
- which source, destination, services and users are affected
- which gateway or which SD-WAN profile is used
- whether static routes, VPN routes or route precedence are competing
- whether NAT matches the route
- how to check the path in the log viewer and packet capture
A good SD-WAN route is narrow enough to control only the desired 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 does not express which traffic should go over which path.
Typical cases:
| Situation | Benefit of an SD-WAN route |
|---|---|
| two or more internet lines | Send specific applications over preferred line or failover |
| VoIP or Teams | Prioritize low-latency or low-jitter lines |
| Cloud services | Steer Microsoft 365, ERP or backup traffic deliberately |
| route-based IPsec VPN | Control traffic via XFRM interface or gateway profile |
| MPLS or site line | Reach internal target networks via dedicated path |
| Provider with source IP binding | Send traffic over exactly the WAN connection that matches the permitted public IP |
If only a static destination network needs to be reached via a clear next hop, a static route can be simpler and more robust. SD-WAN is worthwhile when criteria, gateway selection, failover or performance evaluation are needed.
Plan in advance
Before creating the route, the desired data flow should be described clearly. A sentence like “Teams should work over WAN2” is too imprecise. A small matrix is better:
| Field | Example |
|---|---|
| Source zone | LAN |
| Source network | Client_Net_10.20.0.0_24 |
| Destination | Microsoft 365 target group, FQDN group or specific network |
| Services | HTTPS, UDP 3478-3481 or defined services |
| User/Group | optional, only if user matching works stably |
| Primary Gateway | WAN2 |
| Fallback | WAN1 |
| NAT | MASQ or fixed SNAT IP matching the gateway |
| Test | Client IP, destination, expected gateway, expected log entry |
Especially with VoIP, VPN, cloud services and multiple locations, one should not start with Any only 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.
- Appropriate firewall rules for traffic.
- Appropriate NAT rules if traffic needs to 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.
Create SD-WAN route
Menu path:
Routing > SD-WAN routes
```Proceed:
1. Open **Add**.
2. Assign a unique name, for example `Clients_M365_WAN2`.
3. Choose **Incoming interface** or source context to match the design.
4. Source networks or users only set as wide as necessary.
5. Choose destination networks, FQDN hosts or Internet services consciously.
6. Limit services to the required protocols.
7. Select gateway or SD-WAN profiles.
8. Check failover or backup path.
9. Save the rule and position it appropriately in the order.
10. Carry out a test with a defined client.
The exact interface may vary slightly depending on the SFOS version. What remains crucial, however, is that the route must match the desired flow and must not accidentally capture more traffic than planned.
## Select gateway and SD-WAN profiles
SD-WAN Routes can point directly to gateways or work with SD-WAN Profiles. Which approach is right depends on the goal.
| approach | Makes sense if |
| --- | --- |
| fixed gateway | Traffic should consciously flow over a line |
| Gateway with backup | one line is preferred, but failover should be possible |
| SD-WAN Profiles | multiple gateways can be evaluated according to weight, SLA or priority |
| XFRM interface or VPN path | route-based IPsec is included in the routing |
If you have multiple WAN lines, you should 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 properly via this provider.
## Check order and route precedence
SD-WAN routes do not stand alone. Depending on their 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 wider SD-WAN route fit further up?
- Should SD-WAN be evaluated before or after Static?
- Is a policy-based or route-based IPsec VPN involved?
- Does the route only affect forwarded client traffic or also reply packets and system-generated traffic?
The global order is explained in [Safely change Sophos Firewall route precedence](/en/kb/sophos-firewall-change-routing-priority/). For the special cases **Reply Packets** and **System Traffic**, see [Check Sophos Firewall SD-WAN routing for reply packets and system traffic](/en/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/).
## Don't forget NAT
Routing decides where a packet goes. NAT decides whether the source or destination address is changed. Both have to fit together.
Typical examples:
- Internet traffic over WAN2 may need MASQ or a fixed SNAT IP on WAN2.
- Providers or cloud services only allow a certain public IP.
- For internal networks or VPNs, NAT is often incorrect because the real source IP should be preserved.
- After failover, the public source IP can change and remote sites can drop sessions.
If an SD-WAN route works correctly but the application still fails, NAT should be checked early on. The basics are covered in [Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT](/en/kb/sophos-firewall-nat-basics/).
## Testing and Validation
A green gateway status does not prove that the SD-WAN route is hitting the expected traffic. The test must check a real flow.
Meaningful process:
1. Use test client with known IP.
2. Specify the goal and service exactly.
3. Enable firewall rule logging.
4. Start connection.
5. In the **Log viewer** check Source, Destination, Service, Rule ID, NAT ID and Gateway.
6. Check the usage counter of the SD-WAN route.
7. If it is unclear, use **Diagnostics > Packet capture** with a narrow filter.
8. Test a failure of the primary gateway when validating failover.
9. After the failback, check whether sessions and new connections are running as expected.
For packet flow analysis, see [Testing Sophos Firewall rules with Log Viewer, Policy Test and Packet Capture](/en/kb/sophos-firewall-rule-testing/). Important: The Policy Tester does not replace a real packet flow test for SD-WAN.
## Common mistakes
| Error | Effect | Better approach |
| --- | --- | --- |
| Destination `Any` for convenience | too much traffic is captured by SD-WAN | Choose target networks, FQDN hosts or internet services more narrowly |
| SD-WAN route is too high | more specific application or route is overridden | Check order and hit counter |
| NAT does not match the gateway | Application sees incorrect source IP or return path breaks | Check NAT rule and MASQ/SNAT |
| Gateway monitoring is too coarse | Gateway is active even though the target application cannot be reached | Choose SLA/monitoring goals that match the service |
| Route precedence ignored | Static route or VPN route works differently than expected | Document and test route precedence |
| Reply traffic misclassified | Answers do not go via expected path | Check packet capture and reply packet option |
| multiple changes at the same time | The cause remains unclear a change, a test, then move on |
## Troubleshooting
If the SD-WAN route does not work as expected, you should not immediately “solve” the error with broader rules. A clear demarcation is better.
Check:
1. Does the packet even reach the firewall?
2. Does it meet the expected firewall rule?
3. Does the SD-WAN route match according to the meter?
4. Is another SD-WAN route higher up more specific or broader?
5. Does the service really fit, for example TCP/UDP and port?
6. Is NAT used and is that desired?
7. Does the packet leave the firewall via the expected gateway?
8. Will the answer come back?
9. Is there a static route, VPN route or route precedence that influences the path?
If Packet Capture doesn't see a packet at all, the problem is in the firewall: client gateway, VLAN, switch, local routing or incorrect test. If the packet arrives but goes over the wrong path, SD-WAN criteria, order, NAT and route precedence are the next checkpoints.
## Operational check
SD-WAN routes should be documented and regularly checked after introduction. This is particularly important when changing providers, new VPNs, additional WAN lines or changes to cloud services.
You should document:
- Purpose of the route
- Source and destination criteria
- Services
- Gateway or SD-WAN profiles
- NAT expectation
- Failover behavior
- Test client and test target
- Owner and review date
For business-critical applications, it should also be clear who has to react in the event of provider disruptions, failover problems or changed public IPs.
## Checklist
- Traffic destination and search intention of the route are clearly described.
- Source, destination and services are not set unnecessarily broadly.
- Gateway or SD-WAN profiles deliberately chosen.
- Firewall rule and NAT rule match the route.
- Route precedence checked.
- Reply packets and system-generated traffic only included when necessary.
- Log Viewer and Packet Capture used for acceptance.
- Failover and failback tested when part of the design.
- Route documented and provided with owner.
## Frequently asked questions
When do you need an SD-WAN route on Sophos Firewall?
An SD-WAN route makes sense when certain traffic should flow over a specific path depending on the source, destination, service, user or gateway. For a simple target network, a static route can often be sufficient.
Why is my SD-WAN route not working?
Often the source, destination, service, order or route precedence do not match. Additionally, a firewall rule, NAT rule or static route can affect the actual packet flow.
Can you use SD-WAN with route-based IPsec?
Yes, route-based IPsec can be integrated into SD-WAN designs with XFRM interfaces and appropriate routes. Then IPsec status, SD-WAN route, route precedence, NAT and firewall rules should be checked together.
Should you always set Destination to Any?
No. Any only makes sense if the route is actually intended to control all destination traffic from this source. For cloud services, VoIP, internal networks or VPNs, narrower targets are usually safer and easier to maintain.
Is the Policy Tester sufficient for SD-WAN testing?
No. The Policy Tester helps with policy logic, but does not replace a real packet flow test. For SD-WAN you should use Log Viewer, hit counter and Packet Capture.