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:
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.
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.
Set the UDP Timeout on your LAN->WAN Firewall Rule to 300 seconds - the default is 30, but that is too low.
Under VoIP, enable “Consistent NAT” and disable everything else - Asterisk takes care of it!
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.