This has been an awesome solution for our school, but we have one issue. Our pbx server is on it’s own public IP. Our phones are behind a sonicwall firewall. The phones inside the firewall authenticate to the server just fine. All phones outside of the firewall such as my home network authenticate.
Phones outside of the sonicwall firewall can make calls both ways
Phones inside of the sonicwall firewall cannot make calls to each other
Phones outside of the sonicwall firewall cannot make calls to phones inside firewall.
Phones inside of the sonicwall fireall can make call calls to phones outside firewall.
Everything points to a firewall issue, but I wanted to see if anyone else face and conquered this issue.
It’s a firewall issue or the PBX is not configured correctly. If it’s on a different public IP than the outbound NAT policy your externip variable would not be discovered properly.
Make sure you have all sip transforms turned off in Sonicwall and symetric NAT enabled.
Sonicwalls are awful for SIP, must of us won’t work on them. Use the VPN feature of the Sonicwall.
Lastly, if you have PBX exposed to Internet make sure you are only allowing the networks of trusted folks. You don’t want a school to get hacked.
If your school is in US please look in our application store. The Page Pro module was specifically designed to meet K-12 emergency alerting requirements.
I can’t tell you how to configure your specific system. As you said you have multiple external addresses, I have no idea how you are sourcing the NAT and these types of configs can get tricky.
You are also using the most unforgiving and trickiest firewall to get working with SIP.
Doesn’t sound like you are a network expert either so I hate to be the bearer of bad news, you may be way over your head.
Have you thought of bringing a consultant in?
One other idea, if you have those 8 IP’s you could put a public IP on one of the interfaces on your server and run a software firewall such as APF.
Ok thanks. So how do I configure the outbound NAT policy and exernip on the PBX? The interesting thiing is that I keep seeing that I need to turn off sip transformations but when I turn it off., then I can’t even call out from inside the sonicwall like I’m able to now. I’ll double check this fact tomorrow,but I’m very certain that with sip transformation turned off, it kills everything. The PBX is being use for basically internal calls only between classrooms and isn’t tied to a trunk for regular pstn phone calls. It is also on its own ip. We have 8 ip add allocated on our T1 available. Phones that are t behind the sonicwalls such as at home are able to make calls to each other
I wrote this up after having issues with a Sonicwall to remind myself later- it may get you part of the way there:
[quote]So after much consternation and testing, it turns out there are two issues at play when configuring a Sonicwall unit to play nicely with Asterisk SIP registration. First, the simple one: Consistent NAT needs to be turned on, otherwise the SIP registration that is supposed to happen on UDP port 5060 get shifted/randomized by the Sonicwall, but the server at the other end will inevitably have issues. Turning Consistent NAT on will make sure everything stays on port 5060.
The second issue is a little trickier, and because its only in troubleshooting that it shows up, it’s likely a bit more tricky to track down: the UDP timeout on the Sonicwall is 30 seconds, and that is too short for the needs here. Asterisk has a default timeout of 60, but to be safe I set the UDP timeout to 120. This could either be done beforehand in the Firewall Settings general area (which would affect all future created rules, but is not linked so can be changed later), or for the specific rule itself, under the Advanced tab.[/quote]
That make sure you have those things settled first. And yes, SW is a pain to get working because you can’t get any useful support from them (or at least couldn’t-I haven’t needed to since they got purchased by Dell).
I’m not a firewall guy. I’m coming from an environment where we didn’t use firewalls, but hardware encryption. All traffic was encrypted and point to point. I’m also learning this PBX software as I go.
With that said, I’m looking for any help with anything that I’m missing whether it be in the PBX server or in my firewall.
The issue I’m facing is very consistent with no calls being allowed to come in from the outside and calls between phones outside of the network working great.
Unfortunately, I’m also a one man shop with an assistant who has zero network knowledge. Can i email you a block diagram of my network setup?
Thanks for the help and sharing of information regarding issues that you’ve face as well as your willingness to help strengthen the base users’ knowledge. I know what you mean with Sonicwall support. I’m hoping to call back and get a more knowledable person. We have the 24/7 support agreement which helps a lot.
So I accept the fact that I have a sonicwall which apparently is the most unforgiving firewall for SIP Or VoIP. Well I enabled sip transformations, and allow non sip packets blah blah. I also added an access rule to allow rtp ports 10000-20000 and 5060-5062 for sip on the WAN > LAN
After doing that a was able to make a few calls into my desktop that has XLITE installed. But after about 5 test calls, I was no longer able to make anymore calls. The initiating computer running XLITE appeared to be dialing but my desktop at work never picked up.
When I looked at the statistics of the access rule that I crated, I can see traffic being passed.
Any thoughts?
Thoughts, honestly sure I do. You can run wireshark and both ends and see how the Sonicwall is mutilating the SIP packets.
This this is the pr**k tease of firewalls. Just when you think you found the formula the translation table gets hosed or the firewall makes a decision that confounds Asterisk. When you have NAT traversal (called NAT-T) enabled at both ends you have two devices with no state information being passed making changes based on assumptions to the payload of the SIP messages.
How much is your time worth? The sonic wall has no value. Grab $200 and run (don’t walk) over to Flea-Bay and pick yourself up a Juniper SSG 5 or a Cisco PIX 515. You will never regret it. Sell the Sonicwall to the another sucker.
I want to reiterate I do not know of a single soul running SIP behind a Sonicwall having a positive experience.
About the only thing worse is Barracuda, great marketing lousy product. There is reason you never see this stuff in Enterprise deployments. We have a regional supermarket chain that drank the sonic wall Kool-Aid. It was all ripped out in less than a year.
You could also go Open Source with PF Sense or Untangle. They both work well.
This has been a nice lesson to say the least. I’m glad that you guys told me that SW are not so friendly because that explains a lot. I’ll see what I can accomplish with our “premium” tech support that we purchased. If I can’t get them working end to end I might just ditch that plan and just go with the plan to make as intercom only phones between classrooms on the same LAN. I also found the external and nat setting in the sip.conf file. Thanks.
I work with firewalls, though not Sonicwall, and I usually put the PBX onto a DMZ and then use VPN tunnels to provide the access (restricting traffic to just SIP/RTP).
If this is a possibility for you, you should find it works OK.
I had the exact same problems with the Sonic Wall. I was working with the TZ100. What I had to do sounds pretty ridiculous to me but it worked. I had to make the same rule for inbound AND outbound.
For example
allow from WAN to LAN UDP on port 5060
allow from LAN to WAN UDP on port 5060
do the same for the RTP ports. Get the idea? Let me know if it works for you.
So, a buddy and I put our heads together and came up with the likely solution to our issue. We were looking at the extension settings and noticed that they were all set to NAT: NO RFC3581. We changed it to YES and it opened the floodgates! All phones register and are able to call eachother without any issues. SO here is the fix action for my issue in case anyone comes across it that it might help.
Opened a LAN> WAN access rule on Sonicwall for RTP, SIP, and HTTP ports
Opened a WAN> LAN access rule on Sonicwall for RTP, SIP, and HTTP ports
Disabled SIP Transformations
Changed NAT setting for each extension to YES and left all other settings as default. This system is used for an internal intercom system only, it is not tied to external telephone trunks
I have a host of issues with different softphones and hardphones (SNOM) behind a SSG 140 trying to access the internet.
At the moment I’ve given up on that and have basically created a MIP rule for an internal freepbx server with external(via internet) and internal (LAN prior to SSG) clients.
I get incoming calls to external sip clients but it generally hangs up or I get no sound/voice.
I would love to be able to assign one of my public /27 IPs directly to this freebpx box rather than using MIP…
I do have quite a few issues to deal with at the moment with SIP transversing the SSG-140, but I thought surely the MIP rule would work!!!
We regularly use Sonicwall with DATA system - they are actually very good - Just don’t use the internal VoIP NAT Translations. I dislike that they are constantly getting a bad name.
To configure a FreePBX machine behind a Sonicwall where the system is on the LAN side (recommended)
Set the private IP on the FreePBX server to a static IP (as usual)
Using the SIP module in FreePBX - set the “ExternIP” settings to the External (public) IP assigned to be NATed to the the FreePBX machine. Enter all the local networks where asked
Turn off any NAT-Related settings in the “VoIP” Section of the Sonicwall admin
Use the “Public Server Wizard” to set up public access via SIP (UDP 5060) and RTP (UDP 10000-20000) - This will take care of the proper firewall settings (rules & natting) all at once, quickly and simply.
Viola…No NAT issues.
The reason that there are problems using the built-in SIP translation is that the Sonicwall is actually a bit too smart for its own good when doing deep packet inspection for SIP. Asterisk does a better job of inserting the NAT headers than a firewall (not to mention the overhead required on the firewall).
For a “public” server (which I don’t recommend any server have a public interface) - just assign the public IP to the server. Make sure the extensions are defined with NAT=YES. Turn of SIP translations, and no additional firewall rules are needed since the default rules will allow outbound SIP registrations and inbound RTP relating to a SIP connection.
Good luck and feel free to PM me if there are any further issues with sonicwalls and your PBX
Repost here if you still have any
We regularly use Sonicwall with DATA system - they are actually very good - Just don’t use the internal VoIP NAT Translations. I dislike that they are constantly getting a bad name.
To configure a FreePBX machine behind a Sonicwall where the system is on the LAN side (recommended)
Set the private IP on the FreePBX server to a static IP (as usual)
Using the SIP module in FreePBX - set the “ExternIP” settings to the External (public) IP assigned to be NATed to the the FreePBX machine. Enter all the local networks where asked
Turn off any NAT-Related settings in the “VoIP” Section of the Sonicwall admin
Use the “Public Server Wizard” to set up public access via SIP (UDP 5060) and RTP (UDP 10000-20000) - This will take care of the proper firewall settings (rules & natting) all at once, quickly and simply.
Viola…No NAT issues.
The reason that there are problems using the built-in SIP translation is that the Sonicwall is actually a bit too smart for its own good when doing deep packet inspection for SIP. Asterisk does a better job of inserting the NAT headers than a firewall (not to mention the overhead required on the firewall).
For a “public” server (which I don’t recommend any server have a public interface) - just assign the public IP to the server. Make sure the extensions are defined with NAT=YES. Turn of SIP translations, and no additional firewall rules are needed since the default rules will allow outbound SIP registrations and inbound RTP relating to a SIP connection.
Good luck and feel free to PM me if there are any further issues with sonicwalls and your PBX
Repost here if you still have any