SIP phones and Sonicwall

crp0499
crp0499 used Ask the Experts™
on
We have a yealink IP SIP phone that needs to connect from the outside.  We have set up the phone and tested it internally and it's good so we moved it externally.  

In the phone, we edited the account and put in the public IP of our router (a Sonicwall NSA4600) and waited for the phone to register.  It fails to register.

I've checked the ports and I DO have the right ports open on the Sonicwall but I've also read a lot of posts about people having trouble with SW and SIP phones.  So, after reading, I have made the changes suggested on the posts I've read and still no joy.  

I'm using https://www.yougetsignal.com/ to test 5060 and it reports that it's closed.

Does anyone have any insight into how to make the SW work well with the SIP phone?

PS:  An alternate port scanning tool tells me the port is filtered.  So, I'm looking up how to turn filtering off in the sonicwall for this service.

Thanks
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
J SpoorTME / Network Security Evangelist

Commented:
You need to enable SIP Transformations

SonciWall by default won't allow thos ekind of ports in.
Distinguished Expert 2018

Commented:
Which PBX are you using? And did you ever open any necessary ports from outside?

I've done things without SIP transformations. (There isn't a true consensus on whether to use that feature on a SW, even amongst their own engineers)
J SpoorTME / Network Security Evangelist

Commented:
SIP Transforms are needed for phones going outbound through NAT.
Otherwise, although the IP headers are changed, the private IP inside the data packets is not changed.

If this is a PBX on the LAN side that needs to be reached outside, you will need dedicated NAT policies and allow rules, ideally on a dedicated Public IP address

Createa  new service object for SIP UDP , udp 5060
NAT:
OUTBOUND if using a unique IP:
src = private IP
t src = public IP
dst = any
t dst = org
srvc = any
t srvc = original

INBOUND
src = any
t src = original
dst = Public IP
t dst = private IP

if using a unique IP set srvc = any  and t src =original
if using X1 you will need two policies
one with service SIP (TCP 5060) and one with SIP UDP (UDP 5060)

then create inbound firewall rules
from WAN to LAN
src = any
dst = Public IP
srvc = SIP TCP 5060

src = any
dst = Public IP
srvc = SIP UDP 5060
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

crp0499CEO

Author

Commented:
1.  Sonicwall docs specifically state to turn OFF SIP Transformations.
2.  I'm using a Xorcom and taking baby steps so I am trying to open 5060 from WAN to LAN and when I check, that port shows as filtered by https://www.ipfingerprints.com.  So, I can't even seem to get 5060 open from WAN to LAN.
3.  My PBX is internal, behind the Sonicwall, on a private IP.  So, I used the config wizard to listen for 5060 traffic on the public IP and send it to the private IP of the PBX.  I can't even seem to make that work as the port scan still shows me the port is filtered.
4.  The rules above were created for me when I published the PBX using the config tool.
Distinguished Expert 2018

Commented:
When you opened the port, how did you go about doing it? Via wizard or did you do it manually? (Depending how you did it, might get into the topic of NAT and/or access policies).
crp0499CEO

Author

Commented:
I used the config wizard to publish the private PBX to the internet (public IP) and to listen on UDP 5060 (plus a few other ports).
Distinguished Expert 2018

Commented:
https://www.3cx.com/docs/sonicwall-firewall-configuration/

The reason I'm posting this link is because of the hotfix firmware. While this is referencing a firmware that's out of date, you can actually contact Sonicwall support and they can put that same feature (regarding source port remap) into a newer version. It takes them a few days. May end up helping in the long run (I did this when I used to support 3CX installations)
crp0499CEO

Author

Commented:
ok, I'll get on this tonight and see what I can work out.  Lots of docs out there about SW and SIP not playing nice together.  This looks promising.  I'll let you know.

Thank you!
Distinguished Expert 2018

Commented:
The firmware was more in the sense of things that apply to call issues which have come up at times.

In terms of the actual port opening on the Sonicwall.... have you looked through the logs to see whether traffic was actually making it through port 5060? (BTW - Did you do UDP, TCP, or both?)
crp0499CEO

Author

Commented:
At first, I just did UDP, but I have sine added both.  I have not looked at the logs YET!  That's primarily because it seemed so simple...open port 5060 and register the phone.  It's turning into a nightmare.  I even went to far as to swap out the SW with a Xyzel 1100 and whipped up the rule and it worked perfectly with only about ten mins of config time.  I did this late one night just to see if all the bad press about SW and SIP were legit.  Swapping out permanently isn't an option, I was just testing and it really was that simple.  Now to make that work with the SW.

PS:  My port scanning tells me the 5060 port is filtered, which is defined as being blocked by a firewall, versus closed.
Distinguished Expert 2018

Commented:
Might help if we're able to see some of the rules, namely the access rules. (Obviously, blur out the sensitive information in any screenshots you choose to post)
crp0499CEO

Author

Commented:
SW1 is the access rule.  The SIP Services referenced in there consists of what's in SW2.
SW1.png
SW2.png
Distinguished Expert 2018

Commented:
Interesting. How about the NAT policy involving the PBX?
crp0499CEO

Author

Commented:
Attached as NAT1, NAT2, NAT3
NAT1.png
NAT2.png
NAT3.png
Distinguished Expert 2017

Commented:
Does the connection go over a VPN, LAN side ip overlap as possible explanation?
crp0499CEO

Author

Commented:
we could NOT get this to work, even had sonicwall support in the phone and they couldn’t get the ports forwarded. we ended up doing a P2P vpn and the phones are working as expected.
Distinguished Expert 2018

Commented:
Wait a sec, Sonicwall support couldn't even get the port forwarded? That is very disturbing. What was their explanation?
crp0499CEO

Author

Commented:
that’s right. sonicwall support has no explanation as to why it wouldn’t work. their fix was to factory reset the device and try to build the port forward. that wasn’t an option. we did however do a backup, reset to factory defaults and a restore, but that didn’t work either. they wanted to do factory reset and rebuild one rule at a time and that wasn’t an option. so we set up a p2p IPSecVPN and that worked for us.
Distinguished Expert 2018
Commented:
sonicwall support has no explanation as to why it wouldn’t work.
My bet would be on conflicting/unneeded rules/policies that exist on there.

we did however do a backup, reset to factory defaults and a restore, but that didn’t work either.
Backups are good. I don't know about the complexity of the rules in place, but in instances like this, I would recommend a factory reset, firmware upgrade, then creating all of the rules fresh. I know it's a pain, but sometimes starting fresh gets rid of all of the unneeded trash. I saw Sonicwall suggested it, and it's not always a feasible option. However, I would suggest that you take the time out one day to actually inspect all of the rules that already exist. You may find some surprises.
crp0499CEO

Author

Commented:
That's what SW wanted.  Our firmware was already current.  I didn't mind a BU/restore, but a wipe and rebuild was simply not an option.  I wasn't going to do it.  The work around with the P2P VPN worked and seemed better to me since I wouldn't have to open the ports to allow the SIP traffic in.  What astounds me is that SW devices have so much trouble with what I'm sure is a common task.  Allowing SIP IP phones access to an internal PBX by opening ports would strike me as something a great many companies would want to do.  The fact that the product doesn't support that, or that supporting it requires such a tremendous amount of effort really left it's mark on my opinion of the SW product.
Distinguished Expert 2018
Commented:
Allowing SIP IP phones access to an internal PBX by opening ports would strike me as something a great many companies would want to do.  The fact that the product doesn't support that, or that supporting it requires such a tremendous amount of effort really left it's mark on my opinion of the SW product.
I think some of my edits to my last comment weren't up in time for your response. While I do find it surprising, I'm also going to bet on your rules needing to be audited. Opening ports on SW devices isn't hard at all, even if their VoIP features are suspect.
crp0499CEO

Author

Commented:
agreed. I like their product, and this was my first “failure” trying to make something happen, AND, this is a five year old device. the rules are a plenty and it’s messy in there. I don’t doubt the problem lies in that messiness.  if I had done a wipe and rebuild, I think I would have been fine and had a better, cleaner set of rules, but I’m lazy that way. 😊
Distinguished Expert 2018

Commented:
Haha good one. At least you're honest.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial