Happiness With Sonicwalls - It can happen!

General Help
1

Ok - Wasted quite a bit of time this morning with a new configuration we were trying out and I thought I would post it here so that no one else has to waste the same amount of time that I did this morning.

First, some general information:

For a standard setup with a FreePBX/Asterisk PBX onsite, you will need the following on the Sonicwall:

  1. A Port Forwarding rule of 5060-UDP for the Incoming SIP Trunk - Sonicwalls are very AGGRESSIVE about closing that port, so if you use a SIP trunk and you don’t forward the traffic, you will have problems with inbound calls - outbound will work fine, but skip the drama and put the rule in. If you are using a non-standard port, change the rule accordingly. If you want tighter security, find out your ITSP’s address range and restrict the incoming to that source.

  2. A Port Forwarding rule of 10000-19999-UDP for the incoming RTP - sometimes you can get away without this rule - depends on the ITSP - Put it in anyway. If you want tighter security, find out your ITSP’s address range and restrict the incoming to that source.

  3. Set the UDP Timeout on your LAN->WAN Firewall Rule to 300 seconds - the default is 30, but that is too low.

  4. Under VoIP, enable “Consistent NAT” and disable everything else - Asterisk takes care of it!

  5. Three NAT policies will be created when implement this using the “Public Server Wizard” - Two of them need the following option set:

That “Disable Source Port Remap” can be a killer if you are registering to Broadsoft servers - you will find that some (but not all) of your outbound calls fail - turn it on in 2 of the three rules - the third rule created by the wizard won’t let you turn it on.

This works fine for phones on the same LAN as the PBX and also for remote phones connecting to the office from offsite.

However, we found out this morning a different scenario - A PBX Hosted in a CoLo behind a Sonicwall with ALL the phones remote to the PBX behind another Sonicwall - Same Rule Set as above, but after the wizard runs, you will need to create a 4th NAT Policy and it needs to look like this:

Without this last rule, we were having phones drop off constantly - although it was MUCH worse with Grandstream phones than any of the Polycom, Sangoma, or Yealink phones - I guess the Grandstreams are just more sensitive.

Hope this helps someone - Sonicwalls are nice and tight on security - but they can be a little non-obvious at times.

13 Likes
2

Wow - good write-up.

3

Thanks - As dangerous as it is out there, I like my Sonicwalls more and more - especially with GeoIP blocking - more than 90% of the attacks I see against my Sonicwalls go away when I block about 5 countries!

1 Like
4

Has anyone had any luck with remote phones behind sonicwalls? I was curious if sip TLS would keep the Sonicwall from mangling the packets?

5

Yeah, that is the whole purpose of the post - ALL the phones on this install are behind a Sonicwall at the client site, and then the PBX is ALSO behind a Sonicwall - no changes necessary to the Sonicwall that the phones are behind (other than Consistent NAT and the UDP timeout on your outbound Firewall Policy) and then the settings explained above for the Sonicwall that the PBX is behind - works perfectly and no need to resort to TLS or VPN or anything - in the Wild!

6

I wasted more than just a morning to get my Sonicwall properly configured to pass SIP traffic.
Was scratching my head and now you come along and provide such a great guide.
Thanks a lot!

7

Nice job Greg! I know sonicwalls stump a lot of folks. One ? Is there any worry about memory use with the UDP timeout set to 300 and a certain # of extensions? I bow to your knowledge of this topic but wouldn’t 90 or 120 possibly work as well?

1 Like
8

Actually I have a customer with over 400 extensions - although at most they have 70-90 active during the day - but we have not had a problem - although with that many phones spread over 22 states, we sure see the bad connections on the remote side.

I think any current generation Sonicwall (TZ400,500,600,NSA2600,3600 and above) should work fine.

9

2017-06-07 - One More update for people using Broadsoft SIP Trunks - We were having a problem with some of the Outbound Calls failing randomly with a 403-Forbidden - turns out that the Sonicwall was occasionally re-mapping the source port for a Re-Regsitration - so the registration would be at some high port (15735) and then the next time an outbound call was initiated, it would be coming from the proper port (5060) and you get “All Circuits Busy” because of the 403.

Solution is to set nat=no on both the outbound and inbound leg of the SIP trunk. Wasted a lot of time on this one too…

2 Likes
10

2017-07-03 - Final update for this thread - In testing with another provider (Vitelity) using IP-Auth for a trunk for them, if “Disable-Source-Port-Remap” is set for the box, then the IP-Auth trunk will fail on Outbound - after MUCH very helpful troubleshooting with the assistance of Bigleaf, we found that the SonicWALL was killing the packets because it COULDN’T remap the port.

So, long story short - I think “Disable Source Port Remap” is really only needed when you are using a BroadSoft SIP trunk and not any others - I also consider that configuration to be basically “Broken” - since Vitelity and one other I tried do not need that setting and in fact actually work better without it.

1 Like
11

I’ve been having an issue with the 6.2.71 firmware on the current TZ series of Sonicwalls. I’ve been working with Sonicwall support and seems like a bug might have been introduced in the way the SIP Header is being handled (the SIP INVITE doesn’t get routed to phone IP). This does not occur with the earlier 6.2.5.3 firmware or older Sonicwall TZ and NSA firewalls on 5.9 firmware.

Just throwing that out there.

12

We’ve seen in the past that everything will work fine, but the firewall drops the connection and subsequent reinvites are not sent to the PBX. This occurs with flowroute.com, for instance, after ~30 minutes. Can you confirm this resolves that issue? I spent months working with Sonicwall directly to resolve that, and ended with them telling us it can’t be made to work. I don’t recall the model/firmware off the top of my head but I can get it if you need.

13

In response to both of your questions, we do not have this problem at all - but like in said in the addendum - Disable Source Port Remap was only there to allow us to talk to the BroadSoft SIP Trunks and not fail on Outbound calls - Doing the VoIP Settings of “Enable Consistent NAT”, setting the outbound UDP Timeout to 300 seconds instead of 30 and finally making sure that all of your remote phones have Keep Alive turned on and all the current SonicWALL’s are rock solid. We have at least 500 remote phones spread over about a dozen systems and they are ultra reliable.

SonicWALL is good - we actually got suckered into thinking that the SonicWALL was the problem - it NEVER was the problem - we were having to accommodate a bad Trunking Provider.

14

Thanks for the post @GSnover, I recently put an install in at a location where I was not the network admin. So I showed him your findings to convince him that their old sonicwall was holding up the project with porting issues. Worked!

15

I should have mentioned that my PBX is hosted and not behind the Sonicwall. The issue is with endpoints/phones behind the Sonicwall, accessing an external instance of FreePBX. Older sonicwalls on 5.9 have no issue at all. But recent sonicwalls with 6.2.71… I can’t get working in any fashion.
I have a TZ 300 setup in a lab with just a PoE switch and 4 Mitel 6867i phones, nothing else on the network, and a Sonicwall starting in factory default.
I’ve tried the Source Port Remap (which seems to be the problem looking at the packet captures), enable consistent NAT, enable SIP transformations, extending UDP timeouts… nothing works.

16

Yes. I have found sip over TLS has solved 99% of NAT problems. It uses port 5061 by default and the contents of the packets are encrypted.

17

Specifically in this case with the Mitel phones, I bet you don’t have Keep-Alive turned on - Most phones have it turned off by default because they are deployed on the same LAN as the Server, so it’s un-necessary - but if they are remote to each other, it is VERY necessary - I have never used a Mitel phone, so I don’t know where to tell you to look, but do look for it and turn it on - We have it turned on on ALL our remote phones and that problem just goes away.

18

it’s not the phones, the same occurs on some Polycom VVX 500 phones I had laying around. Also like i mentioned, they work perfectly with no problems and no modifications out of the box on older sonicwalls, and with minimal issues on current sonicwalls with firmware 6.2.5.3 and earlier.
Something was introduced in 6.2.7.1 in the way the SIP Header information does not change and SIP Packets do not get forwarded to the endpoint, at least that is the way it appears in the packet captures. Working with Sonicwall support they have forwarded this possible bug to their software team.

On 6.2.5.3 however, there is a weird issue where after a call (inbound or outbound) completes, the phone will lose registration with the PBX, but then it gets it back after a registration retry. Still working on this to see why.

On 5.9.1.8 and earlier, perfect. No issues.

19

We have the same version on all our current active SonicWALL’s - we are not seeing it anywhere.

Greg

20

Guess I should add one more note after going back through this thread today - I am in the process of updating all my SonicWALL’s to 6.5 - all of the above still applies - and works fine - with 6.5.

1 Like