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.
The article classifies VoIP troubleshooting on the Sophos Firewall as a structured process. Known immediate measures such as deactivating SIP Helper or increasing UDP timeout remain important. However, such changes should not be made blindly, but rather as part of a clean troubleshooting process.
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-sided audio, or audio breaking off after a short period of time.SIP often runs over UDP or TCP
5060, with encrypted SIP often over5061. But that is not a law. Many providers use their own ports, their own proxy servers or additional requirements for NAT keepalives.
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.
Check 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 for rule analysis. For the actual packet flow, Packet Capture in WebAdmin is usually more meaningful than a pure policy test.
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.
That’s why the SIP Helper is a useful test point, but not a general permanent solution for every problem.The commands are executed via SSH on the Sophos Firewall. To do this, connect to the firewall and select 4. Device Console. SSH access should only be permitted from trusted networks. The basics are in Connect to Sophos Firewall via SSH.
Show current module status:
system system_modules show
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.
The current advanced firewall status is displayed in the Device Console:
show advanced-firewall
A common test value is 180 seconds:```shell
set advanced-firewall udp-timeout-stream 180
> ⚠️ `udp-timeout-stream` is not a pure VoIP control option, but has a broader effect on UDP sessions. The value should not be set arbitrarily high. It is better to have a defined test with documentation of the old value, provider requirements and subsequent control of the session and voice quality.
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 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 trafficAdditional points are added for incoming SIP trunks or published telephone systems:
- 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](/en/kb/sophos-firewall-nat-basics/). If a PBX needs to be accessible from the Internet, [Publish server via DNAT](/en/kb/sophos-firewall-server-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 outgoing but nothing comes back, the problem may lie with the provider, the return path, NAT or an upstream remote station. If RTP comes back but is not forwarded to the PBX, firewall rule, DNAT, routing or zone mapping are more likely.
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](/en/kb/sophos-firewall-tcpdump-tool-logs-collect/).
## 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](/en/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/) fits. [Sophos Firewall IPsec Troubleshooting](/en/kb/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](/en/kb/sophos-firewall-application-traffic-shaping/). For VoIP, you should not only check speed tests after implementation, but also carry out real test calls with simultaneous load.
## 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.
1
0. Only adjust the UDP timeout consciously and documented with the old value.
1
1. 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](/en/kb/sophos-firewall-logs-support-analysis/) fits. Which log file belongs to which service is described in [Sophos Firewall Troubleshooting: Services and Logs](/en/kb/sophos-firewall-services-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.
## Rollback and documentation
When making VoIP changes, it should always be clear how to get back:- old `udp-timeout-stream` value documented
- SIP module status documented before testing
- Changed firewall and NAT rules noted with date and reason
- Test calls logged with direction and time
- Packet Capture or relevant logs secured 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.
## 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
Should you always deactivate the SIP Helper on Sophos Firewall?
No. The SIP Helper can help or hinder depending on the provider and telephone system. It should be specifically tested. If deactivation does not bring any improvement, you should restore the previous status.
Why does the call work but you can't hear anything?
Then the SIP signaling works at least partially, but the RTP media stream does not run correctly. You check the RTP port range, NAT, firewall rule, return route and, if there are multiple WAN paths, SD-WAN.
Does a higher UDP timeout help with VoIP problems?
Sometimes yes, especially in the case of broken calls or unstable registrations. However, the value has a broader impact on UDP sessions and should therefore be conscious, documented and not set unnecessarily high.
What is important about VoIP over SD-WAN?
SIP and RTP should run via the expected path. If round trips use different WAN lines or VPN paths, one-sided audio or rejected connections may occur.