Why the Firewall Checker Does not Lie

3CX Phone System has a built-in automated firewall checker which validates the setup of your firewall in terms of “port forwarding” and also “port preservation”.

Port Forwarding

3CX Phone System will check if  “Full Cone NAT” is correctly set up on the firewall/gateway device. Full Cone NAT allows any external entity to connect to 3CX Phone System without the need for the firewall to first confirm that the actual packet originated from 3CX Phone System before allowing the connection. This is very important for VoIP Providers especially, as the SIP server is not the same server (source IP Address) which will deliver the end audio to your system. In some cases a firewall implementation will set “not allowed” incoming traffic onto a deny list, which will prevent a connection to the destination even if 3CX Phone System starts sending data (audio) to its destination.

Port Preservation

Port preservation is another key factor which is checked by the firewall checker. It detects if the firewall alters the port during the LAN IP to WAN IP translation. Technically speaking this should not matter, however it depends on the provider’s implementation whether they reply to the transport source port of 3CX Phone System seen in the UDP header rather than what is defined by the RFC. The RFC defines that a SIP server MUST reply to the defined “contact” IP and Port which is in the content of the SIP message. In order to eliminate any “maybies” the firewall checker also validates this mapping. It is required that if a SIP message is generated locally by 3CX Phone System from the source port 5060 (default SIP Port) then translated to the public IP Address (WAN IP) the port, in this case 5060, remains unchanged.

To do this the firewall checker will run two independent tests with the first configured STUN Server in your system. By default this is set to stun.3cx.com. It is highly recommended that this is not altered. Overall, the firewall checker is a programmatic way to detect your public IP address, similar to using a website like “what is my IP”, but is extended to also check the port.


Below is a failed firewall check reported by the 3CX Management Console and a corresponding wireshark capture of the flow. In this guide we will elaborate the steps taken by the firewall checker and show you the results. The wireshark capture is limited to show “port 3478 or port 3479” only, which this test was based on. Its is important for the firewall checker that the Windows firewall is disabled. The installation of 3CX Phone System creates exceptions for some 3CX applications, however not for the firewall checker itself!

pasted image 0Test 1

3CX Phone System stops the services to free the local port in order to bind it to the firewall checker. This document will only focus on the first port been tested (5060) however the procedure is the same for all other ports.

pasted image 2

The image above shows the following steps:

  1. The local 3CX Phone System server with IP address, Sends a classic stun request to stun.3cx.com with IP
  2. From local port 5060 UDP.
  3. To 3478, which is the default stun server port.
  4. Declaring that the STUN server should NOT change it’s IP or the Port in order to reply to this request.

Each request has a unique “transaction ID” to reliably ensure that the received data belongs to the initial request. In rare cases you might see that the server sends multiple requests however never gets a reply as shown below. This implies that:

a) The outbound traffic was blocked by the firewall or b) No return was passed back to the server. In both cases, check your firewall settings!

pasted image 3

The Stun server then answers with:

  1. A Binding Response to the requests
  2. Then defines that the public IP and Port from where the request was sent from is equal to the port 5060 and the IP address is XX.XX.96.162.

Based on the definition earlier – port preservation is working as the stun server can see the PBX on the defined port. If you see any other port in the “Mapped-Address” field the firewall check will fail and port preservation is NOT working correctly. in this case you will need to contact the firewall manufacturer to resolve the problem.

Test 2

In test 2 the server will send another request to the same stun server as before.

pasted image 4


  1. The 3CX Phone System Server marks the request to be different than before and sets “Change IP and Change Port” to (1). This means that the stun server should send its response back to 3CX Phone System, this time however from an IP address and Port which is unknown by the firewall, that is expecting a response to the request.
  2. It is clear that the server sent the same request 3 times without getting a reply from the stun server. This indicates that full cone NAT is not working.

Compared to test 1, where the 3CX Phone System server actively sends data to the stun server and receives a response, test 2 shows that the data returns from a source that 3CX Phone System has never talked to (i.e the audio server of a VoIP provider) and was not able to receive a response. In this case contact the firewall manufacturer to resolve the problem.

The correct response would be to receive data in the second test whereby the “Mapped-Address” is exactly the same as in test 1 for IP and Port.

If you are keen to see where the traffic should have come from, check your firewall logs. The IP address of the 3CX Stun servers are (-1) and the port is (+1). So the answer was expected to come from but never made it to the NIC of 3CX Phone System.

Hence the system reports:

Testing SIP Port 5060 using STUN server: stun.3cx.com:3478

Resolving STUN server stun.3cx.com … Resolved to: []

[Test1] Reachability test … Resolved Public IP: XX.XX.96.162:5060

STUN server stun.3cx.com has second address

[Test2] One on One Port Forwarding … FAILED.

No response received or port mapping is closed. Firewall check failed. This configuration is not supported