Sophos Firewall SD-WAN Check routing for Reply Packets and System Traffic

SD-WAN Routes on Sophos Firewall are not only relevant for classic client-to-internet traffic. Depending on the environment, Reply Packets and system-generated traffic may also be affected. This is exactly where routing problems that are difficult to detect often arise: the rule looks correct, the Gateway is active, but replies go via the wrong path or the firewall itself does not reach a service via the expected line.

This guide explains the two CLI options reply-packet and system-generate-traffic, when to check them, and how to safely test changes. For the normal SD-WAN route setup, Set up and test Sophos Firewall SD-WAN route and test fits first. For the general order between static routes, SD-WAN policy routes and VPN routes, Sophos Firewall securely change Route Precedence also fits.

⚠️ These settings can immediately affect productive routing. Before making a change, you should document the current status, choose a maintenance window and know a clear way back. Particularly critical are wide SD-WAN routes with Any, Route Precedence in front of static routes and activated SD-WAN routing for System Traffic or Reply Packets.

What the two options are about

With SD-WAN Routes you have to differentiate between normal forwarded traffic, response packets and traffic that the firewall itself generates. The two options do not determine whether a single SD-WAN route is built correctly. Instead, they expand which traffic type can be taken into account by SD-WAN Policy Routing.

The two options have different tasks:

• reply-packet: Affects response packets to existing traffic. This allows the return path to be influenced via SD-WAN in certain non-WAN scenarios.
• system-generate-traffic: Affects traffic generated by the firewall itself. This allows firewall-specific connections to be routed via defined SD-WAN routes.

Both options should not be activated blindly just because “SD-WAN does not work”. First it must be clear whether Reply Packets or system-generated traffic is really affected. For normal connections, the actual cause is often the firewall rule, NAT, Route Precedence, Gateway status or a SD-WAN route that is too wide.

Reply Packets

Reply Packets are response packets to existing traffic. Sophos Firewall generally enforces symmetrical routing for such responses on WAN interfaces: response packets should return over the same WAN interface through which the original connection came in. The reply-packet option is particularly relevant if response packets are to be taken into account in certain SD-WAN Policy Routing scenarios. A typical example is asymmetric routing on non-WAN interfaces, such as between LAN and DMZ.

The important restriction is: If the original traffic runs via the default route or WAN Link Load Balancing, SD-WAN routes do not apply to this Reply Packets. The firewall then continues to use the appropriate return path via the interface of the original connection.

Typical test questions:

• Is it really reply traffic and not a new connection?
• Is the traffic going through WAN, LAN, DMZ, XFRM or another zone?
• Is there a SD-WAN route that is intended to intentionally influence the return route?
• Is the route too wide, for example destination Any?
• Does Route Precedence take effect before a static route or VPN route?

System generated traffic

System-generated traffic is traffic that the Sophos Firewall generates itself. Depending on the environment, this may include DNS, NTP, Sophos Central, Syslog, updates, monitoring, authentication services or diagnostic connections.

With this traffic, the firewall does not recognize a normal incoming interface and a normal source network as with forwarded client traffic. That’s why you should plan SD-WAN routes particularly closely for system-generated traffic: target networks and Services must be chosen sensibly. A very wide route can otherwise unexpectedly pull management or system traffic down a wrong path.

In addition, two practical limits apply:

• If all configured gateways under Network > WAN link manager are marked as Backup only, the firewall will 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 this.

When to check these settings

The two options are particularly relevant for more complex routing designs. In simple single WAN environments they are rarely the first lever.

Useful triggers:

• Firewall native traffic does not use the expected WAN or VPN path.
• Syslog, Central, DNS, NTP or monitoring should run over a specific line.
• Route-based IPsec VPN with XFRM interfaces is used together with SD-WAN Routes.
• VoIP or other sensitive traffic only works in one direction via SD-WAN/VPN.
• Packet Capture shows answers on a different interface than expected.
• After an upgrade, SD-WAN, IPsec or NAT behaves differently than before.
• A wide SD-WAN route suddenly affects internal networks or management access. For IPsec scenarios you should also include Sophos Firewall IPsec VPN Troubleshooting. For individual connections, Sophos Firewall rule test with Log Viewer and Packet Capture is often a better starting point.

View current status

The commands are executed in the Device Console, not in the Advanced Shell. If console access is not yet clear, Connect Sophos Firewall via SSH will help.

Check status for Reply Packets:

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

Check status for system generated traffic:

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

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

Before making any changes, the current edition should be documented. This is important because a later rollback is only possible cleanly if the previous state is known.

Enable options

SD-WAN Activate routing for Reply Packets:

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

SD-WAN Enable routing for system generated traffic:

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

Then execute the status commands again and document the output.

⚠️ Do not make multiple routing changes at the same time. If Route Precedence, SD-WAN route, NAT rule and these CLI options are changed at the same time, it is difficult to clearly attribute an error afterwards.

Secure flow for changes

A pragmatic process reduces the risk:

1. Define affected traffic specifically: Source, Destination, Service, Zone, expected Gateway.
2. Document existing SD-WAN routes, gateways and Route Precedence.
3. Check whether Destination Any is really necessary.
4. Document current status of reply-packet and system-generate-traffic.
5. Change only one option.
6. Run the test with a clear traffic example.
7. Check Log Viewer, Packet Capture and Gateway counters.
8. Document the result and only then make further adjustments. If management access may be affected, a secondary means of access should be available: local console, other internal access path, or access from an unaffected management network.

Validation after change

After activation, a green Gateway status is not enough. You have to check whether the desired traffic really takes the expected path.

Log Viewer and SD-WAN logs

Firewall and SD-WAN related events should be checked in the Log viewer. For relevant firewall rules, Log firewall traffic must be active. Without logging, you often only see part of the decision.

To check:

• Which Firewall Rule ID is hit?
• Which NAT Rule ID is used?
• Which Gateway or which interface appears in the log?
• Are there any drops, policy violations or unexpected security feature decisions?

Packet Capture

The actual packet flow can be checked with Diagnostics > Packet capture. For routing questions, the filter should be narrow: Source IP, Destination IP, Port and Protocol.

The comparison is important:

• Does the package arrive on the expected interface?
• Does it exit the firewall on the expected interface?
• Will the answer come back?
• Is NAT used?
• Is the return route plausible for Reply Packets?

Use Sophos Firewall Packet Capture in WebAdmin is suitable for operation and interpretation.

Check system services

In the case of system-generated traffic, you should specifically test the affected service:

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

If system-generated traffic is not visible, you should also check whether the SD-WAN route should only match source networks or incoming interfaces. These criteria are not available for firewall-owned traffic as they are for client traffic.

Typical errors

• SD-WAN route with destination Any for internal paths: Internal traffic or management access can be routed via WAN. Internet target groups or specific target networks are better.
• Route Precedence sets SD-WAN before Static: Directly connected or static networks may unexpectedly be matched by SD-WAN. Check Route Precedence and set Static in front of SD-WAN if necessary.
• system-generate-traffic active without destination limitation: Firewall-specific services can use the wrong path. Therefore, define target networks and Services closely.
• Reply Packets confused with normal new connections: Then the wrong cause is processed. Packet Capture and check flow direction.
• Several routing changes at the same time: The cause of the error remains unclear. Change gradually and document each test.
• No alternative management access: WebAdmin or SSH may be lost from the affected network. Prepare maintenance window and access path.

A particularly critical risk arises when several conditions come together: Route Precedence is on SD-WAN before static, a wide SD-WAN route uses Any, and SD-WAN routing for system-generated traffic or Reply Packets is active. In this case, access to WebAdmin or SSH from certain internal subnets may be lost.

Interaction with NAT, IPsec and VoIP

SD-WAN is rarely involved alone. NAT, IPsec or application-specific traffic play a role in many disruptions. What is important for SNAT is whether the same source IP is maintained across different gateways. If MASQ or different translated source addresses are used, failover or rerouting may cause communication problems. For the basics, Understand NAT fits Sophos Firewall.

For route-based IPsec VPNs, XFRM interfaces can be used in SD-WAN Routes or SD-WAN Profiles. Then IPsec status, SD-WAN route, Route Precedence and firewall rules should be checked together. The route-based VPN basics are categorized in IPsec Route on Sophos Firewall. If you have VoIP problems, it is also worth looking at SIP, RTP, NAT and SD-WAN. The SFOS-22.0-MR1 release notes document a fixed issue where VoIP audio only worked one-way via route-based VPN with SD-WAN routing after upgrading to SFOS 22.0 GA. The practical process can be found in Sophos Firewall Fix VoIP problems with SIP and RTP.

Rollback

Before making changes, the old status should be documented. If management access, system services or productive traffic are then affected, improvisation is no longer necessary. First restore the previous state.

Practically this means:

1. Reset documented before values for reply-packet and system-generate-traffic.
2. Return Route Precedence to the previous order if changed.
3. Temporarily deactivate SD-WAN routes that are too wide or limit them to specific destinations.
4. Test management access from an unaffected network.
5. Then further narrow down the actual cause.

If access to WebAdmin and SSH is lost from an internal subnet but is still possible from another subnet, the broad SD-WAN route, Route Precedence and the two CLI options should be checked from there first.

Checklist

• Current status of the two CLI options documented.
• Affected traffic specifically defined.
• SD-WAN route not built unnecessarily wide with Any.
• Route Precedence checked.
• At least one WAN-Gateway for System Traffic available as Active.
• Alternative management connection prepared.
• Only made one change per test.
• Log Viewer and Packet Capture used for validation.
• NAT, IPsec and firewall rules checked.
• Result and rollback documented in the operations journal.

FAQ