Why the Firewall Checker Does Not Lie
3CX has an inbuilt automated firewall checker which validates the setup of your firewall in terms of “port forwarding” and also “port preservation”.
On this topic:
3CX 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 without the need for the firewall to first confirm that the actual packet originated from 3CX 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 firewall implementation will set “not allowed” incoming traffic onto a deny list, which will prevent a connection to the destination even if 3CX starts sending data (audio) to its destination.
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 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 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 which are taken by the firewall checker and show you the results. The wireshark capture is limited to show “port 3378 or port 3379” only, which this test was based on. Its is important for the firewall checker that the Windows firewall is disabled. The installation of 3CX creates exceptions for some 3CX applications, however not for the firewall checker itself!
3CX 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 being tested (5060) however the procedure is the same for all other ports.
The image above shows the following steps:
- The local 3CX server with IP address 192.168.3.159, Sends a classic stun request to stun.3cx.com with IP 18.104.22.168.
- From local port 5060 UDP.
- To 3478, which is the default stun server port.
- Declaring that the STUN server should NOT change its 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!
The Stun server then answers with:
- A Binding Response to the requests
- 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.
In test 2 the server will send a request to the same stun server as before.
- The 3CX 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 however from an IP address and Port which is now unknown to the firewall expecting a response to the request.
- 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 server actively sends data to the stun server and receives a response, test 2 shows that the data returns from a source that 3CX has never talked to (i.e the audio server of a VoIP provider) and was not able to receive any 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 22.214.171.124:3479 but never made it to the NIC of 3CX.
Hence the system reports:
Testing SIP Port 5060 using STUN server: stun.3cx.com:3478
Resolving STUN server stun.3cx.com ... Resolved to: [126.96.36.199]
[Test1] Reachability test ... Resolved Public IP: XX.XX.96.162:5060
STUN server stun.3cx.com has second address 188.8.131.52:3479
[Test2] One on One Port Forwarding ... FAILED.
No response received or port mapping is closed. Firewall check failed. This configuration is not supported
SIP ALG Test (since V15.5 SP1)
In addition to the existing NAT test, 3CX evaluates if the firewall has SIP ALG enabled. SIP ALG in brief, are functions found in some firewall devices inspecting, beside the from and to IP/Ports access list, the content of the packages. In this case SIP. For the administrator of 3CX this can cause numerous issues and due to the fact that the changes to the SIP messages are made by an intermediate hop, traces made on 3CX will not show those changes. However they may cause incompatibility issues with remote IP phones or VoIP providers.
Validation: 3CX will generate a generic INVITE message and send it against an online service hosted by 3CX. Except the public IP address all other information is generic rendered.
3CX local generates CRC32 hash value from the send message and expects in return an answer from the cloud service that the hash will have the same value.
If “X-CSREQ” return value matches the local calculated value, it is expected that SIP ALG has not tempered with the message or is not present. If the values do not match, the test shows that a hop between 3CX and the online service has altered the content = SIP ALG.
On a validation basis, the expected hash value can be calculated given that wireshark has captured the outbound INVITE to the SIP ALG detection service.
And paste the copied hey stream into the CRC Input Data
The given Result must match the value returned.