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. Examples include DNS requests, signature downloads and authentication requests. For services such as DHCP, SNMP or Syslog, the classification depends on the role and traffic direction; not all traffic to a firewall service is an outbound, system-generated connection. By default, the firewall sends its own traffic through the 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. The Local service ACL under Administration > Device access is separate: it controls access to local firewall services, not selection of the outbound SD-WAN path. 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.

Reach an authentication server through route-based IPsec

An important special case is an AD or LDAP server at the head office that a branch firewall itself must reach through a route-based IPsec tunnel. A normal LAN-to-VPN rule does not steer this request because the firewall generates the traffic. With an any-to-any tunnel and addressed XFRM interfaces, the forward and return paths must therefore be planned deliberately.

The following example uses 10.10.1.1 as the visible source address of the branch firewall, 10.10.2.15 as the AD server, and TCP 636 for LDAPS. These values are not product defaults. Replace them with a branch address that the tunnel permits and the head office routes back, the actual server, and the authentication service that is really configured.

1. On the branch firewall, create a narrow SD-WAN route with Source networks set to Any, the AD host as Destination networks, and the required authentication service. TCP 636 is appropriate only when the server actually uses LDAPS. Use the remote XFRM address through the local XFRM interface as the Primary Gateway.
2. Turn on Route only through specified gateways only when the request must deliberately be dropped if the tunnel is unavailable. Check the system-generated traffic switch as described above and enable it in a controlled manner for this workflow.
3. In the Device Console, first use show advanced-firewall to record existing sys-traffic-nat entries and their order. Then apply source NAT to map the firewall’s own address to the planned branch address. This address must match the tunnel and return-path rules:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1

4. On the head office firewall, create a return-path SD-WAN route from the AD host to the translated branch address through the remote XFRM address. Keep the source, destination, and service as narrow as on the branch side.
5. At the head office, create logged rules from VPN to the server network and from the server network back to VPN, using the specific hosts and services. The broad Any examples in product instructions are not suitable as a permanent state.
6. Ping/Ping6 under Administration > Device access for the VPN zone is required only if the probe target is a local firewall or XFRM address. To probe a host behind the tunnel, you instead need the appropriate tunnel and route and, where necessary, a firewall rule. Restore any temporary Device Access permission to its previous state after the test.

For acceptance, trigger a real server connection test and a user sign-in. On the branch firewall, system-generated traffic appears in Current activities > Live connections with Firewall Rule ID 0; at the head office, the expected logged rules must match. Packet Capture must show the request and response on the planned XFRM interfaces. A successful ping alone confirms neither LDAPS nor authentication and the return path.

For rollback, first check the two SD-WAN routes, rules, gateway objects and any temporary Ping/Ping6 permission for other dependencies. Remove the NAT entry using exactly the same selectors; if netmask, interface, or both were also used when creating it, include the same selector or selectors in the delete command:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Then use show advanced-firewall to verify that only the intended entry has disappeared. Remove only routes, rules and objects created for this workflow, restore both global SD-WAN switches and Route Precedence to their documented previous values, and retest the original data path.

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.

Under Routing > SD-WAN routes, also establish how each affected route responds to gateway failure. With Route only through specified gateways, the firewall drops the traffic if the specified gateways are unavailable. Without this option, it checks subsequent SD-WAN routes and then WAN Link Load Balancing. If the selected Primary Gateway or SD-WAN Profile is deleted, SFOS also deletes the route; if only the Backup Gateway is deleted, the route remains with None as its backup.

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 the SD-WAN route’s OUT/IN 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

Before testing, check under System services > Log settings whether SD-WAN logging is enabled. Entries appear in the SD-WAN module of Log viewer; for forwarded traffic, Log firewall traffic must also be enabled on the relevant Firewall Rule. Record the previous logging state and restore it after the test if logging was enabled only temporarily.

System-generated traffic 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. The Local service ACL remains a separate control for access to local firewall services.

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 firewall-originated requests, does Status show Generated, and for responses delivered to the firewall, Consumed where applicable?
• Do Gateway ID, NAT ID, and the inbound and outbound interfaces match the intended path?

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

Check the affected system service

A route match alone does not prove that the service works. Before the test, record the destination IP, port, expected source IP and expected outbound interface. Then trigger the specific function being tested, such as an authentication request or a DNS lookup from the firewall, and verify both the Packet Capture and the corresponding traffic or event on the remote system. Use a destination or service that does not match the route as a negative test; it must not match the narrowly scoped route.

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. Read the current state in the Device Console with show routing reroute-connection and show routing reroute-snat-connection. SFOS can reroute connections after a gateway failure, but SNAT connections must retain the same translated source IP on both paths. MASQ or different translated addresses can interrupt an active connection during rerouting. This article only reads these two values; it does not change them. 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. Restore changed SD-WAN routes to their documented previous values; after checking dependencies, remove routes created only for the test.
4. Delete temporary sys-traffic-nat entries with exactly the same selectors and verify the result with show advanced-firewall.
5. Restore firewall rules, gateway objects, Device Access permissions and logging settings changed only for the test.
6. Test management access and the original data path from an unaffected network.
7. 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