Sonicwall Firewall Checker Failure

Discussion in '3CX Phone System - General' started by jmlnet, Feb 5, 2015.

Thread Status:
Not open for further replies.
  1. jmlnet

    Joined:
    Feb 4, 2015
    Messages:
    7
    Likes Received:
    0
    We are a new paid 3cx customer and cannot get the Firewall Checker to pass. SIP vendor (Time Warner) is coming tomorrow.

    The firewall is a Sonicwall NSA 2600, firmware 6.2.2.0-12n Enhanced. While not an expert, I know Sonicwall and have been using them for years.

    We have followed 3cx's (http://www.3cx.com/blog/voip-howto/sonicwall-firewall-configuration/) guidance to the letter and double and triple checked. Our 3cx vendor says everything is set up correctly. The fix mentioned here: http://www.3cx.com/blog/voip-howto/sonicwall-important-update/ should not apply as we are on a much later firmware.

    The Firewall and NAT policies are setup per the above and the 3cx system is using the same external ip as the Sonicwall WAN interface. I tried changing the 3cx public ip (via dns) to another of our static ips but that did not work either.

    The message we receive is: No response received or port mapping is closed. However, I have confirmed that the port forward is working correctly as I am able to browse to the 3cx Server Manager on port 5000 (one of the forwarded ports) from an external computer. As all ports are in a service group (per the above guidance), if 5000 is working then the rest are working. I have also confirmed that port forwarding is working for other services (e.g. terminal services).

    The firewall on the Server Manager machine (win 8.1) is off.

    We purchased support from 3cx (in addition to support from our vendor) and 3cx support punted and said talk to the network admin (me) or to sonicwall. Not sure what Sonicwall can do as port forwarding is working ..

    Help! Please!
     
  2. JonnyM

    Joined:
    May 17, 2010
    Messages:
    77
    Likes Received:
    5
    I have an NSA 220 on 5.9.0.7 and 3CX is working perfectly. I'll have a look at the setup tomorrow and drop some screenshots in.
     
  3. gbardissi

    Joined:
    Feb 4, 2015
    Messages:
    28
    Likes Received:
    0
    Your comment about the hotfix not being need because you are on a much later version is incorrect.

    The hotfix is NOT rolled into the current Sonicwall firwmares and you do need to request the firmware with hotfix as stated.
     
  4. jmlnet

    Joined:
    Feb 4, 2015
    Messages:
    7
    Likes Received:
    0
    Any idea where to get the hotfix? Sonicwall tech support has been less than helpful.
     
  5. gbardissi

    Joined:
    Feb 4, 2015
    Messages:
    28
    Likes Received:
    0
    All you need to do is mention the hotfix number and they should provide it in the current firmware version for your model.
     
  6. cobaltit

    cobaltit Active Member

    Joined:
    Mar 22, 2012
    Messages:
    735
    Likes Received:
    113
    You didn't mention if it was Time Warner Cable or Time Warner Telecom (now L3). If TWC your SIP traffic won't be passing through the Sonicwall. They will provide an ESG that will connect to your LAN and present a local IP address for you to register against.

    http://business.timewarnercable.com/content/dam/business/pdfs/services/Config%20Guides/3CX-Phone-System-Rel-12-5-SIP-Trunk-Config-Guide-1-0.pdf

    If TW Telecom and they are delivering the SIP on a converged/shared interface then get the hotfix as gbardissi mentioned.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. jmlnet

    Joined:
    Feb 4, 2015
    Messages:
    7
    Likes Received:
    0
    Thank you for the replies! We are Time Warner Cable and thank you for that document! Sure wish TWC had given us that document as they've known what our PBX would be for months. Ugh.

    Thanks again, I may have a follow up question (or three) but think we're now on the right path.

    John
     
  8. jmlnet

    Joined:
    Feb 4, 2015
    Messages:
    7
    Likes Received:
    0
    The hotfix does not work on our Sonicwall and Sonicwall is said to be working on engineering the hotfix to our 2600. Not holding my breath.

    However, I'm not sure we need the hotfix at all because we are TWC and have the configuration set forth by cobaltit.

    TWC is coming out again on Wednesday to finally get this sorted out but I remain unclear on some of this:

    As cobaltit said, we have a second cable modem from TWC that connects to the TWC provided ESG. That ESG has a static ip address of 172.16.***.***. According to the TWC document, our PBX is to have an ip address on the same subnet. This makes sense to me as all SIP traffic goes over this ESG and not the "public internet." Where I'm confused is how does the 3cx communicate to the public internet for the mobile apps, to send email, etc. TWC says this 172.16. address is on their private network and cannot communicate with the public internet.

    Our PBX is a windows virtual machine on Hyper-V. Am I to add another vNIC on our LAN subnet that will communicate with the public internet? Am I then going through the sonicwall for some of the PBX communication? If so, does the firewall checker still apply? Do I need the hotfix for this part of the scenario?

    Thanks in advance for your help!
     
  9. tsukraw

    tsukraw New Member

    Joined:
    Mar 9, 2012
    Messages:
    190
    Likes Received:
    6
    Have you guys ever considered a SBC on your install?
    We used to run into issues all the time on 3CX installs where we did not have control of the firewall, specifically sonicwalls and getting things to work right.
    We moved to using SBC units on SIP Trunking deployments. I am not talking about 3CX "SBC" which is not a real SBC.
    Im talking about a device that has both a LAN and WAN port on it. That way audio is processed through the SBC leaving the firewall out of the picture in regards to audio from the provider. Cleared up a LOT of our install issues.

    It will also reduce load on your 3CX box. Since the SBC is a SIP Agent inside the LAN the RTP audio can be delivered betwen the SBC and the phone and not having to pass through the 3CX server.

    Just a idea. The boxes are not overly cheap but they are reasonable in my opinion.

    PM me or reply back if at all interested in the idea and i can give you more specifics. I attached a make shift drawing of how they are deployed.
     

    Attached Files:

    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. cobaltit

    cobaltit Active Member

    Joined:
    Mar 22, 2012
    Messages:
    735
    Likes Received:
    113
    Hey jmlnet,

    So first, TWC should have asked you to fill out a SIP trunk questionnaire. TWC can set that ESG to any IP you want. If you look at my Visio diagram, you will see what I'm talking about.

    Firewall is 192.168.92.1
    ESG is 192.168.92.2
    3CX Box is 192.168.92.254

    The network on the 3CX box is configured to use the firewall (Sonicwall in your case) as the default gateway. All internet traffic flows that way (email, remote phones, etc). In your SIP trunk configuration, you put the ESG IP address as the SIP server. It doesn't need to 'route' because it's on the same subnet.

    You may still need the hotfix if you are going to have remote phones, but you won't need it for your trunking with TWC.
     

    Attached Files:

    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  11. jmlnet

    Joined:
    Feb 4, 2015
    Messages:
    7
    Likes Received:
    0
    Thank you for the replies!

    Cobaltit, thanks for the explanation. I understand now. I think the only limitation will be for remote phones, any other limitations you can think of?

    Anyone have experience with how/whether remote phones work in this situation with a sonicwall and no hotfix?

    tsukraw, we have not considered an SBC and am interested. Not sure it would be worth the cost but our phone system is critical and I can't decide that until I understand better. In your drawing, the ESG is the device on the left before the LAN? Thus all normal and sip data would go through the ESG? The router/firewall and SBC connect to the internet in the same way? (remember TWC has one modem for SIP and another for normal data).

    Thank you!
     
  12. cobaltit

    cobaltit Active Member

    Joined:
    Mar 22, 2012
    Messages:
    735
    Likes Received:
    113
    Hey jmlnet,
    There is no ESG in tsukraw's drawing. That drawing is a standard view of how a SBC works. Most of benefits of a SBC are irrelevant with the TWC implementation. They are more useful in a pure internet-based SIP trunking/hosted PBX scenario. Can't speak about the Sonicwall, I don't use them. But since remote phones use the same SIP/RTP ports that a trunk would use, I imagine the setup would be the same, including the hotfix.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. captain415

    Joined:
    Mar 4, 2012
    Messages:
    9
    Likes Received:
    0
    For Sonicwall without the hotfix (Namely Disabling Source Port Remap). No remote phone will work. One work around I can think of and actually doing it myself is to use VPN. The Sonicwall VPN is pretty easy to work with, either site to site (L2TP) or client to server (SSLVPN). Both are working perfectly fine for our setup.
     
  14. mhanna2755

    Joined:
    Aug 7, 2015
    Messages:
    1
    Likes Received:
    0
    jmlnet,

    Did you ever get the hotfix from Sonicwall? I just purchased a TZ600 and have run into the same issue, an I am waiting on sonicwall to provide the hotfix for my router.

    Thanks
     
  15. Saqqara

    Saqqara Active Member

    Joined:
    Mar 12, 2014
    Messages:
    877
    Likes Received:
    135
    Just uploaded firmware 5.8.4.1-12o onto a SonicWALL TZ200 unit, and it appears that “Disable Source Part Remap” has been added now to the release versions of the firmware - no hotfix required.

    Have not tested it, with 3CX and firewall checker
     
Thread Status:
Not open for further replies.