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.

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 and UDP timeout 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 system modules as loaded by default.

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.

The SFOS 22 CLI help documents load and unload for the SIP module, but no general system system_modules show command. Record the known starting state and every command executed in the maintenance log instead of relying on an assumed status command.

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.

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

180 seconds is a common troubleshooting example, not a general Sophos recommendation. If the packet capture and call drop time indicate that the stream timeout is too short, test the value in a controlled way:

set advanced-firewall udp-timeout-stream 180

⚠️ 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.

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. Test SIP Helper specifically and document the results.
10. Adjust a UDP timeout only deliberately and with the old value documented.
11. 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.
• 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.
• UDP timeout set very high: Global UDP sessions remain open unnecessarily long.
• 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 or unload test and intended final state documented
• 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 was only specifically tested.
• UDP timeout was only changed with a documented initial value.
• 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