Solved Firewall Configuration with Sonicwall & Port 5060 SIP Provider

Status
Not open for further replies.

Mike Big

Customer
Joined
Aug 3, 2018
Messages
10
Reaction score
5
I have a confusing issue regarding Ports with 3CX and SIP trunk using a Dell Sonicwall -
It is well documented that the following standard firewall ports are required -

Port 5061 TCP only - Used for SIP TLS - not required for my system
Port 9000 - 9500 UDP only (some same 10999) - Used for RTP & WebRTC - essential my system
Port 5090 TCP & UDP - Used as a secure tunnel for 3CX apps from WAN - essential for my system
Port 5060 TCP & UDP - Used for the main signalling ports for the call - essential for our system
Port 5001 - Used for remote WAN management of the Web Interface - not required for my system (LAN admin only)

As it is said, these are the basic requirements and in reality, for testing, I have opened only 9000-9500, 5060 and 5090 - all directed in my Dell Sonicwall (through NAT & Access rules) at the 3CX Linux Server on the LAN at 192.168.1.98

All worked well in testing and then I selected my preferred SIP provider in the UK who instructed me the following -

"Please find the SIP endpoint information below along with the DID range. Please be aware that SIP ports 5060 UDP will need to be opened to the 88.215.58.15 & 88.215.58.16. You will also need to open TCP/UDP 6000 to 40000 to this same IP address."

So I modified the NAT policies and Access rules in the Sonicwall as follows:

Port 5090 accepts incoming from any WAN IP address and forwards to 192.168.1.98
Port 5060 only accepts incoming from WAN IP's 88.215.58.15 & 88.215.58.16 and forward to 192.168.1.98
Port Range 6000 to 40000 (i expanded the original 9000-9500) only accepts incoming from WAN IP's 88.215.58.15 & 88.215.58.16 and forward to 192.168.1.98

The internal system and SIP trunks are working fine but now the 3CX and other mobile phone apps working over 4G or WAN cannot connect or make calls. They show as disconnected.

The question I have is regarding the 3CX dedicated mobile App and Windows App use of Port 5090 as a secure tunnel. Is this 5090 for the signalling only or including the Audio as well down the tunnel? If the app needs to use other ports apart from 5090 then how is this going to work when the 5060 and the range 6000 to 40000 only receive incoming for these two approved WAN IP's?

The second question is that the external WAN 3CX apps on both PC and Mobile do not show the extension list with the usual Green Busy lamp ans the call log is also not saving for redial. Is this a setting I am missing in the extension settings or is this needing one of the other ports opening in the firewall?
 
Last edited:
Sigh.. where to begin... So it was working with the 3CX recommended settings and then you changed it to what your provider said to use. Now you are coming to the 3CX forums to ask why it's not working?

The link below will explain the ports and what they are for.

https://www.3cx.com/ports-used-3cx-phone-system-v14-v15/
 
Last edited:
I appreciate the response and also the sigh, since Port Forwarding has been done to death but my question is different - I was asking whether the 3CX client for mobile and windows clients in the WAN/4G, which are automatically configured to use the 5090 Secure Tunnel if not in the LAN, use only 5090. Does both the SIP signalling and also the SIP audio travel down the tunnel i.e. we need only open 5090 or does it then send the audio via the usual port range e.g.9000-9500?

I agree it is unusual for the SIP trunk provider to ask for Ports 6,000 to 40,000 open when the 3CX only uses a smaller range. Talking of which is the latest requirements 9,000 to 9,500 or 9,000-10,999. I see both referred to?
 
  • Like
Reactions: hung1
The mobile clients only use 5090 tcp and udp and 5001 tcp (3CX management https). However if you haven’t checked the extensions under provisioning for the 3cxphone to use tunnel that would cause them to try and talk over 5060 and the udp ports which are now locked down.
 
Thanks Centrex J. That is the perfect answer I needed and borne out by my testing. All of the manuals are unclear about this. They mention opening in the firewall, port 5060 for the SIP signalling (this can be safely locked inbound to the specific IP address of any SIP trunk provider) and 5090 for remote secure tunnelling by the 3CX mobile and Windows apps which detect they are outside the LAN (where they use 5060) and they switch to 5090. Both mobile and Windows apps can make/receive calls without port 5001 open however the android app flicks continuously between connected and disconnected and cannot display the phone logs or Busy Lamps. The windows app stays connected fine but has no call history. To resolve this your must have port 5001 open (or its possible to use 443) and all apps function as expected whilst in WAN. In summary i would suggest the following for best results :
Ports 5060 & 9000-10999 - open but locked to a SIP trunk providers IP address
Ports 5090 & 5001 - open to any WAN address
The disadvantage of this more secure lockdown is that third party SIP apps cannot be used as they normally use 5060 and are not capable of using the secure tunnel protocols of the 3CX port 5090. You are therefore tied to the 3CX app - unless someone can suggest another app that can use the 5090 tunnel?
The other thing which really requires setup for the Android apps (and is not routinely described on the android setup guide) is Google Firebase. This is nicely detailed in a separate 3CX guide and has a significant benefit on battery life using Android push. I would like to see a link on the 3CX android main setup page to the Android Push/Firebase instructions.
 
@Mike Cheetham
Is this Google Firebase setup required for all android devices? I use the android client on my mobile phone, and it works (although very poorly). What is Google Firebase for? I have read a bit about it, but I'm still not understanding it. And @YiannisH_3CX mentioned on another post that 3CX already has this built in and you don't need to configure Google Firebase unless you have your "own project". What is your opinion?
 
The Google Firebase now seems to have replaced the Google API Cloud Messaging server as the preferred push notification channel for the 3CX app on Android. BY default, the 3CX server software already has a Firebase push account setup in it using 3CX's own Firebase account. Basically it sends a wakeup to the Android app and bring it alive from the background. This allows battery to be conserved. I don't know why (perhaps the single 3CX Firebase account is overloaded), but I found that the Android App is much more reliably now that I have created my own Firebase Project. It is easy to do if you follow the guide.

The old guide for configuring Push via Google API is here - https://www.3cx.com/docs/ . This is supported in older 3CX versions (up to v15) and apps.

However I used the latest recommendation using Firebase and the latest 3CX server (v15.5) and apps - https://www.3cx.com/docs/.

Once completed, you also need to post the two codes from Firebase back into the 3CX Server on the Cloud Messaging Page and most importantly, send out new Welcome Emails with the updated config provisioning. On each Android device you need to re-provision with the config file so that the app uses the private Firebase push rather than the generic 3CX one.

I found my androids apps performed near flawlessly once I had updated all and am using my private Firebase push now, without issue.
 
Mike_big
Yes to locking 5060 inbound to your sip provider. No to locking 9000 to 10999 or whatever rtp media ports your sip provider uses. If you lock down your media ports you may find calling to locations using a different sip provider may have no sound. Locking down the media ports also don’t provide more security. All calls have to establish through port 5060 anyway.
 
Thanks @Mike Big

With the Android app - why does it re-register every time I switch to the app? Doesn't it run in the background? It has to make a connection to the server every time I switch to another app. If I'm in the 3CX app and it has registered, then I switch to something else for a few minutes, then switch back to the 3CX app again - it actually shows that it's trying to register for about 5 - 10 seconds, then it comes online with the presence, etc. And it has to wait to download the call history EVERY time. Doesn't it have a memory whatsoever? Will any of this improve by doing the Firebase thing?
 
Peter the entire purpose of push is so that the android and iPhone app don’t have to run in the background wasting data and battery. When a call comes in push wakes the app in time to grab the call. When you need to dial out open the app and make your call.
 
Peter, as detailed, you can quite happily either use the default 3CX Firebase project which is built into the 3CX standard settings or else you can create your own, as explained in my above link. As @CentrexJ explains all it does is wake the Android app up from the background if there is an incoming message or call. Android phones are configured to listen to the Google Cloud for push notifications of many kinds. I think the push wake up sequence refreshes the same whether its using the 3CX project or your own creation. I have tested mine with both versions and it doesn't take 5-10 seconds, it is instant. What is your phone model and mobile connection speed. I have tried with S6, S8 & S9 with 3G & 4G and its instant.The reason I chose a private Firebase was because about 1 in 20 inbound calls, the 3CX app was not waking. Since creating my own push, it hasn't missed a beat...that I know of. Can i suggest you try a private project - but don't forget to send out new provisioning emails and reload on each phone so it carries the new incoming push config criteria.
 
I have a HTC U Ultra, HTC's latest flagship phone. Okay I'll try the firebase and see how that goes. But the removing of call history and waiting for it to go registered until I can view the call history, will this be fixed? Seems like a massive bug. The call history should not require a connection to the PBX, it should stay there at all times. The connection to the PBX should be something that happens in the background while I navigate the app.
 
Peter, if you are using your HTC outside of the LAN, over 3G/4G or wifi, then, providing that you have ticked the box (it is ticked on both by default) on the 3CX server and Android App, then it will revert to Port 5090 and use the 3CX secure tunnel. So this has to be opened as a minimum. The guides seem to imply that everything goes down this 5090 tunnel - signalling and voice but that is not the case. If you only open this one port for the 3CX Windows & mobiles app (obviously 5060 and 9000-10999 need opening for the SIP trunking) then the Windows app will connect & show 'On Hook' but will not show the call history or BLF. The Android app flicks constantly between connected and disconnected and shows no call history or BLF. It seems that this missing communication takes place over Port 5001. I tested it extensively, one port at a time, UDP, TCP, both. For the Android and Windows apps to work correctly in the WAN you need both Ports 5090 & 5001 open. Everything fires up perfectly with these two open. The guides suggest that you can use Port 443 as an alternative. I could not get this working because so many routers and servers use 443 for inbound and outbound SSL connections. My CCTV, Firewall SSL Admin and two other devices all want 443 pointing at them. I therefore resorted to 5001.Why they haven't sent everything down 5090, I am not sure. It does seems strange to have this final data travelling outside of the tunnel. The Firebase personal project is entirely optional. It was not necessary to resolve the other issues that Port 5001 solved. It just allowed the Android app to wake up from the background on every single call. Using the default 3CX Firebase Push, that is default in the server and provisioning for the app, worked well although sometimes it failed to ring (twice in 50 calls) on my android. That has not happened since i installed my own Firebase. Perhaps the generic 3CX Firebase push is at times, overloaded? Hope that helps.
 
But the removing of call history and waiting for it to go registered until I can view the call history, will this be fixed? Seems like a massive bug. The call history should not require a connection to the PBX, it should stay there at all times. The connection to the PBX should be something that happens in the background while I navigate the app.
Please note that call history relies on presence so when the client starts it needs to establish presence connection to the server before call history is displayed. This is the default behaviour of the client so i would recommend creating feature request on our ideas section of the forum if you would like that changed.
 
The guides suggest that you can use Port 443 as an alternative. I could not get this working because so many routers and servers use 443 for inbound and outbound SSL connections. My CCTV, Firewall SSL Admin and two other devices all want 443 pointing at them. I therefore resorted to 5001
The PBX will use the https port you selected during the installation. If you used port 5001 then you need to open port 5001. If you used 443 then you need to open port 443.
If you used port 5001 then port 443 will not work.
 
Agreed. I changed the config in the test server during installation to both 443 and 5001 for testing. I am sure 443 works perfectly well but so many other devices use 443 for SSL inbound communications that I had to give my CCTV system priority since this could nto be altered. Our Dell Sonicwall also has 443 enabled by default for SSL firewall management although this can be disabled or changed. I was just pointing out that I could not get 443 working due to other devices demanding that Port. All is good now. I will try to suggest that 5090 carry all communications and management so that presence can be held active. Thanks again
 
Glad to see that everything is working ok now.
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,891
Messages
589,585
Members
164,756
Latest member
maurin.roffler