Sophos Firewall Fix VoIP problems with SIP and RTP

VoIP problems behind a Sophos Firewall often have a diffuse effect: telephones do not register, calls are dropped, it rings without audio or speech can only be heard in one direction. In practice, the cause is rarely due to a single switch. SIP signaling, RTP media stream, NAT, firewall rules, UDP timeouts or routing usually work together.

This article presents VoIP troubleshooting on Sophos Firewall as a structured process. Common quick fixes such as disabling SIP Helper or increasing a UDP timeout are only controlled tests. First identify the packet path, the firewall and NAT rules actually in use, and inspect SIP and RTP separately.

Understand SIP, RTP and symptoms

What runs through the firewall with VoIP

VoIP roughly consists of two parts:

• SIP: controls registration, call setup, call clearing and negotiation of media parameters. Typical errors include failed registration, calls not being established or SIP dialogs rejected by the provider.
• RTP: transports the voice data during the conversation. Typical errors include missing audio, one-way audio or audio stopping after a short time.

SIP often runs over UDP or TCP 5060, and encrypted SIP often uses 5061. These are not universal values. Many providers use different ports, proxy servers or additional NAT keepalive requirements.

RTP usually uses UDP port ranges that are specified by the provider, the telephone system or the end devices. For a clean analysis, you need the specific SIP servers, RTP port ranges and transport protocols from the provider or the PBX documentation.

Sophos Firewall also supports H.323 alongside SIP. This runbook focuses on SIP signaling and RTP. If the telephone system actually uses H.323, check the H.323 service and H.323 Helper separately; SIP Helper settings are then not automatically the right control.

Classify symptoms correctly

Before making any changes, you should classify the symptom as accurately as possible.

• Registration fails: Check DNS, routing, firewall rule, NAT, provider credentials or SIP transport.
• Call does not connect: Check SIP signaling, firewall rule, Application Control and possible provider blocks.
• Call works but no audio: Check RTP port range, NAT, return route, SD-WAN and SIP Helper.
• Audio is only audible in one direction: Check RTP return path, NAT, routing, VPN and SD-WAN.
• Conversation breaks off after 30, 60 or 120 seconds: Check UDP timeout, NAT keepalive, session refresh and provider expectations.
• Only incoming calls do not work: Check DNAT, firewall rule, provider source networks and PBX port sharing.
• Only one WAN line causes problems: Check SD-WAN route, reply path, gateway and provider IP binding.

This classification prevents you from changing SIP settings even though the actual problem lies in the RTP return path or an SD-WAN route.

Capture the baseline before making changes

Before making CLI changes, you should document the current status:

• Which phones, PBX or SBC are affected?
• Do end devices register directly with the provider or does everything run via an internal telephone system?
• Which SIP servers and RTP port ranges does the provider name?
• Which firewall rule processes the VoIP traffic?
• Is Log firewall traffic enabled in this rule?
• Which NAT rule applies to outgoing and incoming VoIP traffic?
• Are there multiple WAN lines, SD-WAN routes or route-based VPNs?
• Did the problem become visible after a firmware upgrade, provider change or PBX update?

Test firewall rules on Sophos Firewall helps with rule analysis. For the actual packet flow, Packet Capture in WebAdmin is usually more meaningful than a policy test alone. Do not change global CLI values until a reproducible test call and this baseline are available.

Check packet path, routing and quality

Check firewall rules and NAT

NAT is often involved in VoIP problems. The Sophos Firewall must not only allow SIP, but also correctly translate and return the associated RTP streams in both directions.

These points are usually relevant for outgoing telephones or an internal PBX:

• appropriate firewall rule from the VoIP zone or PBX zone to WAN
• appropriate SNAT or MASQ rule
• Logging in the firewall rule
• no rule that is too wide or incorrectly positioned above the VoIP rule
• no unexpected Application Control, IPS or web filtering on this traffic

Whether an incoming SIP trunk actually needs DNAT depends on the provider design. Registration-based trunks may use the existing outbound session. Trunks delivered directly to a public address, or published telephone systems, usually require a narrowly scoped DNAT rule. The provider or SBC operator’s requirements are authoritative.

If DNAT is required, check these additional points:

• DNAT to the internal PBX or SBC
• Firewall rule with appropriate target zone and target network
• Restriction to provider source networks, if possible
• only required SIP and RTP ports
• Logging and Packet Capture for testing

A NAT rule does not allow traffic, but only translates addresses or ports. The connections are explained in Understand NAT on Sophos Firewall. If a PBX needs to be accessible from the Internet, Publish server via DNAT is the better basis for the actual publication.

Analyze RTP and language direction

If the call is established but audio is missing, SIP is usually no longer the main issue. Then you have to check whether RTP flows in both directions.

Typical process:

1. Note provider or PBX RTP port range.
2. Start Packet Capture with Source IP of the PBX or phone and RTP port range.
3. Make a test call.
4. Check whether UDP packets from the internal device to the provider are visible.
5. Check whether UDP packets are returning from the provider.
6. Compare NAT ID, Rule ID, In interface and Out interface.

If RTP is only visible outbound and nothing returns, the problem may be with the provider, return path, NAT or an upstream device. If RTP returns but is not forwarded to the PBX, the firewall rule, DNAT, routing or zone assignment are more likely causes.

For more precise recordings or PCAP export, tcpdump via SSH can be useful. The process is described in Sophos Firewall Use tcpdump for logs and analysis.

SD-WAN, VPN and multiple WAN lines

VoIP is sensitive to asymmetrical paths. If SIP runs over a WAN line but RTP returns over a different line or a route-based VPN is routed differently, typical errors such as one-sided audio arise.

A bug fixed in SFOS 22.0 MR1 shows the typical connection: After an upgrade to SFOS 22.0 GA, VoIP audio could only work one-way over route-based VPN with SD-WAN routing. In practice, this means: SD-WAN should always be checked when using VoIP over VPN or multiple WAN paths.

Important checkpoints:

• Does an SD-WAN route access VoIP traffic?
• Are SIP and RTP routed over the same expected WAN line?
• Are there provider specifications regarding source IP or public sender address?
• Is a route-based VPN route with an XFRM interface used?
• Do return routes and NAT match the chosen path?
• Does Packet Capture show different gateways or interfaces for outward and return directions?

For Sophos-specific SD-WAN options, SD-WAN routing reply packet and system traffic fits. Sophos Firewall IPsec Troubleshooting also helps with IPsec connections.

Traffic shaping for VoIP

Traffic shaping can stabilize VoIP when lines are tight or large uploads displace voice packets. However, it does not solve incorrect NAT rules, missing RTP ports and incorrect return routes.

Traffic shaping is particularly useful if:

• VoIP gets worse when the internet line is under load,
• Uploads or backups disrupt conversations,
• multiple applications use the same line,
• VoIP should be specifically prioritized.

The configuration is described in Application Traffic Shaping on Sophos Firewall. For VoIP, you should not only check speed tests after implementation, but also carry out real test calls with simultaneous load.

Test SIP Helper, UDP timeout and DoS in a controlled way

The following settings affect more than one VoIP rule. Use them only after narrowing down the cause, with a documented baseline, a maintenance window and a clear rollback.

Check SIP Helper

The SIP Helper, often also called SIP ALG, attempts to recognize SIP packets and adapt NAT-relevant SIP information. This can help in simple environments. However, it can also be disruptive in many modern VoIP setups with provider SBC, own PBX, TLS, clean NAT keepalive or more complex RTP port ranges.

SIP Helper is therefore a useful test point, but not a general permanent fix. Sophos documents the SIP module as enabled by default. Changes made with load or unload persist after a restart.

Run the commands over SSH on Sophos Firewall and select 4. Device Console. Permit SSH access only from trusted networks. The basics are covered in Connect to Sophos Firewall via SSH.

Display the current state before and after each change with a read-only command:

system system_modules show

Document the output for the sip entry. This makes it clear whether the helper was loaded before the test and which state is expected after rollback.

Deactivate SIP module:

system system_modules sip unload

Reactivate SIP module:

system system_modules sip load

⚠️ This change should be made in a maintenance window or with clearly defined testing. After disabling or enabling, registration, outgoing calls, incoming calls and audio must be checked in both directions.

If the change doesn’t help, you should take it back. It is important to document the condition before and after the test.

If the provider uses a custom SIP signaling port instead of UDP 5060, load the helper with that exact port:

system system_modules sip load ports <custom_port>

Replace <custom_port> with the SIP port specified by the provider or PBX vendor, not with an entire RTP port range. The SIP Helper supports media ports from 1024 to 65535. If a media port lies outside this range, the firewall may drop the traffic and show Invalid Traffic in the event log.

SIP over TCP has another limitation: The helper doesn’t support SIP or SDP messages that span multiple packets. If the packet capture shows exactly this pattern, clarify the transport with the provider and PBX vendor. Switching to SIP over UDP only makes sense if both sides support it.

Check and adjust UDP timeout

VoIP often uses UDP. If NAT or session entries expire too early, a registration may appear to work, but calls drop or incoming calls do not reach the PBX reliably.

Sophos distinguishes between two global values:

• udp-timeout applies to UDP connections that have not yet been recognised as a bidirectional stream.
• udp-timeout-stream applies to established UDP streams where both endpoints have sent traffic on the same port between network segments.

Both values accept 30 to 3600 seconds in SFOS 22. Display the current advanced firewall values in Device Console:

show advanced-firewall

The current SFOS 22 help lists 60 seconds as the default UDP Timeout Stream value and recommends 150 seconds for VoIP. However, the value actually shown and the provider’s requirement remain authoritative. If packet capture and call drop time indicate that the stream timeout is too short, test the documented value in a controlled way:

set advanced-firewall udp-timeout-stream 150

⚠️ udp-timeout-stream is not a VoIP rule option. It affects all matching UDP streams. Do not raise it speculatively or arbitrarily. Record the old value from show advanced-firewall and restore it with the same set command if the test is unsuccessful.

If the provider or the telephone system supports NAT keepalive, this setting should also be checked. A clean keepalive on the PBX or provider side is often better than a very high global timeout value.

Check UDP flood thresholds

VoIP generates many UDP packets. If the thresholds under Intrusion prevention > DoS & spoof protection > DoS settings are too low, the firewall may drop legitimate SIP or RTP traffic as a UDP flood. Before making a change, document the current Packet rate, Burst rate and Apply flag values as well as the drop counters.

Sophos lists temporarily removing the Apply flag for UDP flood as a diagnostic test. This reduces DoS protection during the test and therefore belongs in a maintenance window with a narrowly defined test case. If VoIP improves, adjust Packet rate and Burst rate to the measured legitimate load and set the Apply flag again. If the problem remains unchanged, restore the initial state immediately.

A targeted exception for known hosts or ports can be safer than disabling protection globally. Spoof Protection and DoS protection on Sophos Firewall explains how thresholds and DoS bypass rules work together. Protection should not remain disabled after the test.

Troubleshooting and evidence

Practical troubleshooting flow

1. Document symptom: registration, call setup, audio, abort time, direction.
2. Collect provider data: SIP server, transport, RTP port range, NAT requirements.
3. Identify firewall rule and NAT rule.
4. Activate logging in the affected firewall rule.
5. Open Log Viewer and Packet Capture during a test call.
6. Check whether SIP signaling runs in both directions.
7. Check if RTP runs in both directions.
8. If there are multiple WAN lines, check SD-WAN and return path.
9. Check the SIP Helper state, test changes specifically and document the results.
10. Adjust a UDP timeout only deliberately and with the old value documented.
11. If UDP drops occur or quality degrades under load, check the UDP flood thresholds in a controlled way.
12. After each change, test registration, outgoing calls, incoming calls and audio in both directions.

If several changes are made at the same time, the subsequent cause is difficult to understand. One test per change is better.

Collect evidence during a test call

A VoIP test is only helpful if the time, direction and packet flow match. Especially in provider cases, the statement “Audio doesn’t work” is not enough. You need a small, reproducible test case.

• Exact time with time zone: Log Viewer, Packet Capture and provider logs can be easily compared later.
• Call direction: incoming calls, outgoing calls and internal forwarding are not mixed.
• Phone numbers or extensions: Providers and PBXs find the specific call more quickly.
• Internal IP of PBX or phone: Packet Capture can be narrowly filtered.
• Provider SIP server and RTP port range: SIP and RTP analysis remain separate.
• Rule ID, NAT ID, In interface and Out interface: you can see which rule and which path were actually used.
• Event log and DoS counters: Invalid Traffic or increasing UDP flood drops narrow the issue down to the helper port range or DoS thresholds.
• Result per test: Registration, ringing, call setup, audio left/right and termination time remain traceable.

In the event of sporadic errors, you should also back up the relevant logs before they are overwritten. For a clean log package, Sophos Firewall Back up logs for support and analysis fits. Which log file belongs to which service is described in Sophos Firewall Troubleshooting: Services and Logs.

Common errors

• Only SIP port enabled, forgot RTP port range: The call sets up but audio is missing.
• NAT rule exists, but no matching firewall rule: Traffic is translated but not allowed.
• Firewall rule without logging: Troubleshooting in Log Viewer remains blind.
• SIP Helper deactivated or activated across the board: The problem is randomly moved instead of analyzed.
• Custom SIP port confused with the RTP port range: The helper is loaded on the wrong signaling port.
• UDP timeout set very high: Global UDP sessions remain open unnecessarily long.
• UDP flood protection too strict or permanently disabled: Legitimate voice packets are dropped or protection remains unnecessarily reduced after the test.
• Multiple WAN paths without a clear SD-WAN rule: One-way audio or provider rejected traffic becomes more likely.
• Provider source networks not restricted: The SIP service is unnecessarily broadly accessible from the Internet.
• Traffic shaping understood as a replacement for NAT/routing: The voice quality remains poor because the cause lies elsewhere.

Roll back changes cleanly

When making VoIP changes, the rollback must be clear:

• old values for udp-timeout and udp-timeout-stream documented if they are changed
• the SIP load, unload or custom-port test and intended final state documented
• original UDP flood thresholds and Apply flags documented and restored after the test
• changed firewall and NAT rules recorded with date and reason
• test calls logged with direction and time
• Packet Capture or relevant logs retained for support cases

If the change doesn’t help, it shouldn’t be left as an accidental legacy. VoIP workarounds in particular will otherwise become difficult to understand later.

Operating checklist

• Provider SIP and RTP information is available.
• Firewall rule for VoIP is identified and logging is active.
• NAT rule matches the direction of traffic.
• SIP and RTP were checked separately.
• Packet Capture shows back and forth direction.
• SIP Helper state was checked before and after the targeted test.
• A custom SIP port matches the provider or PBX specification and is not confused with the RTP port range.
• UDP timeout was only changed with a documented initial value.
• UDP flood thresholds and DoS protection were returned to a secure final state after the test.
• SD-WAN, VPN and multiple WAN lines were checked.
• Traffic shaping is used only for quality control, not as a replacement for routing or NAT corrections.

Frequently asked questions