Manage Sophos Firewall system modules safely

Sophos Firewall uses system modules as protocol helpers for traffic where the firewall must track additional protocol information or account for dynamic connections. SFOS 22 lists dns, h323, irc, pptp, sip and tftp. These modules are loaded by default.

A loaded module is neither a firewall rule nor a recommendation to use the corresponding protocol. It does not replace the required NAT rule, route or security policy. Conversely, unloading all apparently unused helpers is not a sensible hardening measure. The setting is global and can unexpectedly affect existing applications.

⚠️ Operating rule: First record the status and the specific failing flow. Change no more than one module, repeat the same flow and restore the original state if the change does not improve the result.

Classify the six modules correctly

The helper is often named too quickly as either the cause or the solution for sip and h323. The complete workflow for NAT, RTP, timeouts, custom SIP ports, packet capture and real test calls is described in Troubleshoot VoIP problems with SIP and RTP.

Record the baseline in Device Console

These commands belong in 4. Device Console, not Advanced Shell. Access it through SSH or through admin > Console in the upper-right corner of WebAdmin. For SSH, allow SSH for the required zone under Administration > Device access > Local service ACL; the web console requires HTTPS there. Do not open access more widely than required for the administration source.

Read the global state before making a change:

system system_modules show

Save the complete output even when only one module is being investigated. This reveals whether a migrated or previously modified system differs from the default. A displayed loaded only proves the module state. It does not prove that the helper processes a particular flow or causes its failure. If SIP was previously loaded with a custom port, also record its exact value from the existing configuration documentation. Do not change SIP if that value cannot be established reliably, because a state-preserving return path cannot then be prepared.

Also record source and destination IP, port, protocol, rule ID, NAT ID, time and the exact application test. Without a reproducible flow, a global change cannot be evaluated reliably. Log Viewer, Policy Test and Packet Capture are suitable for technical acceptance.

Load or unload exactly one module

The basic commands use the same pattern. The table is a reference, not a command block to run in full.

Before execution, check the installed build with the built-in help: enter the intended command and use ? to display its supported arguments. Do not submit incomplete variants speculatively; Sophos warns that an incomplete Device Console command can make the access_server daemon unresponsive. Run system system_modules show again after exactly one change, then repeat the previously documented application flow. Parallel changes to NAT, firewall rules, routing, timeouts or the PBX make attribution difficult and should be avoided.

Sophos explicitly documents that SIP load and unload survive a restart. The SFOS 22 system-modules page does not make the same precise persistence statement for the other modules. Read their state again after a planned restart instead of assuming persistence.

Do not infer custom ports from incomplete shorthand syntax

The system-modules page lists additional terms such as port, portname, default or show for IRC, SIP and TFTP, but does not fully explain their exact input form. Do not guess these values. Device Console displays the syntax for the installed build with ?.

For SIP, Sophos separately publishes the exact custom-port command system system_modules sip load ports <custom_port>. This decision belongs in the VoIP analysis, not a general helper test. Replace the placeholder with the signalling port actually used by the provider or PBX.

Know the SIP limits before testing

By default, the SIP helper uses UDP port 5060. It translates local IP addresses in the SIP header to public addresses and creates an expected dynamic voice connection in the firewall. This explains why its effect goes beyond merely recognizing signalling.

Two limits are essential when diagnosing a fault:

• The helper supports SIP media ports only in the range 1024–65535. If a configured media port is outside this range, the firewall drops the packets and the event log reports Invalid Traffic.
• The helper does not support a SIP or SDP message that spans more than one packet. This can occur with SIP over TCP. Sophos identifies a SIP UDP control connection as the workaround; use it only if the provider, PBX or SBC supports it.

A custom signalling port and the RTP media range are different values. <custom_port> in the load command is the SIP signalling port actually in use; do not derive an RTP range from it.

Verify the effect and the return path

A meaningful test checks more than the CLI output. After loading or unloading, verify the specific connection setup, traffic in both directions, rule and NAT ID, drops and the affected application. For SIP or H.323, this includes registration, incoming and outgoing connections, and media in both directions. For DNS, verify request and response with the expected name. For TFTP, verify the file transfer as well as its start.

If the symptom remains unchanged or new faults appear, return only the modified module to the previously recorded state:

• If it was loaded with the default setting, load it again with the corresponding ... load command.
• If it was unloaded, unload it again with the corresponding ... unload command.
• If SIP was loaded on a custom signalling port, restore that exact saved value with system system_modules sip load ports <previous_custom_port>. Replace <previous_custom_port> with the baseline value, not a new example value.

Then run system system_modules show and the same test flow again. The CLI output must match the saved baseline, and the original application path must not have acquired an additional fault from the test. A restart is not a substitute for this rollback.

If the behavior changes but the cause remains unclear, preserve the before-and-after state, firmware build, logs and packet capture. A globally unloaded helper should not remain as a permanent solution merely because one short test looked better.

For SIP, the symptom points to the next check: Invalid Traffic with missing media leads first to the configured media port and the 1024–65535 range. If TCP registration fails or long SIP/SDP messages break, check the multi-packet limitation. If the displayed module state is correct but behavior does not change, first confirm the signalling port actually in use and the affected rule/NAT path.

FAQ