Warum der Firewall-Checker nicht lügt

Der 3CX Firewall Checker ist ein unverzichtbares, integriertes Tool, das die Konfiguration Ihrer Firewall für Portweiterleitung und Portbeibehaltung automatisch überprüft. Dieses Dokument erläutert die grundlegenden Konzepte dieser Tests und wie der Checker eine optimale Kommunikation Ihres 3CX-Systems über UDP sicherstellt. Zur Überprüfung der TCP-Konnektivität können Sie jeden gängigen TCP-Port-Validator verwenden.

Port Forwarding

3CX überprüft, ob „Full Cone NAT“ auf Ihrer Firewall oder Ihrem Gateway korrekt konfiguriert ist. Full Cone NAT ermöglicht es externen Systemen, sich mit 3CX zu verbinden, ohne dass die Firewall zuvor die Herkunft des Pakets von 3CX bestätigen muss. Dies ist für VoIP-Anbieter entscheidend, da der SIP-Server (Quell-IP-Adresse), der die Signalisierung übernimmt, nicht unbedingt derselbe Server ist, der die eigentliche Audioübertragung an Ihr System liefert. Ohne Full Cone NAT blockieren manche Firewalls eingehenden Datenverkehr und verhindern so eine Verbindung, selbst wenn 3CX die Kommunikation initiiert.

Port Preservation

Die Beibehaltung des Ports ist ein weiterer wichtiger Faktor, den die Firewall-Prüfung überprüft. Sie erkennt, ob Ihre Firewall den Port bei der Übersetzung von Ihrer lokalen LAN-IP-Adresse zu Ihrer öffentlichen WAN-IP-Adresse ändert. Obwohl RFCs festlegen, dass ein SIP-Server auf die im SIP-Nachrichteninhalt angegebene „Kontakt“-IP-Adresse und den Port antworten soll, antworten manche Anbieter möglicherweise auf den im UDP-Header angegebenen Transportquellport von 3CX. Um potenzielle Probleme zu vermeiden, validiert die Firewall-Prüfung, ob ein von 3CX generierter lokaler Quellport (z. B. 5060) bei der Übersetzung zur öffentlichen IP-Adresse unverändert bleibt.

Der Firewall-Checker führt diese Tests mit dem ersten konfigurierten STUN-Server Ihres Systems durch. Dieser variiert je nach Region; ein gängiger Server ist „stun.3cx.com“. Es wird dringend empfohlen, diese Einstellung nicht zu ändern. Der Firewall-Checker erkennt automatisch Ihre öffentliche IP-Adresse und überprüft darüber hinaus auch die Portweiterleitungen.

So führen Sie den Firewall-Checker aus

3CX STUN-Server, die für einen erfolgreichen Firewall-Check auf die Whitelist gesetzt werden müssen:

• 34.40.60.101
• 34.40.164.62
• 34.83.212.229
• 34.138.123.132

So führen Sie den Firewall-Checker aus:

• Öffnen Sie die 3CX-Administrationskonsole.
• Navigieren Sie zum Dashboard.
• Suchen Sie den Abschnitt „Firewall-Checker“ und klicken Sie darauf, um zum Test-Tab zu gelangen.
• Klicken Sie auf „Start“, um die Tests zu beginnen.
• Die PBX-Dienste werden während dieses Vorgangs angehalten und neu gestartet. Sie können den Vorgang durch Klicken auf „Stopp“ beenden.

• Die Ergebnisse werden direkt aktualisiert angezeigt und geben an, ob jeder Test bestanden oder nicht bestanden wurde.

Firewall-Checker-Ergebnisse verstehen

Nachfolgend ein Beispiel für einen fehlgeschlagenen Firewall-Check, der von der 3CX-Administrationskonsole gemeldet wurde.

Der Firewall-Checker führt eine Reihe von Tests durch, um Ihre Netzwerkkonfiguration zu überprüfen. Wir erläutern die einzelnen Schritte und die zu erwartenden Ergebnisse.

ANMERKUNGEN:

• Der Port-Check überprüft aus Gründen der Testeffizienz Blöcke gerader Ports am Anfang und Ende des gültigen Portbereichs. Sie müssen sicherstellen, dass der gesamte vom PBX erwartete Portbereich lückenlos durch Ihre Firewall freigegeben ist.
• Für eine detaillierte Analyse unter Windows-Installationen empfiehlt es sich, die Windows-Firewall auf dem 3CX-Server während der Tests zu deaktivieren. 3CX erstellt zwar Ausnahmen für seine Anwendungen, jedoch möglicherweise nicht für den Firewall-Check selbst.

Test 1: Porterhaltung und ausgehende Konnektivität

In Test 1 unterbricht 3CX vorübergehend seine Dienste, um die für die Tests benötigten lokalen Ports freizugeben. Obwohl die Vorgehensweise für alle Ports gleich ist, konzentrieren wir uns hier auf den Standard-SIP-Port (5060).

Der 3CX-Server führt folgende Schritte aus:

• Sendet eine klassische STUN-Anfrage von seiner lokalen IP-Adresse (z. B. 192.168.3.159) an den konfigurierten STUN-Server (z. B. stun.3cx.com).
• Die Anfrage stammt von einem lokalen UDP-Port (z. B. 5060).
• Sie wird an den Standard-STUN-Server-Port (3478) gesendet.
• Die Anfrage weist den STUN-Server explizit an, seine IP-Adresse und seinen Port bei der Antwort nicht zu ändern.

Jede Anfrage enthält eine eindeutige „Transaktions-ID“, um eine zuverlässige Zuordnung der Antworten zu gewährleisten.

Wenn der Server mehrere Anfragen sendet, aber keine Antwort erhält, wie unten dargestellt, deutet dies auf Folgendes hin:

• Der ausgehende Datenverkehr wurde von der Firewall blockiert, oder
• es wurde kein Rückverkehr an den Server weitergeleitet.

In jedem Fall müssen Sie Ihre Firewall-Einstellungen überprüfen.

Der Stun-Server antwortet dann mit:

• Eine bindende Antwort auf die Anfragen
• Definiert dann, dass die öffentliche IP und der öffentliche Port, von dem aus die Anfrage gesendet wurde, dem Port 5060 entsprechen und die IP-Adresse XX.XX.96.162 ist.

Wenn das Feld „Mapped-Address“ in der STUN-Antwort denselben Port (z. B. 5060) wie der Quellport der ursprünglichen Anfrage anzeigt, funktioniert die Portbeibehaltung korrekt. Wird ein anderer Port im Feld „Mapped-Address“ angezeigt, schlägt die Firewall-Prüfung fehl, was bedeutet, dass die Portbeibehaltung nicht funktioniert. In diesem Fall wenden Sie sich bitte an den Hersteller Ihrer Firewall.

Test 2: Validierung von Full Cone NAT

In Test 2 sendet der 3CX-Server eine weitere Anfrage an denselben STUN-Server. Diesmal jedoch:

• Der 3CX-Server kennzeichnet die Anfrage mit der Option „IP-Adresse und Port ändern“ (Wert: 1).
• Dadurch wird der STUN-Server angewiesen, seine Antwort von einer anderen IP-Adresse und einem anderen Port als dem der ursprünglichen Anfrage zu senden.
• Diese neue Quell-IP-Adresse und dieser neue Quell-Port sind der Firewall unbekannt; sie würde daher üblicherweise eine Antwort vom ursprünglichen Ziel erwarten.

Sendet der Server mehrere Anfragen, ohne eine Antwort vom STUN-Server zu erhalten, deutet dies darauf hin, dass Full Cone NAT nicht funktioniert.

Anders als in Test 1, in dem 3CX eine Antwort vom Server erwartet, mit dem es aktiv kommuniziert hat, simuliert Test 2 den Empfang von Daten von einer Quelle, mit der 3CX nicht direkt kommuniziert hat (ähnlich einem Audioserver eines VoIP-Anbieters). Bleibt eine Antwort aus, blockiert die Firewall diesen Datenverkehr. Wenden Sie sich in diesem Fall an den Hersteller Ihrer Firewall, um das Problem zu beheben.

Eine erfolgreiche Antwort in Test 2 würde die „Mapped-Address“ mit exakt derselben IP-Adresse und demselben Port wie in Test 1 anzeigen. Zur weiteren Untersuchung überprüfen Sie die Firewall-Protokolle auf Datenverkehr von den IP-Adressen des 3CX-STUN-Servers, da die erwartete Antwort die Netzwerkschnittstelle des 3CX-Servers nicht erreicht hat.

SIP ALG Test

3CX prüft außerdem, ob SIP ALG (Application Layer Gateway) auf Ihrer Firewall aktiviert ist. SIP ALG analysiert neben IP-/Port-Zugriffslisten auch den Inhalt von SIP-Paketen. Für 3CX-Administratoren kann dies zahlreiche Probleme verursachen, da Änderungen an SIP-Nachrichten durch einen Zwischenschritt (die Firewall) in den 3CX-Protokollen nicht sichtbar sind. Dies kann zu Inkompatibilitäten mit entfernten IP-Telefonen oder VoIP-Anbietern führen.

Validierungsprozess:

• 3CX generiert eine generische INVITE-Nachricht und sendet diese an einen von 3CX gehosteten Online-Dienst. Nur die öffentliche IP-Adresse ist spezifisch; alle anderen Informationen sind generisch.

• 3CX local generiert einen CRC32-Hash-Wert aus der gesendeten Nachricht und erwartet im Gegenzug eine Antwort vom Cloud-Dienst, dass der Hash denselben Wert haben wird.

• Stimmt der Rückgabewert von „X-CSREQ“ mit dem lokal berechneten Wert überein, bedeutet dies, dass SIP ALG die Nachricht nicht manipuliert hat oder nicht vorhanden ist. Stimmen die Werte nicht überein, zeigt der Test, dass ein Zwischenschritt zwischen 3CX und dem Online-Dienst den Inhalt verändert hat, was bedeutet, dass SIP ALG aktiv ist.

Berechnung des erwarteten Hashwerts

Sie können den erwarteten Hashwert manuell überprüfen, indem Sie die ausgehende INVITE-Nachricht an den SIP ALG-Erkennungsdienst mit Wireshark aufzeichnen:

• Klicken Sie in Wireshark mit der rechten Maustaste auf die von 3CX gesendete INVITE-Nachricht.
• Wählen Sie „Kopieren“ > „Bytes“ > „Hex-Stream“.

• Öffnen Sie einen Online-CRC-Rechner (z. B. https://www.sunshine2k.de/coding/javascript/crc/crc_js.html).
• Fügen Sie den kopierten Hexadezimaldatenstrom in das Feld „CRC-Eingabedaten“ ein.

• Das berechnete Ergebnis muss mit dem Wert übereinstimmen, der im "X-CSREQ"-Header der 200 OK-Antwort zurückgegeben wird.

Behebung häufiger Firewall-Probleme

Falls die Firewall-Prüfung fehlschlägt, beachten Sie Folgendes:

• SIP ALG deaktivieren: Stellen Sie sicher, dass SIP ALG und alle SIP-Hilfsfunktionen auf Ihrem Router/Ihrer Firewall deaktiviert sind. Dies ist eine häufige Ursache für SIP-Probleme.
• Portweiterleitung: Überprüfen Sie, ob alle erforderlichen Ports korrekt an Ihr 3CX-System weitergeleitet werden. Wichtige Ports sind:

• SIP-Trunk/VoIP-Anbieter:

• Port 5060 (eingehend, UDP) und 5060–5061 (eingehend, TCP) für SIP.
• Port 9000–10999 (eingehend, UDP) für RTP (Audio).

• Remote 3CX-Apps & SBC:

• Port 5090 (eingehend, UDP und TCP) für den 3CX-Tunnel.
• Port 443 oder 5001 (eingehend, TCP) für HTTPS (Präsenz und Bereitstellung).
• Port 443 (ausgehend, TCP) für Google Android Push.
• Ports 443, 2197 und 5223 (ausgehend, TCP) für Apple iOS Push.

• 3CX-Videokonferenz:

• Port 443 (eingehend, TCP) für Teilnehmer.
• Port 443 (ausgehend, TCP) vom 3CX-System zur 3CX-Cloud.

• Ports 443 (ausgehend, TCP) und 48000–65535 (ausgehend, UDP) von Benutzern für den Audio-/Videoaustausch.
• Firewall-Protokolle: Überprüfen Sie Ihre Firewall-Protokolle auf blockierte Verbindungen im Zusammenhang mit den von 3CX verwendeten Ports, insbesondere nach einem fehlgeschlagenen Firewall-Check.
• ACL-/Firewall-Regeln: Definieren Sie geeignete ACL-/Firewall-Regeln, damit der 3CX-Host die erforderlichen Subnetze/Endpunkte innerhalb und außerhalb Ihres Netzwerks erreichen kann.

Siehe auch

• Firewall- und Routerkonfiguration

Letztes Update

Dieses Dokument wurde zuletzt am 22. Juli 2026 aktualisiert.

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