Sonicwall has always affected voip equipment | Port filtration and Device Timeouts
bob
Newbie ✭
Good afternoon team,
Sonicwall equipment in general at all low and mid levels attempted have had the same issue with voip equipment.
Issues being:
1) by sending recovery_on_timeout_expires intermittently where phones need to be rebooted to restore their connection.
2) Phone requesting a port somewhere in the range of 5060-5080 and the phone being assigned a random port in the 10000+ range by the sonicwall.
Steps followed:
Step 1:
-Firewall > Service Objects > Create service object
2 objects, for our port ranges 5060-5080 for SIP/VOIP registrations and 2 objects for port ranges 10k-30k for audio.
SIP port 5060-5080 TCP and UDP
10000-30000 UDP and TCP
Step 2:
network > services >
Firewall > Access Rules > Add > from ALL, to ALL, source ANY, destination ANY,
(create 1 for each of the service objects you created)
Step 3:
For SIP ALG go to VOIP > and uncheck all boxes with the exception of “Consistent NAT” which should remain ENABLED.
Despite addressing these settings, both TCP and UDP are given random port assignments from the sonicwall despite requesting the 5060-5080 range. Please advise if there are reports in the past this was resolved for, and advise steps to adjust the TCP/UDP timeout as well as it may help the issue.
Answers
If any of the bridge modes can avoid affecting voip data inbound and outbound but maintain WAP Controller functionality and WAP Configurations for their SSIDs any instructions would be appreciated.
Not sure what phones / PBX you are using, but that would help. Yes, there maybe occasional issues when encountering a new VoIP system but once you have good settings that can be reproduced there are rarely issues.
Above might be what you are looking for. Also below.
As far as editing UDP timeouts it is something that I regularly do for voice traffic, typically in the inbound and outbound access rules only. I do not like editing the timeouts globally.
Hi @BOB,
One thing as per my experience with VoIP is to make an exception from SonicWall Security Services for VoIP used port numbers or IP addresses for the VoIP to work smooth. This is because the VoIP is more sensitive and real-time.
Hope this helps.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
Hi @Bob,
If you are enabled the UDP Flood protection, increase the default Flood Attack Threshold(default value is 1K) to "10K" and try / Disable the UDP flood protection and do the test.
PBX is a proprietary system that uses elements of Trixbox and Asterisk. The phones are Polycom VVX 450s. This voip system doesn't experience any SIP port remapping on any network but ones involving Sonicwall.
We've implemented the flood protections, and made exceptions for the ports and phone IPs from any to any as described in the ticket. We've also increased the UDP/TCP timeouts and tried lowering them as well.
We'll see if the settings mentioned in "Source Remap" to stop port remapping resolves the issue and will follow up, but if there are any other settings on the sonicwall that would reject a network device's sip port request within 5060-5080 range and give it something over 10000+ for UDP transport SIP devices, it would be MUCH appreciated and encourage Sonicwall use for the hundreds of clients we often have to simply convince to swap network routers over the last decade.
I have Digium and Sangoma PBXs (both Asterisk based) behind Sonicwalls (with local and remote phones) and have never had what you are describing. Long ago I had a Trixbox I maintained that was behind a Sonicwall as well. I do not create such broad rules as you have described in your first post, as ANY ANY ANY rules should be a last resort and not a standard.
Are your phones and the PBX on different VLANs / networks? Are the phones offsite? Phone firmware up to date?
Hi @bob
Please check the "Enable SIP Transformation" checked on the SIP access rules,
App Control Advanced / VoIP catagory not blocked.
App Control Advanced filter as Application and check the SIP application not blocked.
some IP PBX sent to anonymuse authantication info during SIP logon process. please check the ip pbx logs. ( is the SIP phone info and password key correct)
I'll respond to each reply segment below. Thank you all for the suggestions, I think we've isolated the issue a bit further and will include my thoughts after all the replies.
-One thing as per my experience with VoIP is to make an exception from SonicWall Security Services for VoIP used port numbers or IP addresses for the VoIP to work smooth. This is because the VoIP is more sensitive and real-time.
Voip exceptions in and out ANY/ANY/ANY have been applied.
-Are your phones and the PBX on different VLANs / networks? Are the phones offsite? Phone firmware up to date?
PBX system is proprietary and a separate network but works and hosts across thousands of networks without this issue. Only sonicwall network associated devices have call drops and/or quality issues and always have registration ports remapped to random values.
-If you are enabled the UDP Flood protection, increase the default Flood Attack Threshold(default value is 1K) to "10K" and try / Disable the UDP flood protection and do the test.
This was done but issues persist.
-Please check the "Enable SIP Transformation" checked on the SIP access rules,
This was done but issues persisted. General voip recommendations online for sonicwall have been to keep H.323 settings disabled, sip transformations disabled, and only have 'consistent NAT' enabled.
-App Control Advanced / VoIP catagory not blocked.
We'll review our build and report back after applying this change.
-App Control Advanced filter as Application and check the SIP application not blocked.
We'll review our build and report back after applying this change.
-some IP PBX sent to anonymuse authantication info during SIP logon process. please check the ip pbx logs. ( is the SIP phone info and password key correct)
Phones register just fine and can make and receive calls. It's intermittently that they suddenly are unable to make/receive calls or drop in quality.
------------------------------------
There are a pair of settings above we're going to retry, but one of the visible issues we see, 'ports remapping' still persists despite our efforts. We've isolated the sonicwall to NAT Policies, but attempts to prevent port remapping are failing. Is there some specific recommended setting to keep phones on the service address object range pictured here '5060-5080'? Guides in the manual give vague examples so I suspect some value should be specific to 'original service' vs 'translated service'