Course Content - Basic
Configuring the Firewall (Server Side)
Welcome to the online training series from 3CX. In this module, we’ll be explaining what configuration your firewall will require.
Specifically what we are going to be covering are the concepts of NAT and Port preservation, what SIP ALG is and how it works.
Moving forward we will be talking about what firewall configuration is required in order for VoIP Providers to work properly, what Remote Extensions require depending on if they are 3CX Clients or IP Phones, as well as other 3CX PBXs connected via bridges.
Generally, everything you need to know on this topic depending on your use case.
Finally, we will be showing you how you can validate if the configuration has been done correctly, or not.
As you all probably know, and hope, by default, Firewalls block all incoming traffic from the Internet.
This, however, would not allow the 3CX Server to have a proper two-way communication with external entities such as VoIP Providers and Remote Extensions.
For this reason, some configuration is required so that the Firewall allows all the necessary internet traffic to reach the 3CX Server from the outside.
In order to fully understand this module, fundamental knowledge of networks and routing is required, however we will try to explain things in the simplest way possible.
If you want to try this out, you will need to have a configurable firewall.
Throughout this module we are going to be talking about the general configuration that needs to be done, but we are not going to go into vendor-specific settings. For this reason, you must know how to perform these settings on the hardware you are using. For the same reason, no one from the 3CX staff will ever attempt to configure your firewall for you.
We do have some sample configuration guides available as a reference, for some of the more popular Firewalls on the market which you can find from our website at the link shown on screen now.
One of the most important features of a Firewall, which we are going to be talking about, is NAT, or Network Address Translation. This is the way the firewall knows which traffic to allow through, from the outside, into the network.
This is required so that external entities like your SIP Trunks, 3CX Clients, IP Phones, SBCs and Bridges, can communicate with your 3CX Server from outside your Local LAN.
NAT can also be used to set specific rules so that you can limit who can access the 3CX Server through what is called an ACL, or Access Control List.
IPv6 is supported in 3CX, but IPv6 masquerading is not supported. You will need to create IPv6 firewall rules for all the traffic to and from the PBX, just like in IPv4, if IPv6 is being used. The ports will remain the same as in IPv4
One more feature a Firewall must have, is to be able to support Full Cone NAT.
This allows entities unknown to the Firewall to be able to contact the 3CX Server. This is especially important for VoIP Providers, as most of the times, they will try to contact your server from a large range of IPs and not just one.
This is also important for remote extensions as the users may not have a static IP at home or if they are connecting on the go.
Another important characteristic a Firewall must have, is Port Preservation. What this means is that when an internal entity sends a packet through the firewall, the Firewall must allow this through WITHOUT changing the source port.
Although this may sound like an obvious thing, a lot of Firewall have features like “Source Port Remap” which does exactly this, purposely change the Source IP Port.
This is usually not a problem for other protocols, but SIP and SDP are kind of unique in this sense. To get a bit more technical on this, a lot of other protocols rely on the source port that is found in the Transport Header, so if this is changed by the firewall that is OK. SIP on the other hand also has port information inside the actual payload, and this port information must match that found in the Transport Header. If they do not match, there is a high probability that there will be connectivity issues.
SIP ALG is one more feature a lot of Firewalls have.
What it does is try to look inside the SIP packets and alter the information. Although the intention of SIP ALG is good and it tries to solve some connectivity issues, our experience has shown that unfortunately not all implementations of it work reliably.
For this reason, we recommend disabling it.
Doing this can sometimes be a bit tricky and there is no consistent pattern to how this is done, and does vary from one Firewall vendor to another. If you are unsure how this feature is disabled, it is best to either contact the firewall manufacturer or look it up, in the online documentation they may provide.
Now we will talk a bit more specifically about exactly which NAT ports need to be opened depending on what External VoIP traffic you are going to be utilizing.
Most of the ports we will mention in this module, as well as other modules, can be changed during the installation process. We will always be mentioning the default ports in this case. If you change any of the ports during the installation phase, you will need to modify and perform the necessary port forwarding to reflect this.
SIP trunks are used in most of the deployments these days, so we will start with this. To use SIP Trunks you must open, and forward the SIP port of the PBX. This, by default is port 5060 for both TCP and UDP traffic, although this can be changed during the installation phase.
This will allow the SIP signaling from your Provider to reach 3CX. SIP Signaling, however, does not contain the actual audio. Audio uses a different Protocol called RTP, or Real-time Transport Protocol, which uses a different port range. This means that you must also open this port range for UDP traffic. This range is set from 9000 to 10999, and cannot be changed.
If you intend on having remote users working with either a 3CX Client, an IP Phone operating through an SBC, or even another PBX connected via a bridge, then the port you will need to open is the tunnel port of the PBX, which, by default is 5090 for both TCP and UDP traffic, unless changed during the installation process.
The Tunnel protocol port encapsulates both SIP and Audio packets so only one port is required for calls to be made.
Because the endpoints may also receive other non-SIP information such as Presence Information, Provisioning Information and the Company Phonebook, one more port must be opened. That is the HTTPS port you chose during the installation process which, by default, is 5001.
WebMeeting is another great feature 3CX offers. In order to use this, you must allow outbound traffic to the WebMeeting server which is webmeeting.3cx.net on port 443. This is irrespective of which HTTPS port is defined on the PBX.
Most firewalls allow outbound traffic without any restrictions. However, some corporate firewall restrict outgoing traffic as well.
In order for notifications to reach your 3CX Server from the Web Meeting server, you must ensure that your PBX HTTPS port is open for TCP traffic.
Only do this configuration in the case where your firewall does restrict outgoing traffic to only the configured destinations.
External IP Phones can be connected through an SBC to the 3CX Server, but they can also be connected directly.
In this case, the ports that need to be opened and forwarded are very similar to those required for a VoIP Provider.
The PBX SIP Port must be forwarded for TCP and UDP traffic, as well as the audio ports for UDP traffic. In addition to those, the HTTPS port will need to be opened for TCP traffic, which will allow the IP Phone to retrieve information like the Provisioning file and the Phonebook.
During the setup of the PBX, using the PBXConfigTool, using a browser, port 5015 will be used with TCP traffic. If you are performing this task from a remote network, you will need to have this port forwarded to the PBX. This is only required for the host setup, and will not be used during the actual everyday use of the PBX.
Once you have done your firewall configuration, it is now time to run the Firewall Checker.
What this does is check if the ports have indeed been opened and provides a status.
Green means that the port has been successfully opened, or
Red means that the port has not been opened, in which case you must check your firewall configuration again.
To run the Firewall Checker log into your Management Console and in the Dashboard select the Firewall option.
It is worth pointing out that only UDP ports are checked.
This means that it cannot check the SIP, Tunnel and HTTPS port TCP traffic.
The firewall checker will stop the PBX services to perform the tests, and restart them automatically when it finishes. Please be careful when performing this test on a live system.
Here you can see an example of the Firewall Checker, which was run on a system that seems to fail all of the tests. This is clearly stated in the results.
This means that either the firewall has not been configured at all, or the configuration has been done incorrectly.
In this case, if you do not know how to proceed, you should contact the Support Team of your Firewall manufacturer so that they can help you with the procedure.
As this may require special knowledge of your Firewall device, the 3CX Support Team will not be able to help you with this process. Also there is no point in troubleshooting any issues related to VoIP Providers or Remote Extensions just yet.
The issue is an incorrect configuration of the firewall. Once you get the firewall configured correctly and the firewall checker passes, then see if your issue remains.
Now if this is a new installation, there is no reason proceeding with creating and provisioning VoIP Providers, Bridges or Remote Extensions until the failed Firewall Checker result has been resolved.
This is another example of a Firewall Checker result.
This is not a complete fail like before, but it is neither a complete success.
As we can see, here the SIP Server port, 5060 and Tunneling Proxy port, 5090 have passed while all others failed. This is still considered a failed Firewall Check, but we are on the right track!
The same procedure applies as before. Talk with your firewall manufacturer if you require assistance in the configuration before proceeding any further.
This is what a successful Firewall Checker result looks like.
So what has been checked in the firewall checker?
Full Cone NAT has been successfully configured and Port Preservation is correct.
SIP ALG has also been tested by the Firewall checker and has not been detected, so it is considered to be disabled.
Also, remember that we mentioned that the ports are not checked for TCP, so ensure the ports that require TCP have been opened correctly.
You can now start configuring the PBX to accept connections from the outside world.
We are now in a position to check whether SIP ALG is active on the firewall or not now.
The SIP ALG test is integrated in the firewall test. If it is disabled, it will give a Green result.
If it is enabled and detected, it will give a failed result. You will need to configure your firewall to disable this.
Thank you and goodbye!