Why the Firewall Checker Does Not Lie

The 3CX Firewall Checker is an essential, built-in tool that automatically validates your firewall's configuration for port forwarding and port preservation. This document explains the core concepts behind these tests and how the checker ensures optimal communication for your 3CX system, over UDP. To validate TCP connectivity you can use any of the widely available TCP port validators.

Port Forwarding

3CX verifies that "Full Cone NAT" is correctly configured on your firewall or gateway device. Full Cone NAT allows any external entity to connect to 3CX without the firewall first needing to confirm that the packet originated from 3CX. This is crucial for VoIP Providers, as the SIP server (source IP address) that handles signaling may not be the same server that delivers the actual audio to your system. Without Full Cone NAT, some firewalls might block incoming traffic, preventing a connection even if 3CX initiates the communication.

Port Preservation

Port preservation is another critical factor checked by the firewall checker. It detects if your firewall alters the port during the translation from your local LAN IP to your public WAN IP. While RFCs define that a SIP server should reply to the "contact" IP and Port specified in the SIP message content, some providers might reply to the transport source port of 3CX seen in the UDP header. To prevent potential issues, the firewall checker validates that if a SIP message is generated by 3CX from a specific local source port (e.g., 5060), that same port remains unchanged when translated to the public IP address.

The firewall checker performs these tests using the first configured STUN Server in your system which varies depending on region, a common one being “stun.3cx.com”. It is highly recommended not to alter this setting. Essentially, the firewall checker programmatically detects your public IP address and extends this functionality to also verify port mappings.

How to Run the Firewall Checker

3CX STUN servers to whitelist for a successful Firewall Check:

• 34.40.60.101
• 34.40.164.62
• 34.83.212.229
• 34.138.123.132

To run the Firewall Checker:

• Go to the 3CX Admin Console.
• Navigate to Dashboard.
• Locate the Firewall Checker section and click on it to enter the testing tab.
• Click “Start” to begin the tests.
• PBX services will be stopped and restarted during this process, you can end it by pressing “Stop”.

• The results will be displayed updated directly, indicating whether each test passed or failed.

Understanding Firewall Checker Results

Below is an example of a failed firewall check reported by the 3CX Admin Console.

The firewall checker performs a series of tests to validate your network configuration. We will elaborate on the steps taken and the expected results.

NOTES:

• The port check verifies blocks of even ports at the start and end of the valid port range, for test brevity. You must ensure the complete range of ports that the PBX expects to have available is allowed through your firewall in full, without gaps.
• For detailed analysis on Windows installations, it's recommended to disable the Windows firewall on the 3CX server during testing, as while 3CX creates exceptions for its applications, it might not for the firewall checker itself.

Test 1: Port Preservation and Outbound Connectivity

In Test 1, 3CX temporarily stops its services to free up the local ports required for testing. While the procedure is the same for all ports, we'll focus on the default SIP port (5060).

The 3CX server performs the following steps:

• Sends a classic-stun request from its local IP address (e.g., 192.168.3.159) to the configured STUN server (e.g., stun.3cx.com).
• The request originates from a local UDP port (e.g., 5060).
• It is sent to the default STUN server port (3478).
• The request explicitly instructs the STUN server NOT to change its IP or Port when replying.

Each request includes a unique "transaction ID" to ensure reliable matching of responses.

If the server sends multiple requests but receives no reply, as shown below, it indicates:

• Outbound traffic was blocked by the firewall, or
• No return traffic was passed back to the server.

In either case, you must check your firewall settings.

The STUN server should then respond with:

• A Binding Response to the request.
• It defines the public IP and Port from which the request was sent (e.g., public IP XX.XX.96.162 and port 5060).

Based on this, if the "Mapped-Address" field in the STUN response shows the same port (e.g., 5060) as the source port of the initial request, then port preservation is working correctly. If any other port is shown in the "Mapped-Address" field, the firewall check will fail, indicating that port preservation is NOT working. In this scenario, you will need to contact your firewall manufacturer for assistance.

Test 2: Full Cone NAT Validation

In Test 2, the 3CX server sends another request to the same STUN server. However, this time:

• The 3CX Server marks the request with "Change IP and Change Port" set to (1).
• This instructs the STUN server to send its response from an IP address and port that is different from the one the initial request was sent to.
• This new source IP/Port is unknown to the firewall, which would typically expect a response from the original destination.

If the server sends multiple requests without receiving a reply from the STUN server, it indicates that Full Cone NAT is not working.

Unlike Test 1, where 3CX expects a response from the server it actively communicated with, Test 2 simulates receiving data from a source that 3CX has not directly "talked to" (similar to an audio server of a VoIP provider). If no response is received, it means the firewall is blocking this type of traffic. In this case, contact your firewall manufacturer to resolve the problem.

A successful response in Test 2 would show the "Mapped-Address" as exactly the same IP and Port as in Test 1. If you wish to investigate further, check your firewall logs for traffic from the 3CX STUN server IP addresses, as the expected answer never reached the 3CX server's network interface.

SIP ALG Test

3CX also evaluates if SIP ALG (Application Layer Gateway) is enabled on your firewall. SIP ALG functions inspect the content of SIP packets in addition to IP/Port access lists. For 3CX administrators, this can cause numerous issues because changes made to SIP messages by an intermediate hop (the firewall) will not be visible in 3CX traces, leading to incompatibility issues with remote IP phones or VoIP providers.

Validation Process:

• 3CX generates a generic INVITE message and sends it to an online service hosted by 3CX. Only the public IP address is specific; all other information is generic.

• 3CX locally calculates a CRC32 hash value from the sent message and expects the online service to return the same hash value in its response.

• If the "X-CSREQ" return value matches the locally calculated value, it indicates that SIP ALG has not tampered with the message or is not present. If the values do not match, the test shows that an intermediate hop between 3CX and the online service has altered the content, meaning SIP ALG is active.

Calculating the Expected Hash Value

You can manually validate the expected hash value by capturing the outbound INVITE to the SIP ALG detection service using Wireshark:

• Right-click on the INVITE message sent from 3CX in Wireshark.
• Select Copy > Bytes > Hex Stream.

• Open an online CRC calculator (e.g., http://www.sunshine2k.de/coding/javascript/crc/crc_js.html).
• Paste the copied hex stream into the "CRC Input Data" field.

• The calculated result must match the value returned in the "X-CSREQ" header of the 200 OK response.

Troubleshooting Common Firewall Issues

If your Firewall Checker fails, consider the following:

• Disable SIP ALG: Ensure SIP ALG or any SIP Helper functions are disabled on your router/firewall. This is a common cause of SIP-related issues.
• Port Forwarding: Verify that all necessary ports are correctly forwarded to your 3CX system. Key ports include:

• SIP Trunk / VoIP Provider:

• Port 5060 (inbound, UDP) and 5060-5061 (inbound, TCP) for SIP.
• Port 9000-10999 (inbound, UDP) for RTP (Audio).

• Remote 3CX Apps & SBC:

• Port 5090 (inbound, UDP and TCP) for the 3CX tunnel.
• Port 443 or 5001 (inbound, TCP) for HTTPS (Presence and Provisioning).
• Port 443 (outbound, TCP) for Google Android Push.
• Ports 443, 2197, and 5223 (outbound, TCP) for Apple iOS Push.

• 3CX Video Conference:

• Port 443 (inbound, TCP) for participants.
• Port 443 (outbound, TCP) from 3CX System to 3CX cloud.

• Ports 443 (outbound, TCP) and 48000-65535 (outbound, UDP) from users for audio/video exchange.
• Firewall Logs: Check your firewall logs for any blocked connections related to the ports 3CX uses, especially during a failed firewall checker run.
• ACL/Firewall Rules: Define appropriate ACL/firewall rules to allow the 3CX host to reach required subnets/endpoints within your network and outside.

See Also

• Firewall & router configuration 

Last Updated

This document was last updated on 02 June 2026

https://www.3cx.com/docs/firewall-checker/