Overview
This guide covers how to configure a SonicWall firewall for SIP-based VoIP services.
SonicWall works well with VoIP, but only if a few default features are adjusted. In most cases, issues come down to SIP transformations (ALG), NAT behaviour, or blocked RTP traffic.
If these aren’t set correctly you’ll typically see:
- One-way audio
- Calls dropping after ~30 seconds
- Phones not registering
Before you start
You’ll need:
- Admin access to the SonicWall
- Your SIP provider details (IP ranges if available)
- A basic understanding of your LAN/WAN layout
If the system is behind another router (double NAT), expect problems unless that’s been designed properly.
Ports used by VoIP
SIP uses separate ports for signalling and media.
- SIP signalling: 5060 (UDP/TCP), sometimes 5061 (TLS)
- RTP media: usually UDP 10000–20000
Both need to work in both directions — blocking either side will break calls.
Configuration
1. Disable SIP Transformations (SIP ALG)
This is the first thing to check on any SonicWall.
Go to:
VoIP → Settings
Untick:
- Enable SIP Transformations
Apply the change.
Why this matters:
SonicWall tries to “help” SIP traffic, but in practice it rewrites packets in a way that breaks NAT and media routing. It’s one of the most common causes of one-way audio.
2. Enable Consistent NAT
In the same menu:
VoIP → Settings
Enable:
- Consistent NAT
What this does:
Keeps SIP sessions tied to a predictable public IP/port mapping. Without it, RTP streams can end up going to the wrong place.
3. Check Flood Protection
Still under VoIP settings:
- Review SIP Flood Protection
- Either tune it or disable it if you suspect it’s blocking legitimate traffic
This isn’t always an issue, but we’ve seen it interfere in higher call volume environments.
4. Firewall Rules
You don’t need anything unusual here — just make sure SIP and RTP are actually allowed out.
Go to:
Firewall → Access Rules (LAN → WAN)
Create or confirm rules for:
SIP
- Service: UDP 5060 (or SIP object)
- Destination: preferably your provider’s IPs
RTP
- Service: UDP 10000–20000
- Destination: Any (or provider range if known)
If these ports aren’t open outbound, phones simply won’t register or will drop media.
5. NAT Policy
Go to:
Network → NAT Policies
In most cases, the default outbound NAT (LAN → WAN) is fine.
If you’re hosting an on-prem PBX:
- Consider a static NAT (1:1)
- Or make sure SIP traffic always leaves via the same public IP
6. QoS (worth doing if there’s any load on the line)
If the connection carries other traffic (file transfers, backups, etc.), prioritising voice will make a big difference.
Go to:
Firewall → QoS
Create a rule matching:
- UDP traffic
- RTP port range (10000–20000)
Set it to:
- High / real-time priority
Even a small amount of shaping here can stabilise call quality.
Good practice (based on real installs)
- Don’t leave SIP open to the entire internet — restrict it if you can
- Avoid double NAT unless there’s a clear reason for it
- If using hosted VoIP, you don’t usually need inbound port forwarding
- If using an on-site PBX, design NAT properly (don’t guess it)
Troubleshooting
These are the patterns we see most often:
Calls connect but no audio (or only one side hears audio)
Usually RTP is being blocked or mis-routed.
Things to check:
- RTP port range is allowed out
- Consistent NAT is enabled
- No second router is interfering
Calls drop after ~30 seconds
Almost always SIP ALG still in play somewhere.
Check:
- SIP Transformations is definitely off
- There isn’t another firewall upstream doing the same thing
Phones won’t register
Start simple:
- Is UDP 5060 actually allowed out?
- Is DNS resolving the SIP server correctly?
- Is the WAN connection stable?
Call quality is poor (jitter, clipping)
Look at the wider network:
- Is the link saturated?
- Is QoS in place?
VoIP doesn’t need much bandwidth, but it does need consistency.