Perché il Firewall Checker non mente

Il 3CX Firewall Checker è uno strumento integrato fondamentale che verifica automaticamente la configurazione del firewall per quanto riguarda il port forwarding e la conservazione delle porte. Il presente documento illustra i concetti fondamentali alla base di questi test e spiega in che modo il checker garantisce una comunicazione ottimale per il sistema 3CX tramite UDP. Per verificare la connettività TCP è possibile utilizzare uno qualsiasi dei validatori di porte TCP comunemente disponibili.

Port Forwarding

3CX verifica che il “Full Cone NAT” sia configurato correttamente sul firewall o sul dispositivo gateway. Il Full Cone NAT consente a qualsiasi entità esterna di connettersi a 3CX senza che il firewall debba prima confermare che il pacchetto provenga da 3CX. Ciò è fondamentale per i provider VoIP, poiché il server SIP (indirizzo IP di origine) che gestisce la segnalazione potrebbe non essere lo stesso server che fornisce l'audio effettivo al sistema. Senza il Full Cone NAT, alcuni firewall potrebbero bloccare il traffico in entrata, impedendo la connessione anche se è 3CX ad avviare la comunicazione.

Preservazione delle porte

La conservazione delle porte è un altro fattore critico verificato dallo strumento di controllo del firewall. Esso rileva se il firewall modifica la porta durante la traduzione dall'IP LAN locale all'IP WAN pubblico. Sebbene le RFC stabiliscano che un server SIP debba rispondere all'IP e alla porta “contact” specificati nel contenuto del messaggio SIP, alcuni provider potrebbero rispondere alla porta di origine del trasporto di 3CX visibile nell'intestazione UDP. Per prevenire potenziali problemi, il firewall checker verifica che, se un messaggio SIP viene generato da 3CX da una specifica porta di origine locale (ad esempio, 5060), quella stessa porta rimanga invariata quando viene tradotta nell'indirizzo IP pubblico.

Il firewall checker esegue questi test utilizzando il primo server STUN configurato nel sistema, che varia a seconda della regione; uno dei più comuni è “stun.3cx.com”. Si raccomanda vivamente di non modificare questa impostazione. In sostanza, il firewall checker rileva a livello di programmazione l’indirizzo IP pubblico e estende questa funzionalità per verificare anche le mappature delle porte.

Come eseguire il Firewall Checker

Server STUN 3CX da inserire nella whitelist per il corretto funzionamento del Firewall Check:

• 34.40.60.101
• 34.40.164.62
• 34.83.212.229
• 34.138.123.132

Per eseguire il Firewall Checker:

• Accedere alla Console di Amministrazione 3CX.
• Passare alla Dashboard.
• Individuare la sezione Firewall Checker e cliccarci sopra per accedere alla scheda di test.
• Cliccare su “Avvia” per iniziare i test.
• I servizi PBX verranno arrestati e riavviati durante questo processo; è possibile interromperlo premendo “Stop”.

• I risultati verranno visualizzati aggiornati direttamente, indicando se ogni test è stato superato o meno.

Comprendere i risultati del Firewall Checker

Di seguito è riportato un esempio di un controllo del firewall non superato segnalato dalla Console di Amministrazione 3CX.

Firewall Checker esegue una serie di test per convalidare la configurazione di rete. Di seguito illustreremo i passaggi eseguiti e i risultati attesi.  

NOTE:  

• Il controllo delle porte verifica i blocchi di porte pari all'inizio e alla fine dell'intervallo di porte valido, per brevità del test. È necessario assicurarsi che l'intero intervallo di porte che il PBX si aspetta di avere a disposizione sia consentito dal firewall per intero, senza lacune.
• Per un'analisi dettagliata delle installazioni Windows, si consiglia di disabilitare il firewall di Windows sul server 3CX durante il test, poiché, sebbene 3CX crei delle eccezioni per le proprie applicazioni, potrebbe non farlo per lo strumento di controllo del firewall stesso.

Test 1: Conservazione delle porte e connettività in uscita

Nel Test 1, 3CX interrompe temporaneamente i propri servizi per liberare le porte locali necessarie per il test. Sebbene la procedura sia la stessa per tutte le porte, ci concentreremo sulla porta SIP predefinita (5060).

Il server 3CX esegue i seguenti passaggi:

• Invia una richiesta classic-stun dal proprio indirizzo IP locale (ad es. 192.168.3.159) al server STUN configurato (ad es. stun.3cx.com).
• La richiesta ha origine da una porta UDP locale (ad es. 5060).
• Viene inviata alla porta predefinita del server STUN (3478).
• La richiesta indica esplicitamente al server STUN di NON modificare il proprio IP o la propria porta quando risponde.

Ogni richiesta include un “ID transazione” univoco per garantire una corrispondenza affidabile delle risposte.

Se il server invia più richieste ma non riceve alcuna risposta, come mostrato di seguito, ciò indica:

• Il traffico in uscita è stato bloccato dal firewall, oppure
• Nessun traffico di ritorno è stato rinviato al server.

In entrambi i casi, è necessario controllare le impostazioni del firewall.

Il server STUN dovrebbe quindi rispondere con:

• Una risposta di binding alla richiesta.
• Essa definisce l'IP pubblico e la porta da cui è stata inviata la richiesta (ad es., IP pubblico XX.XX.96.162 e porta 5060).

In base a ciò, se il campo “Mapped-Address” nella risposta STUN mostra la stessa porta (ad es. 5060) della porta di origine della richiesta iniziale, allora la conservazione della porta funziona correttamente. Se nel campo “Mapped-Address” viene mostrata qualsiasi altra porta, il controllo del firewall fallirà, indicando che la conservazione della porta NON funziona. In questo scenario, sarà necessario contattare il produttore del firewall per assistenza.

Test 2: Convalida NAT a cono pieno

Nel Test 2, il server 3CX invia un'altra richiesta allo stesso server STUN. Tuttavia, questa volta:

• Il server 3CX contrassegna la richiesta con “Change IP and Change Port” impostato su (1).
• Ciò indica al server STUN di inviare la sua risposta da un indirizzo IP e una porta diversi da quelli a cui è stata inviata la richiesta iniziale.
• Questo nuovo IP/Porta di origine è sconosciuto al firewall, che in genere si aspetterebbe una risposta dalla destinazione originale.

Se il server invia più richieste senza ricevere una risposta dal server STUN, ciò indica che il Full Cone NAT non funziona.

A differenza del Test 1, in cui 3CX si aspetta una risposta dal server con cui ha comunicato attivamente, il Test 2 simula la ricezione di dati da una fonte con cui 3CX non ha “comunicato” direttamente (simile a un server audio di un provider VoIP). Se non viene ricevuta alcuna risposta, significa che il firewall sta bloccando questo tipo di traffico. In questo caso, contattare il produttore del firewall per risolvere il problema.

Una risposta positiva nel Test 2 mostrerebbe l’“Indirizzo mappato” esattamente uguale all’IP e alla porta del Test 1. Se si desidera approfondire, controllare i log del firewall per il traffico proveniente dagli indirizzi IP del server STUN di 3CX, poiché la risposta prevista non ha mai raggiunto l’interfaccia di rete del server 3CX.

Test SIP ALG

3CX valuta anche se SIP ALG (Application Layer Gateway) è abilitato sul firewall. Le funzioni SIP ALG ispezionano il contenuto dei pacchetti SIP oltre alle liste di accesso IP/Porta. Per gli amministratori 3CX, ciò può causare numerosi problemi perché le modifiche apportate ai messaggi SIP da un hop intermedio (il firewall) non saranno visibili nelle tracce 3CX, portando a problemi di incompatibilità con telefoni IP remoti o provider VoIP.

Processo di convalida:

• 3CX genera un messaggio INVITE generico e lo invia a un servizio online ospitato da 3CX. Solo l'indirizzo IP pubblico è specifico; tutte le altre informazioni sono generiche.

• 3CX calcola localmente un valore hash CRC32 dal messaggio inviato e si aspetta che il servizio online restituisca lo stesso valore hash nella sua risposta.

• Se il valore di ritorno “X-CSREQ” corrisponde al valore calcolato localmente, significa che SIP ALG non ha manomesso il messaggio o non è presente. Se i valori non corrispondono, il test mostra che un hop intermedio tra 3CX e il servizio online ha alterato il contenuto, il che significa che SIP ALG è attivo.

Calcolo del valore hash previsto

È possibile verificare manualmente il valore hash previsto catturando l'INVITE in uscita verso il servizio di rilevamento SIP ALG utilizzando Wireshark:

• Ciccare con il tasto destro del mouse sul messaggio INVITE inviato da 3CX in Wireshark.
• Selezionare Copia > Byte > Flusso esadecimale.

• Aprire un calcolatore CRC online (ad es., http://www.sunshine2k.de/coding/javascript/crc/crc_js.html).
• Incollare lo stream esadecimale copiato nel campo “CRC Input Data”.

• Il risultato calcolato deve corrispondere al valore restituito nell'intestazione “X-CSREQ” della risposta 200 OK.

Risoluzione dei problemi comuni relativi al firewall

Se il controllo del firewall non va a buon fine, verificare quanto segue:

• Disattivare SIP ALG: Assicurarsi che SIP ALG o qualsiasi funzione SIP Helper siano disattivate sul router/firewall. Questa è una causa comune di problemi relativi al protocollo SIP.
• Inoltro delle porte: Verifica che tutte le porte necessarie siano correttamente inoltrate al tuo sistema 3CX. Le porte principali includono:

• Trunk SIP / Provider VoIP:

• Porta 5060 (in entrata, UDP) e 5060-5061 (in entrata, TCP) per SIP.
• Porta 9000-10999 (in entrata, UDP) per RTP (Audio).

• App 3CX remote e SBC:

• Porta 5090 (in entrata, UDP e TCP) per il tunnel 3CX.
• Porta 443 o 5001 (in entrata, TCP) per HTTPS (Presenza e Provisioning).
• Porta 443 (in uscita, TCP) per Google Android Push.
• Porte 443, 2197 e 5223 (in uscita, TCP) per Apple iOS Push.

• Videoconferenza 3CX:

• Porta 443 (in entrata, TCP) per i partecipanti.
• Porta 443 (in uscita, TCP) dal sistema 3CX al cloud 3CX.

• Porte 443 (in uscita, TCP) e 48000-65535 (in uscita, UDP) dagli utenti per lo scambio audio/video.
• Log del firewall: controllare i log del firewall per eventuali connessioni bloccate relative alle porte utilizzate da 3CX, specialmente durante l'esecuzione non riuscita del controllo del firewall.
• Regole ACL/firewall: definire regole ACL/firewall appropriate per consentire all'host 3CX di raggiungere le sottoreti/gli endpoint richiesti all'interno e all'esterno della rete.

Ultimo aggiornamento

Questo documento è stato aggiornato il 12 giugno 2026

https://www.3cx.it/doc/firewall-checker/