Happiness With Sonicwalls - It can happen!


(Raphael Waller) #21

Interesting findings there. I have several FreePBX instances and all behind Sonicwalls.
All of mine phones are either on the LAN, or are not NAT with a site to site VPN.

We have always set up using Public Server Wizard and left those NAT rules as default, allowing ports 5060-5061, as well as the RTP ranges requested from ITSP and locking it down to only allow from their IP’s
Only recently had an instance where needed to increase UDP timeout, because calls got dropped after exactly 30 minutes.


(Greg Snover) #22

Yeah, the UDP timeout is primarily for long calls - restricting the Source IP’s is great if you don’t have phones in the wild (changing) - if you do, you cant.


(Jade Medenilla) #23

Hi, I’ve been configuring this for almost a month but still no luck. Heres the setup 2routers site to site VPN and FreePBX behind each Sonicwall. Both routers have no issues regarding on the connection from each site, I also created port forwarding both routers for 5060 UDP/TCP including access rules and NAT policy. But still peer SIP trunk still unreachable, I was able to ping both PBX from each site. Please advise, thanks.


(Greg Snover) #24

Doesn’t sound like a SonicWALL problem to me - it sounds like your Peer SIP Trunk is not correct - post both sides here and let’s have a look!

Greg


(Idacomp) #25

Greg,

I’ve followed your info here to a T, but seem to still be having an issue. We have several PBX systems behind a TZ400. The problem we’re experiencing is a long delay when making outbound calls. Our provider is Twilio.

When placing a call, it appears that the trunk will timeout and then re-transmit, and timeout and re-transmit. Sometimes taking up to 45 seconds before the call finally progresses to ringing.

But it’s intermittent. Sometimes you can place several calls in a row that they connect within 2 seconds.

These are all remote phones and the particular case we’re fighting, those remote phones are also behind a SonicWALL (TZ300).

We never experienced this until we put the PBX behind the firewall - so it’s got to be that. I just cannot figure out for the life of me what’s going on.

Any suggestions would be greatly appreciated.

Thanks,

Brett


(Idacomp) #26

Update - changing outbound calls to a different trunk provider (flowroute), the calls connect immediately with no changes to the firewall(s). It appears as though part of the issue is with Twilio.


(Greg Snover) #27

That was my assumption - for anybody else deploying/testing boxes, you should ALWAYS have a second provider available - even if it is just one of your own boxes - so you can test a box outside of the provider you are having problems with - it saves a lot of running in circles - Glad you found it.


(Idacomp) #28

UPDATE:

After further testing, I think I found the issue with regards to Twilio. Under Settings -> Asterisk SIP Settings -> NAT Settings.

When behind the firewall and you let the system detect the network settings, it puts the public address correctly within the ‘External Address’ field, and it also correctly identifies the ‘Local Networks’ that includes the private address of the PBX behind the firewall.

It appears however, that with regard to Twilio, the ‘Local Networks’ field needs to be the network that includes the public IP.

Once I made that change, I haven’t been able to duplicate the problem.

Will continue to test next week and confirm - will leave an update whether I can confirm the finding.


(Greg Snover) #29

That is actually something I found with several providers (Vitelity, BluIP, CoreDial) - it seems a little counter-intuitive, but under the trunks you set (in the definition) nat=no and the remote side seems much happier. Even though the PBX is behind a NAT router.

Live and Learn…


(Edrick Smith) #30

I’m running a FreePBX with a Sonicwall TZ300 the phones are also local inside the same network as the Sonicwall. I’m using VOIP Street for my trunk provider.

Outbound calling is working fine, inbound calling works only for a short period after an outbound call. After that it doesn’t even hit the FreePBX box. I’ve enabled sip debugging and watching and there’s no activity coming in from the call. It just rings and rings until VoipStreet gives a busy signal.

I’ve created 2 rules with the auto wizard
SIP UDP, RTP

I’ve modified SIP UDP to be 300 instead of 30 and checked the VOIP settings in step 4.

Any ideas?

I’ve verified this is definitely an issue with the Sonicwall side of things, I connected the freepbx directly to the modem and assigned it its own static IP with the same configuration all that changed was that its now directly connected to the internet vs. going through the Sonicwall.


(Itzik) #31

Can you show us your Sonicwall Voip settings? I don’t remember off hand under which section it is, but I assume under network.

Btw, as a side note. I would create a Service Group that has SIP and RTP in it, and use that service group for the LAN to WAN and NAT rule, instead of having multiple rules…
Also, set VoipStreet’s IP or FQDN as a object under address objects and set in the WAN to LAN rule the source to that object, this way you only allow SIP and RTP from their servers.


(Edrick Smith) #32

Here are the VoIP Settings


#33

You may want to go into your NAT Policies for your PBX.

At the very least on the outbound NAT policy, edit and go into Advanced and check the “Disable Source Port Remap” option. This tells the sonicwall to not rewrite the outbound source port, which may confuse some voip providers on which port to send inbound SIP traffic to. Combining this with increasing your UDP timeout should keep the SIP ports open and on 5060

You MAY need to do this on your inbound NAT policy for the PBX as well, but usually just outbound will work fine.


(David Johnson) #34

Have been working on this for 7 hours, playing with the sonicwall rules and wizard, banging my head on the wall wondering why its not working!!! SAW YOUR POST AND IN 5 MINUTES…WORKING! The 4th NAT rule was the issue!!! I took a chance and guess that your PBX-BDC Public is actually the public IP of the sonicwall and it worked!

THANK YOU!!!


(Greg Snover) #35

You are very welcome - I love my SonicWALL’s, but they are a little “Opaque” at times - Glad it helped!

Greg


(United States) #36

Hi Greg we have a PBX system in NY behind a plain jane router the call center is in florida behind a sonicwall and were having lots of problem. when i do the port forwading as you stated which ip address am i forwarding to


(Greg Snover) #37

Phones behind the SonicWALL with the PBX behind a different (non-SonicWALL) require no settings or forwarding on the SonicWALL Side - It will let them through just fine.

If your setup is Phones -> SonicWALL -> Internet -> PBXFirewall -> PBX then you need rules to forward SIP/PJSIP (Whichever you are using) and RTP through the PBXFirewall so the remote phones can connect.


(Lorne Gaetz) #38

@GSnover

Hardly a week goes by that I (or a colleague) don’t send someone to this thread. You should be racking up lots of IT Karma™ from fellow Sonicwall disciples.


(Greg Snover) #39

Thanks - I am tempted to re-do it because one of the key things I was doing (Disable Source-Port Remap) was only for a specific ITSP - I mention it in the thread, but I am afraid that the thread has gotten so long that a casual visitor might miss that it’s not necessary for most setups.

We fought against/threw away SonicWALL’s for so long before we bit the bullet and learned how to use them - now the Internet is so dangerous that I would never use anything but a smart firewall with active updates for threats. Without smart firewalls, you are a sitting duck.


(Lorne Gaetz) #40

If When you do, please submit it to the Community Doc project described here: FreePBX Community Documentation

The idea is to move highly informative docs like this to a central repository.