Sophos Firewall: Invalid TCP reserved bit caused by Accurate ECN

If Sophos Firewall drops legitimate TCP traffic with Invalid TCP reserved bit, Accurate ECN may be the cause. An additional allow rule or a web filter exception does not help in this case because the drop occurs during strict TCP validation.

Sophos specifies disabling strict-policy globally as the workaround. This change should only be made after obtaining clear evidence: it applies to the entire firewall and does not relax the check only for the affected traffic flow.

Identify the error conclusively

The workaround is appropriate only when all of the following conditions apply:

• A specific TCP connection reproducibly fails or cannot be established.
• Log Viewer or Packet Capture shows Invalid TCP reserved bit as the drop reason.
• The firewall rule, NAT, and routing match the expected traffic path.
• A broad allow rule does not change the behaviour.
• The TCP handshake capture shows AE, CWR, and ECE set on the dropped initial SYN. AE was formerly called NS and is still labelled NS by Sophos and older decoders.

For the first test, open Log viewer in the upper-right corner of Web Admin, select the Firewall module, and narrow the results by time, source IP, and destination IP with Timer filter and Add filter. Also use the free-text search to look for Invalid TCP reserved bit. A failed session may not appear immediately, however: Sophos Firewall normally logs firewall sessions only when the connection is closed.

Therefore, confirm the drop reason under Diagnostics > Packet capture. Under Configure, for example, this BPF filter limits the display to two documentation addresses and HTTPS:

host 192.0.2.10 and host 198.51.100.20 and port 443

Replace both IP addresses and the port with the values of the failing connection. Turn on Trace On, trigger exactly one connection attempt, and turn capture off again. In Display filter, select Status: Violation and Reason: INVALID_TRAFFIC. This lets SFOS confirm the violation and the Invalid TCP reserved bit reason; use the WebAdmin view only for that confirmation.

For full TCP handshake and flag analysis, make a separate capture over SSH with tcpdump, bounded by time, hosts, and port. Save it as a PCAP and open it in Wireshark or another decoder. Follow Collect logs with the Sophos Firewall tcpdump tool. Current Wireshark uses the display field tcp.flags.ae; tcp.flags.ns is legacy terminology.

If the specific drop reason is missing, strict-policy should not be disabled as a precaution. First test the firewall rule, NAT, and packet flow.

Why Accurate ECN is identified as invalid

Explicit Congestion Notification, or ECN, signals congestion without dropping a packet solely for that purpose. Accurate ECN extends this mechanism and calls the bit formerly known as NS AE. Sophos NC-169842 and older decoders still use the name NS.

Capturing the TCP handshake is required for the known-issue signature: the dropped initial SYN has SYN plus AE (formerly NS), CWR, and ECE set. If the SYN is forwarded, inspect the SYN/ACK to establish whether Accurate ECN negotiation succeeded. AE/NS alone is not conclusive. In an established flow, combinations of AE, CWR, and ECE form the ACE counter rather than retaining the legacy per-flag meanings. See RFC 9768 section 3.1.1 and section 3.2.2.

Sophos states under NC-169842 that strict packet validation can interpret the AE bit, which it still calls NS, as a set reserved TCP bit and drop the traffic. The log therefore shows Invalid TCP reserved bit, even though the sender is using the bits for Accurate ECN. The issue definition checked for this procedure identifies ECE, CWR, and NS (now AE) as the signature and gives two alternatives: generate traffic without those Accurate ECN bits or disable the strict TCP policy check from the CLI.

This procedure is deliberately limited to the only version identified as affected there: SFOS 21.5.0 GA Build 171 (21.5.0.171); no fix version was identified. The SFOS 22.0 help still documents the strict-policy parameter, but that does not establish that NC-169842 affects SFOS 22.0. On another build, use the workaround only after verifying the full signature and first open a support case with the packet capture and log excerpt. If the release notes for a newer build explicitly list NC-169842 as fixed, prefer that tested update over retaining the global workaround.

Check Strict Policy

Run the commands at the console> prompt of the Device Console, not in the Advanced Shell:

1. Sign in to the firewall through SSH or the local console.
2. Select 4. Device Console from the main menu.
3. Display the current state:

show advanced-firewall

Find this line in the output:

Strict Policy                  : on

The complete output contains additional global firewall parameters. These should not be changed for this test. If access has not yet been configured, see Connect to Sophos Firewall through SSH.

In SFOS 22.0, on is the documented default. The current value you have just read with show advanced-firewall is still authoritative for rollback. If it is already off, the workaround is already active; do not toggle it, and investigate the case with Sophos Support instead. Check Advanced Firewall Settings safely explains the other values, the baseline, control test, and rollback.

Test the workaround in a controlled manner

⚠️ Security impact: strict-policy off disables strict packet validation globally. Sophos Firewall then no longer rejects certain unusual or potentially harmful packet patterns through this check. The command does not create an exception for an individual IP address, domain, or firewall rule.

Before making the change, save a current configuration state, document the affected test case, and schedule a maintenance window. Then run:

set advanced-firewall strict-policy off

Check the new state:

show advanced-firewall

Expected line:

Strict Policy                  : off

Now retest only the previously documented traffic flow. If it works immediately and the Invalid TCP reserved bit drop reason disappears, this confirms that Strict Policy triggers the drop. Only a captured handshake showing SYN plus AE/NS, CWR, and ECE on the dropped initial SYN associates the drop with the NC-169842 signature.

If the error remains unchanged, re-enable strict-policy immediately. The cause is then probably elsewhere in the packet flow.

Re-enable Strict Policy

If the value recorded before the change was on, the rollback command is:

set advanced-firewall strict-policy on

Then use show advanced-firewall again to verify that Strict Policy : on is displayed, and check both the test case and normal traffic. If the repeated initial SYN contains the same AE/NS, CWR, and ECE signature and follows the same path, Invalid TCP reserved bit should recur. If it does not, compare the handshake flags and path before drawing a conclusion from the control test.

Even if the workaround works, strict-policy off should not become a permanent state without an assessment. The preferred order is:

1. Check whether the sender, operating system, application, or upstream service can disable Accurate ECN or negotiate it differently.
2. Check the release notes for available SFOS maintenance releases for an explicit NC-169842 fix.
3. Involve Sophos Support and provide the SFOS version, timestamp, source and destination, drop reason, and Packet Capture.
4. Only if no narrower solution is possible, continue operating with the global change after accepting the risk and documenting monitoring and the rollback procedure.

The required evidence can be collected with Save Sophos Firewall logs for a support case.

What does not help

• A broader firewall rule: Strict TCP validation is not normal rule matching.
• Web or TLS exceptions: The drop can occur before these policies process the traffic.
• An IPS exception as a precaution: For NC-169842, Sophos explicitly identifies Strict Policy as the cause and workaround.
• Disabling the global setting without a baseline: Without a reproducible before-and-after test, there is no proof that Accurate ECN caused the issue.