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, not that the helper processes a particular flow or causes its failure. It also does not prove that IRC, SIP or TFTP is configured without custom ports or other custom arguments. Before any change, explicitly establish and document whether the affected module has a confirmed default configuration with no custom ports or other custom arguments.

For IRC, SIP or TFTP with custom arguments, record the complete baseline as actually configured and a supported procedure for exact restoration, confirmed for the installed build, before the test. For SIP, this includes the exact custom signalling port from the existing reliable configuration documentation; for IRC and TFTP, it includes all actually configured port values and other argument values. Syntax help alone does not establish the current configuration. If the baseline is unclear, values are missing or the state-preserving restoration procedure has not been confirmed, leave the affected helper unchanged. Do not guess default values or restoration commands.

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. A simple change using these commands and its inverse for restoration are intended only for a default baseline confirmed in advance to have no custom ports or other custom arguments. For IRC, SIP or TFTP with custom settings, use only the change and restoration procedure recorded before the test and confirmed for the installed build; do not start a test without it.

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 previously loaded and the default baseline with no custom ports or other custom arguments has been confirmed, load it again with the corresponding ... load command.
• If it was previously unloaded and the default baseline with no custom ports or other custom arguments has been confirmed, unload it again with the corresponding ... unload command. Here too, the status alone is not sufficient evidence that there are no custom arguments.
• If SIP was previously 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. This restoration procedure must also be confirmed for the installed build before the test and must restore the complete saved configuration.
• For IRC or TFTP with custom ports or other custom arguments, restore the complete saved baseline only with the supported restoration procedure previously confirmed for the installed build, not with a simple inverse load or unload command. If this procedure is unavailable, leave the helper unchanged from the outset.

Then run system system_modules show and the same test flow again. The CLI output must match the saved initial state, and the test must not have caused any additional disruption to the original application path. For IRC, SIP or TFTP with custom settings, also compare the complete configured baseline, including all saved argument values, using the verification procedure confirmed in advance; a matching module status alone does not prove that these have been restored. 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