Check Sophos Firewall SD-WAN Reply and System Traffic

SD-WAN routes on Sophos Firewall are not only relevant to conventional client-to-internet traffic. Depending on the environment, reply packets and system-generated traffic may also be affected. This is where routing problems that are difficult to identify often arise: the rule looks correct and the gateway is active, but replies use the wrong path or the firewall itself cannot reach a service over the expected connection.

This guide explains the two CLI options reply-packet and system-generate-traffic, when to check them and how to test changes safely. For the standard setup, start with Set up and test an SD-WAN route on Sophos Firewall. For the general order of static routes, SD-WAN policy routes and VPN routes, also see Safely change route precedence on Sophos Firewall.

⚠️ These settings can affect production routing immediately. Before making a change, document the current state, choose a maintenance window and establish a clear rollback path. Broad SD-WAN routes using Any, route precedence placing SD-WAN before static routes, and enabled SD-WAN routing for system traffic or reply packets are particularly critical.

Fundamentals and limitations

What the two options control

For SD-WAN routes, you must distinguish between normal forwarded traffic, reply packets and traffic generated by the firewall itself. The two options do not determine whether an individual SD-WAN route is configured correctly. Instead, they extend the types of traffic that SD-WAN policy routing can consider.

The options perform different functions:

• reply-packet: Affects reply packets for existing traffic. It allows SD-WAN to influence the return path in certain non-WAN scenarios.
• system-generate-traffic: Affects traffic generated by the firewall itself. It allows firewall-originated connections to use defined SD-WAN routes.

Do not enable either option blindly merely because “SD-WAN is not working”. First establish whether reply packets or system-generated traffic are actually affected. For normal connections, the real cause is often the firewall rule, NAT, route precedence, gateway status or an overly broad SD-WAN route.

Reply packets

Reply packets are responses to existing traffic. Sophos Firewall generally enforces symmetric routing for these responses on WAN interfaces: reply packets should leave through the same WAN interface on which the original connection arrived.

The reply-packet option is primarily relevant when SD-WAN policy routing should consider reply packets in specific scenarios. One typical example is asymmetric routing on non-WAN interfaces, such as between LAN and DMZ.

There is an important limitation: if the original traffic uses the default route or WAN link load balancing, SD-WAN routes do not apply to these reply packets. The firewall continues to use the appropriate return path through the interface of the original connection.

Typical checks:

• Is this genuinely reply traffic rather than a new connection?
• Does the traffic use WAN, LAN, DMZ, XFRM or another zone?
• Is there an SD-WAN route intended to influence the return path?
• Is the route too broad, for example with destination Any?
• Does route precedence cause it to be evaluated before a static or VPN route?

System-generated traffic

System-generated traffic is traffic created by Sophos Firewall itself. Depending on the environment, this can include DNS requests, signature downloads, authentication requests, DHCP, NTP, Syslog or connections to Sophos Central. By default, this traffic uses the active WAN gateways under Network > WAN link manager.

For this traffic, Incoming interface and Source networks are unknown and are therefore unsuitable selectors. An SD-WAN route intended to match firewall traffic should instead be restricted specifically using Destination networks and Services, while the other criteria remain broad. Otherwise, a route with destination Any can unexpectedly direct system and management traffic over the wrong path.

A normal firewall rule is not required for this traffic. Under Current activities > Live connections, system-generated traffic therefore has Firewall Rule ID 0. If a specific source IP address is required, a normal SNAT rule is also insufficient: NAT rules translate forwarded traffic, while firewall traffic may require sys-traffic-nat in the Device Console, depending on the scenario.

Two additional practical limitations apply:

• If all configured gateways under Network > WAN link manager are marked only as Backup, the firewall does not forward system-generated traffic through them. At least one gateway must be Active.
• System-generated RED traffic on UDP 3410 is Layer 2 traffic. SD-WAN routes do not apply to it.

Preparation

When to check these settings

The two options are most relevant in more complex routing designs. In simple single-WAN environments, they are rarely the first setting to change.

Useful indicators include:

• Firewall-originated traffic does not use the expected WAN or VPN path.
• Syslog, Central, DNS, NTP or monitoring traffic should use a specific connection.
• A route-based IPsec VPN with XFRM interfaces is used together with SD-WAN routes.
• VoIP or other sensitive traffic works in only one direction over SD-WAN or VPN.
• Packet Capture shows replies on a different interface than expected.
• SD-WAN, IPsec or NAT behaves differently after an upgrade.
• A broad SD-WAN route suddenly affects internal networks or management access.

For IPsec scenarios, also consult Troubleshoot IPsec VPN on Sophos Firewall. For individual connections, Test a Sophos Firewall rule with Log Viewer and Packet Capture is often the better starting point.

Display the current status

Run these commands in the Device Console, not in the Advanced Shell. If console access is not yet established, see Connect to Sophos Firewall using SSH.

Check the status for reply packets:

show routing sd-wan-policy-route reply-packet

Check the status for system-generated traffic:

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

In addition, the routing information tooltip in WebAdmin under Routing > SD-WAN routes shows whether SD-WAN routing is enabled for system-generated traffic and reply packets.

Also document the current route precedence:

system route_precedence show

Document the current output before every change. A clean rollback is only possible if the previous state is known.

Change the configuration

Enable or disable the options

Enable SD-WAN routing for reply packets:

set routing sd-wan-policy-route reply-packet enable

Enable SD-WAN routing for system-generated traffic:

set routing sd-wan-policy-route system-generate-traffic enable

Then run the status commands again and document the output.

Use the corresponding commands to disable the options deliberately:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ Do not make several routing changes at once. If route precedence, the SD-WAN route, a NAT rule and these CLI options are all changed simultaneously, it becomes difficult to attribute a subsequent fault correctly.

Safe change procedure

A pragmatic procedure reduces the risk:

1. Define the affected traffic precisely: source, destination, service, zone and expected gateway.
2. Document the existing SD-WAN routes, gateways and route precedence.
3. Check whether destination Any is genuinely necessary.
4. Document the current status of reply-packet and system-generate-traffic.
5. Change only one option.
6. Test using a clearly defined traffic example.
7. Check Log Viewer, Packet Capture and gateway counters.
8. Document the result before making any further changes.

If management access may be affected, ensure a second access method is available: a local console, another internal access path or access from an unaffected management network.

Validation after the change

An active gateway status alone is not sufficient after enabling an option. You must verify that the required traffic actually uses the expected path.

Live Connections, Log Viewer and SD-WAN counters

For forwarded traffic, check firewall and SD-WAN-related events in Log viewer. Log firewall traffic must be enabled for the relevant Firewall Rules. System-generated traffic, however, is not controlled by a firewall rule. Under Current activities > Live connections, identify it by Firewall Rule ID 0 and its inbound and outbound interfaces.

Check the following:

• Is this forwarded traffic with a Firewall Rule ID, or system traffic with ID 0?
• Which NAT Rule ID is used for forwarded traffic?
• Which gateway or interface appears in the log?
• Are there drops, policy violations or unexpected security-feature decisions?
• Does the SD-WAN route show only OUT for requests, or also IN for replies? The counters appear only when the source and destination criteria match the respective direction.

Packet Capture

Use Diagnostics > Packet capture to inspect the actual packet flow. Keep the filter narrow for routing questions: source IP, destination IP, port and protocol.

Compare the following:

• Does the packet arrive on the expected interface?
• Does it leave the firewall through the expected interface?
• Does the reply return?
• Is NAT applied?
• Is the return path plausible for reply packets?

For operation and interpretation, see Use Packet Capture in Sophos Firewall WebAdmin.

Check system services

For system-generated traffic, test the affected service specifically:

• DNS: Run a DNS lookup on the firewall and check the destination path.
• NTP: Check the time status and reachability of the NTP server.
• Syslog: Check for a test message or current log entry on the collector.
• Sophos Central: Check the Central connection and reporting.
• Monitoring: Check SNMP, sFlow or external checks on the collector.

If system-generated traffic is not visible, check whether the route unnecessarily requires Source networks, Incoming interface, a user or an application. For firewall-originated traffic, Destination networks and Services should be the primary criteria. If the peer expects a specific source address, also check the source IP and any required sys-traffic-nat configuration.

Errors and dependencies

Common errors

• SD-WAN route with destination Any for internal paths: Internal traffic or management access may be routed over WAN. Use internet destination groups or specific destination networks instead.
• Route precedence places SD-WAN before Static: Directly connected or static networks may unexpectedly match an SD-WAN route. Check route precedence and, if necessary, place Static before SD-WAN.
• system-generate-traffic enabled without destination restrictions: Firewall-originated services may use the wrong path. Restrict destination networks and services carefully.
• Reply packets confused with normal new connections: This leads to investigating the wrong cause. Check Packet Capture and the flow direction.
• Looking for a firewall rule for system-generated traffic: This traffic has Firewall Rule ID 0; normal firewall rules do not control it. Check the route, service, Live Connection and, where necessary, sys-traffic-nat.
• Direct Web Proxy treated like normal HTTP/HTTPS traffic: For the direct proxy, the SD-WAN route must include the port configured under Web > General settings > Web proxy listening port. Alternatively, Services can be set to Any. Source Network and Incoming Interface do not match reply packets for proxy traffic; the return path requires at least one WAN gateway or a suitable static route.
• Several routing changes at once: The source of the fault remains unclear. Make changes step by step and document every test.
• No alternative management access: WebAdmin or SSH access may be lost from the affected network. Prepare a maintenance window and an alternative access path.

A particularly critical risk arises when several conditions coincide: route precedence places SD-WAN before Static, a broad SD-WAN route uses Any, and SD-WAN routing for system-generated traffic or reply packets is enabled. In this case, WebAdmin or SSH access from certain internal subnets may be lost.

Interaction with NAT, IPsec and VoIP

SD-WAN is rarely the only component involved. Many faults also involve NAT, IPsec or application-specific traffic.

For SNAT, determine whether the same source IP address is retained across different gateways. If MASQ or different translated source addresses are used, failover or rerouting can cause communication problems. For the fundamentals, see Understand NAT on Sophos Firewall.

For route-based IPsec VPNs, XFRM interfaces can be used in SD-WAN routes or SD-WAN Profiles. In that case, check the IPsec status, SD-WAN route, route precedence and firewall rules together. IPsec routes on Sophos Firewall explains the route-based VPN fundamentals.

For VoIP problems, also check SIP, RTP, NAT and SD-WAN. The SFOS 22.0 MR1 release notes document a resolved issue in which VoIP audio worked in only one direction over a route-based VPN using SD-WAN routing after an upgrade to SFOS 22.0 GA. The practical procedure is described in Resolve Sophos Firewall VoIP problems with SIP and RTP.

Rollback and completion

Rollback

Document the previous state before making a change. If management access, system services or production traffic are affected afterwards, do not continue improvising. Restore the previous state first.

In practice:

1. Restore the documented previous values for reply-packet and system-generate-traffic using the corresponding enable or disable commands.
2. Restore the previous route-precedence order if it was changed.
3. Temporarily disable overly broad SD-WAN routes or restrict them to specific destinations.
4. Test management access from an unaffected network.
5. Only then continue narrowing down the actual cause.

If WebAdmin and SSH access is lost from one internal subnet but remains available from another, use the working subnet to check the broad SD-WAN route, route precedence and both CLI options first.

Checklist

• Current status of both CLI options documented.
• Route precedence documented using system route_precedence show.
• Affected traffic defined precisely.
• Only destination and service used as the decisive match criteria for system traffic.
• SD-WAN route not made unnecessarily broad using Any.
• Route precedence checked.
• At least one WAN gateway for system traffic marked as Active.
• Alternative management connection prepared.
• Only one change made per test.
• Log Viewer and Packet Capture used for validation.
• NAT, IPsec and firewall rules checked as well.
• Result and rollback documented in the operations journal.

FAQ