Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Sonicwall has always affected voip equipment | Port filtration and Device Timeouts

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.

Category: Entry Level Firewalls


  • bobbob Newbie ✭

    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.

  • TKWITSTKWITS All-Knowing Sage ✭✭✭✭
    edited March 12

    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.

  • SaravananSaravanan Moderator

    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.


    Saravanan V

    Technical Support Advisor - Premier Services

    Professional Services

  • AjishlalAjishlal All-Knowing Sage ✭✭✭✭

    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.

  • bobbob Newbie ✭

    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.

  • TKWITSTKWITS All-Knowing Sage ✭✭✭✭

    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?

  • MitatOngeMitatOnge Newbie ✭

    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)

Sign In or Register to comment.