Welche Ports müssen für eine 3CX-Anlage wirklich freigegeben werden? Eine saubere Antwort darauf sucht man im Netz vergeblich. Hier ist sie: fünf Netzpläne mit allen ein- und ausgehenden Freigaben – von On-Premise über SBC bis zur VLAN-Segmentierung.
Welche Ports müssen für eine 3CX-Anlage tatsächlich freigegeben werden? Eine saubere Antwort darauf sucht man im Netz vergeblich – die Angaben sind über Handbücher und Foren verstreut und decken Spezialfälle wie VLAN-Segmentierung gar nicht ab. Wir haben die Portfreigaben für 3CX V20 deshalb komplett aufgearbeitet: fünf Netzpläne mit allen ein- und ausgehenden Freigaben, inklusive der Regeln zwischen VLANs.
Die 3CX-Anlage steht im eigenen Netz und ist aus dem Internet erreichbar. Der klassische Fall – und der einzige, bei dem eingehende Portfreigaben zwingend nötig sind.
| Richtung | Port(s) | Zweck | Wann / worauf achten |
|---|---|---|---|
| eingehend | 5060 UDP · 5060–5061 TCP | SIP-Signalisierung vom Trunk | Immer bei SIP-Trunk. Auf die IP-Bereiche des Providers einschränken. |
| eingehend | 9000–10999 UDP | RTP – die eigentlichen Sprachdaten | Immer. 2 Ports je Gleichzeitiggespräch. |
| eingehend | 443 TCP (alt. 5001) | Web Client, Konsole, Presence, Provisionierung, WebRTC | Immer. Muss von ANY erreichbar bleiben – Homeoffice, Hotel, unterwegs. |
| eingehend | 5090 TCP + UDP | 3CX-Tunnel für SBC, Apps, Router-Phones | Sobald SBC oder Remote-Apps genutzt werden. TCP UND UDP – nur TCP gibt Einweg-Audio. |
| eingehend | 80 TCP | Let's-Encrypt-Validierung, Redirect auf HTTPS | Für die automatische Zertifikatserneuerung. Nicht offiziell dokumentiert. |
| ausgehend | 443 TCP | 3CX-Cloud: Aktivierung, Updates, RPS, Mail, Push, WebMeeting | Immer – Details in Diagramm 5. |
| ausgehend | 2197 + 5223 TCP | Apple APNs Push | Nur wenn iOS-Apps genutzt werden. |
| ausgehend | 48000–65535 UDP | Medienstrom der Videokonferenz | Nur bei Nutzung von 3CX Meet. |
| ausgehend | 3478 UDP · 53 · 123 | STUN, DNS, NTP | Immer. DNS und NTP sind technisch zwingend, von 3CX aber nicht dokumentiert. |
Die Anlage liegt in der 3CX-Cloud, am Standort steht ein SBC. Der große Vorteil: in der Standort-Firewall sind überhaupt keine eingehenden Freigaben nötig.
| Richtung | Port(s) | Zweck | Wann / worauf achten |
|---|---|---|---|
| keine / nicht nötig | eingehend: KEINE | Kein Port-Forwarding, keine eingehende Regel | Gilt immer – der SBC baut ausschließlich nach außen auf. |
| ausgehend | 5090 TCP + UDP | 3CX-Tunnel: SIP und RTP gebündelt zur Cloud-Anlage | Immer. TCP UND UDP freigeben. |
| ausgehend | 443 TCP (alt. 5001) | HTTPS zur Anlage: Provisionierung, Auth, Firmware | Immer – für SBC, Telefone und Apps. |
| ausgehend | 123 UDP · 53 UDP/TCP | NTP und DNS für SBC und Telefone | Immer. Ohne korrekte Zeit scheitert die TLS-Prüfung beim Provisionieren. |
| ausgehend | 80 / 443 TCP | RPS des Telefonherstellers | Nur beim Erst-Provisioning fabrikneuer oder zurückgesetzter Telefone. |
| lokal / LAN | 5060 UDP + RTP | SIP und Medien zwischen Telefon und SBC | Im selben Netz unkritisch. Bei VLAN-Trennung siehe Diagramm 3. |
| lokal / LAN | 224.0.1.75 : 5060 UDP | Plug & Play (SIP-Multicast, NICHT mDNS/5353) | Funktioniert nur im selben Layer-2-Segment. |
| keine / nicht nötig | 5060/5061 · 9000–10999 · 3478 | Bei SBC-Einsatz bewusst geschlossen lassen | SIP und RTP laufen gekapselt im Tunnel – das reduziert die Angriffsfläche erheblich. |
SBC in VLAN 2, Telefone in VLAN 3, Arbeitsplätze in VLAN 1. Zusätzlich zur Perimeter-Firewall müssen jetzt auch im Layer-3-Switch bzw. der internen Firewall Ports freigegeben werden.
| Richtung | Port(s) | Zweck | Wann / worauf achten |
|---|---|---|---|
| zwischen VLANs | 5060 UDP (ggf. TCP) | VLAN 3 → VLAN 2: SIP zum SBC als Outbound-Proxy | Immer. Der SBC lauscht standardmäßig auf 5060/UDP für lokale Endgeräte. |
| zwischen VLANs | kein dok. Bereich – prakt. dyn. UDP | VLAN 3 → VLAN 2: RTP/Medien zum SBC | 3CX veröffentlicht KEINE RTP-Range für den SBC. 9000–10999 gilt für den PBX-Medienserver, nicht für den SBC. In der Praxis den dynamischen UDP-Bereich gezielt zur SBC-IP freigeben. |
| zwischen VLANs | 5060 + ephemere UDP | VLAN 2 → VLAN 3: Rückrichtung SIP/RTP | Bei stateful Firewalls durch die Hinregel abgedeckt, bei statischen ACLs explizit nötig. |
| keine / nicht nötig | 224.0.1.75 : 5060 UDP | Plug & Play – nicht routbar | Multicast quert keine VLAN-Grenze. 3CX bezeichnet PnP über VLANs als nicht unterstützt. Ein mDNS-Repeater hilft NICHT (der reflektiert nur 224.0.0.251:5353). |
| ausgehend | 443 TCP | VLAN 3 → Internet: Provisionierung und Firmware | Zwingend. Der SBC ist kein Provisioning-Server – die Telefone holen die Config direkt bei der Cloud. |
| zwischen VLANs | 67 / 68 UDP (DHCP-Relay) | VLAN 3 → DHCP: Option 66 bzw. 132/133 | Der empfohlene Ersatz für PnP. Achtung: Option 66 überschreibt PnP – nicht beides parallel. |
| zwischen VLANs | 80 TCP | VLAN 1 → VLAN 3: Legacy-CTI (Telefonsteuerung) | Nur beim alten CTI-Modus. Beim modernen uaCSTA nicht nötig. |
| keine / nicht nötig | VLAN 1 → VLAN 2: keine | Apps müssen den SBC nicht erreichen | Die 3CX-Apps registrieren sich direkt bei der Cloud-Anlage. |
Die 3CX-Anlage steht im Server-VLAN, Telefone und Arbeitsplätze in eigenen VLANs. Hier ist besonders die Rückrichtung Server → Telefone wichtig, die gerne vergessen wird.
| Richtung | Port(s) | Zweck | Wann / worauf achten |
|---|---|---|---|
| zwischen VLANs | 5060 UDP + TCP · 5061 TLS | VLAN 3 → VLAN 2: SIP-Registrierung und Signalisierung | Immer. TLS nur bei SIP/TLS und SRTP. |
| zwischen VLANs | 9000–10999 UDP | VLAN 3 ↔ VLAN 2: RTP zum Medienserver | Immer. 3CX kennt nur EINEN Medienserver-Bereich – intern wie extern, nicht konfigurierbar. Gespräche zwischen zwei Telefonen im selben VLAN queren die Grenze nicht. |
| zwischen VLANs | 443 TCP (alt. 5001) | VLAN 3 → VLAN 2: Provisionierung, Firmware, Telefonbuch | Immer. Es gibt keinen separaten Provisioning-Port – es ist der Webserver-Port der Anlage. |
| zwischen VLANs | 5060 UDP/TCP ⚠ | VLAN 2 → VLAN 3: SIP NOTIFY (check-sync, BLF, Voicemail-LED) | Immer – und der häufigste Fehler. Fehlt die Regel, funktioniert Telefonieren, aber Reprovisionierung, BLF-Tasten und die Voicemail-Anzeige nicht. |
| zwischen VLANs | 443 TCP · 9000–10999 UDP | VLAN 1 → VLAN 2: Web Client / Desktop App inkl. WebRTC | Immer, wenn Arbeitsplätze in einem eigenen VLAN liegen. |
| zwischen VLANs | 22 · 443 · 5015 TCP | Management-VLAN → VLAN 2: SSH, Konsole, Setup-Assistent | V20 läuft nur auf Debian 12 – RDP/3389 entfällt. 5015 nur temporär beim Setup. |
| zwischen VLANs | 53 UDP/TCP ⚠ | Alle VLANs → DNS: Split-DNS | Bei V20 On-Premise Pflicht. Der FQDN muss in JEDEM VLAN auf die interne Server-IP zeigen, sonst NAT-Hairpin über die Firewall und typischerweise einseitiges Audio. |
| zwischen VLANs | 80 TCP | VLAN 1 → VLAN 3: Legacy-CTI | Nur beim alten CTI-Modus. 'Gleiches Subnetz' ist eine Vereinfachung – Routing plus Portfreigabe genügt. |
Gilt für jede selbst gehostete Anlage. Alle Ziele laufen über 443/TCP – drei davon dürfen aber nicht durch eine TLS-Inspection laufen.
| Richtung | Port(s) | Zweck | Wann / worauf achten |
|---|---|---|---|
| ausgehend | activate.3cx.com : 443 | Lizenzaktivierung und -prüfung | Immer. ⚠ Ohne SSL-Inspection freigeben. |
| ausgehend | discoverv4.3cx.com : 443 | Discovery / FQDN-Auflösung | Immer. ⚠ Ohne SSL-Inspection freigeben. |
| ausgehend | pbxservicespush.3cx.com : 443 | Push-Dienst – weckt die Smartphone-Apps | Bei Nutzung der Apps. ⚠ Ohne SSL-Inspection freigeben. |
| ausgehend | downloads-global.3cx.com : 443 | Updates, Service Packs, Telefon-Firmware | Immer. |
| ausgehend | rps.3cx.com : 443 | Remote Provisioning von IP-Telefonen | Nur bei RPS-Provisionierung. |
| ausgehend | mailproxy.3cx.com : 443 | E-Mail-Versand (Voicemail, Systemmeldungen) | Immer, wenn der 3CX-Mailproxy genutzt wird. |
| ausgehend | wmr.3cx.net : 443 | WebMeeting und Transkription | Nur bei Videokonferenzen. Rückkanal der Transkription kommt von wmr-in.3cx.net (34.40.92.110). |
| ausgehend | stun2.3cx.com : 3478 UDP | STUN – NAT-Erkennung, Firewall Checker | Bei Betrieb hinter NAT. |
| ausgehend | Apple APNs : 443 · 2197 · 5223 | Push an iOS-Apps | Nur bei iPhone-/iPad-Apps. |
| ausgehend | Google FCM : 443 | Push an Android-Apps | Nur bei Android-Apps. |
Alle 79 Freigaben aus den fünf Szenarien noch einmal am Stück – gruppiert nach Einsatzfall, mit Zweck, Bedingung, Gegenstelle und Verbindlichkeit. Zum Nachschlagen und Abhaken bei der Firewall-Konfiguration.
| Port(s) | Protokoll | Richtung | Zweck & Hinweise | Gegenstelle / Ziel | Status |
|---|---|---|---|---|---|
| A · EINGEHEND zur 3CX-Anlage (selbst gehostet / On-Premise / eigener Cloud-Server) | |||||
| 5060 | UDP | eingehend | SIP-Signalisierung: Registrierung, Anrufaufbau und -abbau (Standardport, unverschlüsselt).Immer, wenn ein SIP-Trunk oder externe Telefone direkt (ohne Tunnel/SBC) mit der Anlage sprechen. Empfehlung: auf die IP-Bereiche des SIP-Providers einschränken, um Scans/Angriffe zu vermeiden. | SIP-Provider / externe Telefone | Pflicht |
| 5060–5061 | TCP | eingehend | SIP über TCP (5060) bzw. SIP über TLS = verschlüsselte Signalisierung (5061).Nur wenn der Trunk oder die Endgeräte SIP über TCP bzw. SIP-TLS statt UDP nutzen. Bei reinem UDP-Trunk nicht nötig. | SIP-Provider / externe Telefone | Bedingt |
| 9000–10999 | UDP | eingehend | RTP – der eigentliche Sprach- und Videostrom (Audio des Gesprächs). Pro Gleichzeitiggespräch werden 2 Ports belegt.Immer bei externem Sprachverkehr ohne 3CX-Tunnel. Der Bereich lässt sich bei wenigen Leitungen verkleinern, muss aber min. 2× die Zahl gleichzeitiger Gespräche fassen. | SIP-Provider / externe Telefone | Pflicht |
| 5090 | TCP UND UDP | eingehend | 3CX-Tunnelprotokoll: kapselt SIP + RTP in einer einzigen Verbindung. Gegenstelle für 3CX SBCs, Apps und 'Router-Phones'.Immer, wenn 3CX SBC, Remote-Apps (Desktop/Smartphone) oder Remote-Telefone genutzt werden. WICHTIG: TCP UND UDP freigeben – nur TCP führt zu Einweg-Audio. | 3CX SBC / Apps (beliebige IP) | Pflicht bei SBC/Apps |
| 443 (alternativ 5001) | TCP | eingehend | HTTPS: Web Client, Management-Konsole, Presence, Provisionierung der Endgeräte, WebRTC.Immer bei Zugriff von außen. 443 ist der Standard ab V20, 5001 der alternative/ältere HTTPS-Port. Muss von 'ANY' erreichbar sein (Homeoffice, Hotel, unterwegs) – nicht auf feste IPs einschränken. | Beliebige Clients (Internet) | Pflicht |
| 443 | TCP | eingehend | Videokonferenz: externe Teilnehmer verbinden sich über den Browser zur Anlage.Nur bei Nutzung von 3CX Meet / Videokonferenzen. Identisch mit dem HTTPS-Port oben – keine zusätzliche Regel, wenn 443 bereits offen ist. | Konferenzteilnehmer (Internet) | Bedingt |
| 443 | TCP | eingehend | Rückkanal des 3CX-Transkriptionsdienstes zur Anlage.Nur wenn Anrufaufzeichnung mit Transkription genutzt wird. Quelle einschränkbar auf wmr-in.3cx.net (34.40.92.110). | wmr-in.3cx.net (34.40.92.110) | Optional |
| 80 | TCP | eingehend | HTTP: Validierung des Let's-Encrypt-Zertifikats (ACME HTTP-01) und Weiterleitung auf HTTPS.Praxisempfehlung für die automatische Zertifikatserneuerung. Von 3CX nicht ausdrücklich als Firewall-Anforderung dokumentiert, in der Praxis aber regelmäßig nötig. | Let's Encrypt / Internet | Empfohlen |
| 5000 | TCP | eingehend | Alternativer HTTP-Port der Anlage (älterer Standard).Nur bei abweichender Portkonfiguration. Achtung laut 3CX: niemals 443 für HTTP und 80 für HTTPS vergeben – sonst arbeiten Firewalls nicht korrekt. | Beliebige Clients | Nur Sonderfall |
| 5062 (in Einzelfällen 5061) | TCP | eingehend | SIP-Signalisierung für Microsoft Teams Direct Routing.Nur bei Teams-Direct-Routing-Integration. Zusätzlich nötig: öffentlicher DNS-A-Record auf eine statische IP und ein Zertifikat einer von Microsoft anerkannten CA. | Microsoft Teams / MS-Cloud | Nur Sonderfall |
| 5015 | TCP | eingehend | Web-Konfigurationsassistent bei der Erstinstallation der Anlage.Nur während der Ersteinrichtung; danach wieder schließen. Nur in Community-Quellen belegt, nicht in der offiziellen Firewall-Doku. | Admin-Arbeitsplatz | Nur bei Setup |
| B · AUSGEHEND von der 3CX-Anlage (selbst gehostet – Ziel: 3CX-Cloud & Provider) | |||||
| 443 | TCP | ausgehend | Lizenzaktivierung und regelmäßige Lizenzprüfung.Immer. ACHTUNG: ohne SSL-/TLS-Inspection freigeben (uninspected) – sonst schlägt die Aktivierung fehl. | activate.3cx.com | Pflicht |
| 443 | TCP | ausgehend | 3CX Discovery-Dienst (FQDN-/Instanz-Auflösung).Immer. Ebenfalls ohne SSL-Inspection freigeben. | discoverv4.3cx.com | Pflicht |
| 443 | TCP | ausgehend | Bezug von Updates, Service Packs und Telefon-Firmware.Immer, damit die Anlage aktualisiert werden kann. | downloads-global.3cx.com | Pflicht |
| 443 | TCP | ausgehend | RPS – Remote Provisioning Service: Fernkonfiguration von IP-Telefonen über die Herstellercloud.Nur wenn Telefone per RPS außerhalb des LAN provisioniert werden. | rps.3cx.com | Bedingt |
| 443 | TCP | ausgehend | E-Mail-Versand (Voicemail-Benachrichtigung, Systemmeldungen, Konferenzeinladungen) über den 3CX-Mailproxy.Immer, wenn der 3CX-Mailserver genutzt wird statt eines eigenen SMTP-Servers. | mailproxy.3cx.com | Pflicht (Standard) |
| 443 | TCP | ausgehend | Push-Dienst der Anlage – weckt die Smartphone-Apps bei eingehenden Anrufen.Immer, wenn Smartphone-Apps genutzt werden. Ohne SSL-Inspection freigeben. | pbxservicespush.3cx.com | Pflicht bei Apps |
| 443 | TCP | ausgehend | WebMeeting-/Videokonferenz-Dienst und Transkription in der 3CX-Cloud.Nur bei Nutzung von Videokonferenzen bzw. Transkription. | wmr.3cx.net | Bedingt |
| 443 | TCP | ausgehend | Push-Benachrichtigungen an Android-Apps über Google Firebase (FCM).Nur wenn Android-Apps genutzt werden. | Google FCM | Bedingt |
| 443, 2197, 5223 | TCP | ausgehend | Push-Benachrichtigungen an iOS-Apps über Apple APNs.Nur wenn iPhone-/iPad-Apps genutzt werden. Alle drei Ports freigeben. | Apple APNs | Bedingt |
| 48000–65535 | UDP | ausgehend | Medienstrom (Audio/Video) der Videokonferenz zwischen Anlage/Teilnehmern und 3CX-Cloud.Nur bei Nutzung von 3CX Meet / Videokonferenzen. | 3CX WebMeeting-Cloud | Bedingt |
| 5060 (bzw. 5061 TLS) | UDP / TCP | ausgehend | SIP-Signalisierung zum VoIP-Provider (Gegenrichtung zum eingehenden Trunk).Immer bei SIP-Trunk. Bei stateful Firewalls meist durch die eingehende Regel abgedeckt, bei restriktivem Outbound-Regelwerk explizit nötig. | SIP-Provider | Pflicht |
| 9000–10999 | UDP | ausgehend | RTP-Sprachdaten zum VoIP-Provider.Immer bei externem Sprachverkehr; bei restriktivem Outbound-Regelwerk explizit freigeben. | SIP-Provider | Pflicht |
| 3478 | UDP | ausgehend | STUN – Ermittlung der öffentlichen IP / NAT-Typ; wird u. a. vom 3CX Firewall Checker verwendet.Bei Betrieb hinter NAT und für den Firewall-Check. Standard-STUN-Server: stun2.3cx.com. | stun2.3cx.com | Empfohlen |
| 53 | UDP / TCP | ausgehend | DNS – Auflösung des eigenen FQDN, der 3CX-Cloud-Dienste und des Providers.Immer. Technisch zwingend, wird von 3CX aber nicht als eigene Firewall-Anforderung dokumentiert. | DNS-Server | Pflicht (technisch) |
| 123 | UDP | ausgehend | NTP – Zeitsynchronisation. Falsche Systemzeit bricht TLS-Zertifikate und Lizenzprüfung.Immer. Technisch zwingend, von 3CX nicht als eigene Firewall-Anforderung dokumentiert. | NTP-Server | Pflicht (technisch) |
| 25 / 587 / 465 | TCP | ausgehend | SMTP direkt zu einem eigenen Mailserver (statt über mailproxy.3cx.com).Nur wenn ein eigener SMTP-Server hinterlegt ist. Port richtet sich nach dem Mailserver (25 = plain, 587 = STARTTLS, 465 = SMTPS). | Eigener SMTP-Server | Optional |
| 2528 | TCP | ausgehend | Alter 3CX-SMTP-Relay-Port für den Mailversand.Nur bei Altsystemen bis V18. Ab V20 läuft der Mailversand über mailproxy.3cx.com auf Port 443 – dann nicht mehr nötig. | 3CX SMTP-Relay | Nur Altsysteme |
| C · STANDORT MIT 3CX SBC / TISCHTELEFONEN (Regeln in der Standort-Firewall) | |||||
| KEINE | — | eingehend | Am Standort mit SBC sind KEINE eingehenden Portfreigaben und KEIN Port-Forwarding nötig.Gilt immer: der SBC baut die Verbindung ausschließlich ausgehend zur Anlage auf. Das ist der Hauptvorteil des SBC gegenüber direkt registrierten Telefonen. | — | Hinweis |
| 5090 | TCP UND UDP | ausgehend | 3CX-Tunnel vom SBC zur Anlage – transportiert SIP-Signalisierung UND RTP-Sprachdaten gebündelt.Immer, wenn ein SBC eingesetzt wird. TCP UND UDP freigeben – nur TCP führt zu Einweg-Audio. | FQDN der 3CX-Anlage | Pflicht |
| 443 (bzw. 5001) | TCP | ausgehend | HTTPS zur Anlage: Provisionierung des SBC und der Telefone, Authentifizierung, Firmware-Updates.Immer. Welcher Port gilt, hängt von der Instanz ab – 443 bei 3CX-gehostet, oft 5001 bei selbst gehosteten Altinstallationen. Im URL der Management-Konsole ablesbar. | FQDN der 3CX-Anlage | Pflicht |
| 53 | UDP / TCP | ausgehend | DNS – Auflösung des FQDN der 3CX-Anlage.Immer. | DNS-Server | Pflicht |
| 123 | UDP | ausgehend | NTP – Zeitsynchronisation für SBC und Telefone.Empfohlen. Telefone können die Zeit alternativ per DHCP-Option beziehen. | NTP-Server | Empfohlen |
| 80 / 443 | TCP | ausgehend | RPS des Telefonherstellers (Yealink, Fanvil, Snom …) beim allerersten Provisioning.Nur bei Erst-Provisionierung fabrikneuer oder auf Werkseinstellung zurückgesetzter Telefone. Im Normalbetrieb nicht nötig. | RPS-Server des Herstellers | Nur bei Erst-Setup |
| 5060 | UDP (ggf. TCP) | nur LAN-intern | SIP zwischen Telefon und SBC im lokalen Netz. Das Telefon nutzt die LAN-IP des SBC als Outbound-Proxy.Immer bei SBC-Einsatz. Bei SBC unter Windows muss die lokale Windows-Firewall diesen Port zulassen. | Telefon → SBC (LAN) | LAN-intern |
| 224.0.1.75 : 5060 | UDP (Multicast) | nur LAN-intern | Plug & Play / Autodiscovery: das Telefon sendet ein SIP-SUBSCRIBE an die Multicast-Adresse 224.0.1.75, der SBC meldet den Fund an die Anlage. 3CX nutzt für PnP KEIN mDNS/5353.Nur für Plug & Play. Funktioniert ausschließlich im selben Layer-2-Segment – nicht über VLAN-/Subnetzgrenzen (siehe Abschnitt F/G). Switch muss unbekannten Multicast fluten bzw. IGMP-Snooping passend konfiguriert sein. | Telefon → 224.0.1.75 (LAN) | LAN-intern |
| kein fester Bereich | UDP | nur LAN-intern | RTP/Medien zwischen Telefon und SBC – der SBC relayt die Sprachdaten in den Tunnel.Immer bei Gesprächen. ACHTUNG: 3CX veröffentlicht für den SBC gegenüber lokalen Telefonen KEINE Portrange (9000–10999 ist die Range des PBX-Medienservers, nicht des SBC). Innerhalb eines Segments unkritisch – relevant erst bei VLAN-Trennung (Abschnitt F). | Telefon ↔ SBC (LAN) | LAN-intern |
| 80 | TCP | nur LAN-intern | CTI / Telefonsteuerung: Steuerung des Tischtelefons durch den 3CX-Client (Legacy-CTI per HTTP-Kommando direkt an die Telefon-IP).Nur beim alten CTI-Modus. Das moderne uaCSTA (V18/V20) steuert das Telefon über die bestehende SIP-Registrierung von der Anlage aus – dann ist keine Client→Telefon-Regel nötig. | Client → Telefon (LAN) | LAN-intern |
| D · VON 3CX GEHOSTETE INSTANZ (3CX-hosted / StartUP – Regeln in der Kundenfirewall) | |||||
| KEINE | — | eingehend | Bei 3CX-gehosteten Instanzen sind in der Kundenfirewall KEINE eingehenden Freigaben nötig.Gilt immer – alle Verbindungen werden vom Kundennetz aus nach außen aufgebaut. Achtung: die Spalte 'eingehend' der 3CX-Doku bezieht sich auf den Server; beim gehosteten Modell entspricht sie AUSGEHENDEN Regeln beim Kunden. | — | Hinweis |
| 5090 | TCP UND UDP | ausgehend | 3CX-Tunnel zur gehosteten Anlage – für SBC, Apps und Router-Phones.Immer, wenn SBC oder Apps im Einsatz sind. | FQDN der gehosteten Anlage | Pflicht |
| 443 | TCP | ausgehend | HTTPS: Web Client, Provisionierung, WebRTC, Videokonferenz.Immer. | FQDN der gehosteten Anlage | Pflicht |
| 9000–10999 | UDP | ausgehend | RTP-Sprachdaten zwischen Endgeräten/Web Client und der gehosteten Anlage.Immer, wenn Telefone oder der Web Client direkt (ohne Tunnel) mit der Anlage sprechen. | FQDN/IP der gehosteten Anlage | Pflicht |
| 5060 (bzw. 5061 TLS) | UDP / TCP | ausgehend | SIP-Signalisierung, wenn sich Telefone direkt bei der gehosteten Anlage registrieren.Nur wenn KEIN SBC/Tunnel genutzt wird. Mit SBC läuft alles über 5090. | FQDN/IP der gehosteten Anlage | Bedingt |
| 48000–65535 | UDP | ausgehend | Medienstrom der Videokonferenz vom Arbeitsplatz zur 3CX-WebMeeting-Cloud.Nur bei Nutzung von Videokonferenzen aus dem Kundennetz heraus. | 3CX WebMeeting-Cloud | Bedingt |
| E · NICHT NÖTIG bei Einsatz von 3CX SBC / Tunnel (bewusst geschlossen lassen) | |||||
| 5060 / 5061 | UDP / TCP | eingehend | SIP – wird bei SBC-Einsatz gekapselt im Tunnel (Port 5090) übertragen.Nicht öffnen, wenn ausschließlich der SBC/Tunnel genutzt wird. Reduziert die Angriffsfläche erheblich. | — | Nicht nötig |
| 9000–10999 | UDP | eingehend | RTP – wird bei SBC-Einsatz ebenfalls im Tunnel übertragen.Nicht öffnen, wenn ausschließlich der SBC/Tunnel genutzt wird. | — | Nicht nötig |
| 3478 | UDP | ausgehend | STUN – am SBC-Standort keine NAT-Traversal-Erkennung nötig, da nur ausgehende Verbindungen aufgebaut werden.Nicht nötig am SBC-Standort (wohl aber ggf. an der Anlage selbst). | — | Nicht nötig |
| F · VLAN-SEGMENTIERUNG bei CLOUD-ANLAGE + SBC vor Ort (Regeln im Layer-3-Switch / der internen Firewall) | |||||
| 5060 | UDP (ggf. TCP) | Inter-VLAN | SIP-Registrierung und -Signalisierung: das Telefon nutzt die LAN-IP des SBC als Outbound-Proxy.Immer, wenn Telefone und SBC in getrennten VLANs liegen. Der SBC lauscht standardmäßig auf 5060/UDP für lokale SIP-Endgeräte. | VLAN 3 (Telefone) → VLAN 2 (SBC) | Pflicht |
| kein dokumentierter Bereich – praktisch UDP 1024–65535 | UDP | Inter-VLAN | RTP/Medien zwischen Telefon und SBC. Der SBC nimmt die Sprachdaten des Telefons an und leitet sie durch den Tunnel zur Cloud-Anlage.Immer bei Gesprächen. ACHTUNG: 3CX veröffentlicht KEINE RTP-Portrange für den SBC gegenüber lokalen Telefonen – die bekannten 9000–10999 gelten für den PBX-Medienserver, nicht für den SBC-Prozess vor Ort. In der Praxis den dynamischen UDP-Bereich gezielt zur SBC-IP freigeben. | VLAN 3 (Telefone) → VLAN 2 (SBC) | Pflicht |
| 5060 + ephemere UDP-Ports | UDP | Inter-VLAN | Rückrichtung von SIP und RTP vom SBC zum Telefon.Bei stateful Firewalls durch die Hinregel abgedeckt. Nur bei rein statischen ACLs (z. B. auf einem Layer-3-Switch ohne Session-Tracking) explizit freigeben. | VLAN 2 (SBC) → VLAN 3 (Telefone) | Bedingt |
| 224.0.1.75 : 5060 | UDP (Multicast) | Inter-VLAN | Plug & Play / Autodiscovery der Telefone durch den SBC (SIP-Multicast, NICHT mDNS/5353).FUNKTIONIERT NICHT über VLAN-Grenzen. Multicast ist ohne Multicast-Routing nicht routbar, ein mDNS-Repeater/Reflector hilft nicht (der reflektiert nur 224.0.0.251:5353). 3CX bezeichnet PnP über VLANs ausdrücklich als nicht unterstützt. Lösung: SBC ins Telefon-VLAN stellen ODER DHCP Option 66 / RPS / manuelle Provisioning-URL nutzen. | VLAN 3 → VLAN 2 (nicht routbar) | Nicht möglich |
| 443 (alt: 5001) | TCP | Inter-VLAN / ausgehend | Provisionierung und Firmware: die Telefone holen ihre Konfiguration DIREKT bei der Cloud-Anlage – der SBC ist kein Provisioning-Server und hat keine Web-GUI.Immer. Das Telefonie-VLAN benötigt zwingend ausgehenden Internetzugang auf 443/TCP zum FQDN der Anlage – sonst provisioniert kein Telefon. Bei 3CX-Hosting ist HTTP+IP nicht möglich, nur HTTPS+FQDN. | VLAN 3 (Telefone) → Internet / PBX-FQDN | Pflicht |
| 53 | UDP / TCP | Inter-VLAN | DNS – Auflösung des PBX-FQDN durch die Telefone (bei HTTPS-Provisionierung zwingend, eine IP genügt nicht).Immer. Freigabe zum internen Resolver bzw. ins Internet. | VLAN 3 → DNS-Resolver | Pflicht |
| 123 | UDP | Inter-VLAN / ausgehend | NTP – Zeitsynchronisation der Telefone. 3CX provisioniert per Default pool.ntp.org.Immer. Ohne korrekte Zeit scheitert die TLS-/Zertifikatsprüfung bei der Provisionierung. | VLAN 3 → NTP-Server / Internet | Pflicht |
| 67 / 68 (DHCP-Relay) | UDP | Inter-VLAN | DHCP-Relay bzw. 'ip helper-address' im Telefonie-VLAN: Adressbezug und Übergabe von Option 66 (Provisioning-URL) bzw. Option 132/133 (VLAN-ID/Priorität).Immer, wenn der DHCP-Server nicht im Telefonie-VLAN steht. Option 66 ist bei VLAN-Trennung der empfohlene Ersatz für PnP. Achtung: Option 66 überschreibt PnP – nicht beides parallel betreiben. | VLAN 3 → DHCP-Server | Pflicht |
| 80 | TCP | Inter-VLAN | Legacy-CTI: der 3CX-Client am Arbeitsplatz schickt HTTP-Kommandos direkt an die IP des Tischtelefons.Nur beim alten CTI-Modus. Geroutet über VLANs funktionsfähig (Routing + Portfreigabe genügen), auch wenn 3CX 'gleiches Netz' schreibt. Beim modernen uaCSTA (V18/V20) NICHT nötig – dort steuert die Anlage das Telefon über die SIP-Registrierung. | VLAN 1 (Clients) → VLAN 3 (Telefone) | Bedingt |
| KEINE | — | Inter-VLAN | Die 3CX Desktop-/Web-Apps müssen den SBC NICHT erreichen – sie registrieren sich direkt bei der Cloud-Anlage.Gilt immer. Der SBC ist ausschließlich für IP-Tischtelefone gedacht. Keine Freigabe Clients → SBC nötig. | VLAN 1 (Clients) → VLAN 2 (SBC) | Nicht nötig |
| 80 / 443 | TCP | Inter-VLAN | Weboberfläche der Telefone für den administrativen Zugriff.Optional, nur wenn Admins aus dem Daten-/Management-VLAN auf die Telefon-Weboberflächen zugreifen sollen. | Management-VLAN → VLAN 3 (Telefone) | Optional |
| 443 / 80 | TCP | ausgehend | RPS des Telefonherstellers (Yealink/Fanvil/Snom) beim Erstboot fabrikneuer Geräte.Nur bei RPS-Provisionierung. Bei VLAN-Trennung häufig der praktikabelste Weg, weil PnP entfällt. Zieladressen der Hersteller sind von 3CX nicht dokumentiert. | VLAN 3 (Telefone) → Internet | Nur bei Erst-Setup |
| G · VLAN-SEGMENTIERUNG bei INTERN GEHOSTETER 3CX-Anlage (Regeln im Layer-3-Switch / der internen Firewall) | |||||
| 5060 | UDP + TCP | Inter-VLAN | SIP-Registrierung und -Signalisierung der Tischtelefone zur Anlage.Immer. UDP ist der Default-Transport; TCP zusätzlich, wenn Telefone auf SIP/TCP konfiguriert sind. | VLAN 3 (Telefone) → VLAN 2 (3CX) | Pflicht |
| 5061 | TCP | Inter-VLAN | SIP über TLS – verschlüsselte Signalisierung.Nur wenn SIP/TLS und SRTP im Einsatz sind. | VLAN 3 (Telefone) → VLAN 2 (3CX) | Bedingt |
| 9000–10999 | UDP | Inter-VLAN | RTP/Audio zwischen Telefon und Medienserver der Anlage. 2 Ports pro Gespräch.Immer. WICHTIG: 3CX kennt nur EINEN Medienserver-Bereich – er gilt intern wie extern und ist nicht offiziell konfigurierbar. Gespräche zwischen zwei Telefonen im selben VLAN laufen direkt Endpunkt-zu-Endpunkt und queren die Grenze nicht. | VLAN 3 (Telefone) ↔ VLAN 2 (3CX) | Pflicht |
| 443 (alt: 5001) | TCP | Inter-VLAN | HTTPS: Provisionierung der Telefone, Firmware, Telefonbuch. Es gibt KEINEN separaten Provisioning-Port – es ist der Webserver-Port der Anlage.Immer. Welcher Port gilt, wurde bei der Installation festgelegt (443 empfohlen, 5001 als Alternative). | VLAN 3 (Telefone) → VLAN 2 (3CX) | Pflicht |
| 80 (alt: 5000) | TCP | Inter-VLAN | HTTP-Provisionierung über die IP-Adresse der Anlage.Nur wenn eine HTTP-Provisioning-URL verwendet wird. Von 3CX ausschließlich für lokale Telefone in RFC1918-Netzen zugelassen – Remote-Telefone müssen HTTPS+FQDN nutzen. | VLAN 3 (Telefone) → VLAN 2 (3CX) | Bedingt |
| 5060 (SIP-Port des Telefons) | UDP / TCP | Inter-VLAN | Gegenrichtung: die Anlage sendet SIP NOTIFY an die Telefone – 'check-sync' (Neustart/Reprovisionierung), 'ua-profile', BLF-Statusaktualisierungen und MWI (Voicemail-Lampe).Immer. Wird oft vergessen und äußert sich darin, dass Reprovisionierung, BLF-Tasten und die Voicemail-Anzeige nicht funktionieren. Der Server pusht keine Konfiguration – das Telefon holt sie nach dem NOTIFY selbst ab. | VLAN 2 (3CX) → VLAN 3 (Telefone) | Pflicht |
| RTP-Bereich des Telefons (herstellerabhängig) | UDP | Inter-VLAN | Rückrichtung des RTP-Stroms: die Anlage sendet aus 9000–10999 an den RTP-Port des Telefons (z. B. Yealink ~11780–11800, Snom ab 49152).Bei stateful Firewalls durch die Hinregel abgedeckt. Bei rein statischen ACLs den RTP-Bereich der eingesetzten Telefone im Handbuch nachschlagen und freigeben. | VLAN 2 (3CX) → VLAN 3 (Telefone) | Bedingt |
| 443 (alt: 5001) | TCP | Inter-VLAN | Web Client und Desktop App: HTTPS + WebSocket, Anmeldung, Presence, Client-Updates.Immer, wenn Arbeitsplätze in einem eigenen VLAN liegen. | VLAN 1 (Clients) → VLAN 2 (3CX) | Pflicht |
| 9000–10999 | UDP | Inter-VLAN | WebRTC-Medien des Softphones im Web Client / in der Desktop App.Immer, wenn die Clients im Softphone-Modus telefonieren. (Der WebRTC-Anteil liegt praktisch im Teilbereich 10500–10999 – nicht offiziell dokumentiert, nicht als Filterkriterium verwenden.) | VLAN 1 (Clients) → VLAN 2 (3CX) | Pflicht |
| 5090 | TCP + UDP | Inter-VLAN | 3CX-Tunnel – wird intern normalerweise nicht benötigt, da der Web Client WebRTC über 443 nutzt.Optional. 3CX äußert sich nicht dazu, ob 5090 intern gebraucht wird. Die Freigabe ist unschädlich und erspart Fehlersuche, falls ein Client in den Tunnel-Modus fällt. | VLAN 1 (Clients) → VLAN 2 (3CX) | Optional |
| 80 | TCP | Inter-VLAN | Legacy-CTI: der 3CX-Client schickt HTTP-Kommandos direkt an die IP des Tischtelefons.Nur beim alten CTI-Modus. Geroutet über VLANs funktionsfähig. Beim modernen uaCSTA nicht nötig – dort läuft die Steuerung über die SIP-Registrierung von der Anlage aus. | VLAN 1 (Clients) → VLAN 3 (Telefone) | Bedingt |
| 224.0.1.75 : 5060 | UDP (Multicast) | Inter-VLAN | Plug & Play / Autodiscovery der Telefone durch die Anlage (SIP-Multicast, NICHT mDNS/5353).FUNKTIONIERT NICHT über VLAN-Grenzen – 3CX nennt 'Telefon und Anlage im selben lokalen Subnetz' als PnP-Voraussetzung und rät von PnP über VLANs ausdrücklich ab. Ersatz: DHCP Option 66, manuelle Provisioning-URL, RPS oder ein SBC im Telefonie-VLAN. | VLAN 3 → VLAN 2 (nicht routbar) | Nicht möglich |
| 53 | UDP / TCP | Inter-VLAN | DNS – und zwar zwingend mit SPLIT-DNS: der FQDN der Anlage muss in JEDEM VLAN auf die interne Server-IP auflösen.Immer. Löst ein VLAN den FQDN auf die öffentliche IP auf, trägt die Anlage die öffentliche IP ins SDP ein und der Sprachverkehr läuft per NAT-Hairpin über die Firewall – typische Folge: einseitiges Audio. 3CX V20 setzt Split-DNS On-Premise zwingend voraus. | Alle VLANs → DNS-Resolver | Pflicht |
| 123 | UDP | Inter-VLAN | NTP – Zeitsynchronisation von Telefonen und Clients.Immer. Falsche Zeit führt zu Zertifikatsfehlern und falschen Anrufzeiten. | VLAN 1 + VLAN 3 → NTP-Server | Pflicht |
| 67 / 68 (DHCP-Relay) | UDP | Inter-VLAN | DHCP-Relay bzw. 'ip helper-address' im Telefonie-VLAN – Adressvergabe und Option 66 (Provisioning-URL) bzw. 132/133 (VLAN-ID/Priorität).Immer, wenn der DHCP-Server nicht im Telefonie-VLAN steht. Option 66 ist bei VLAN-Trennung der empfohlene Ersatz für PnP. | VLAN 3 → DHCP-Server | Pflicht |
| 443 (alt: 5001) | TCP | Inter-VLAN | Zugriff auf die Management-Konsole der Anlage.Immer, wenn Administration aus einem Management-VLAN erfolgt. | Management-VLAN → VLAN 2 (3CX) | Pflicht |
| 22 | TCP | Inter-VLAN | SSH – Administration des Debian-Betriebssystems (V20 läuft ausschließlich auf Debian 12; RDP/3389 entfällt, Windows wird nicht mehr unterstützt).Optional, für OS-Administration. Von 3CX nicht in einer Portliste dokumentiert. Zugriff möglichst auf das Management-VLAN begrenzen. | Management-VLAN → VLAN 2 (3CX) | Optional |
| 5015 | TCP | Inter-VLAN | Web-Konfigurationsassistent bei der Erstinstallation.Nur temporär während der Ersteinrichtung, danach wieder sperren. | Management-VLAN → VLAN 2 (3CX) | Nur bei Setup |
| 80 / 443 | TCP | Inter-VLAN | Weboberfläche der Telefone für den administrativen Zugriff. Die Anlage selbst greift NICHT darauf zu – der Link öffnet sich im Browser des Admins.Optional, nur für administrativen Zugriff aus dem Management-/Daten-VLAN. | Management-VLAN → VLAN 3 (Telefone) | Optional |
| 443 | TCP | ausgehend | Ausgehende Verbindungen der Anlage zu den 3CX-Cloud-Diensten (siehe Abschnitt B) – vom Server-VLAN ins Internet.Immer. Bei segmentierten Netzen daran denken, dass auch das Server-VLAN einen Weg ins Internet braucht. | VLAN 2 (3CX) → Internet | Pflicht |
Der „SIP Helper“ in Router und Firewall manipuliert SIP-Pakete und ist die häufigste Ursache für Einweg-Audio und abbrechende Gespräche. In jedem Szenario abschalten.
Nur TCP freigegeben? Dann kommt der Tunnel zustande, das Audio läuft aber nur in eine Richtung. Immer beide Protokolle freigeben.
activate.3cx.com, discoverv4.3cx.com und pbxservicespush.3cx.com müssen uninspected passieren – TLS-Aufbrechen lässt Aktivierung und Push fehlschlagen.
Mitarbeiter verbinden sich aus Homeoffice, Hotel und Mobilfunknetz. Nur die SIP-Ports (5060/5061) lassen sich sinnvoll auf die IPs des Providers einschränken.
Pro gleichzeitigem Gespräch werden 2 UDP-Ports belegt. Der Standardbereich 9000–10999 deckt bis zu 1.000 Gespräche ab.
Mit einem 3CX SBC am Standort entfallen sämtliche eingehenden Freigaben: SIP und RTP laufen gekapselt über den ausgehenden Tunnel auf Port 5090.
Die 3CX-Doku listet Ports aus Sicht des Servers. Bei einer von 3CX gehosteten Anlage werden daraus in Ihrer Firewall ausgehende Regeln – eingehend ist nichts nötig.
Nach der Konfiguration den 3CX Firewall Checker laufen lassen: Er prüft die Anlagen-Seite und meldet fehlende Freigaben und aktives SIP-ALG.
3CX nutzt für die Telefonerkennung SIP-Multicast (224.0.1.75:5060) – kein mDNS. Multicast ist nicht routbar: Bei VLAN-Trennung stattdessen DHCP Option 66 oder RPS provisionieren.
Verständlich. Wir konfigurieren Firewall und Anlage in einem Zug – inklusive SIP-ALG-Kontrolle, Firewall-Checker-Lauf und sauberer Dokumentation der Regeln. Als WatchGuard- und 3CX-Partner kennen wir beide Seiten. Sprechen Sie uns an.
Bei einer selbst gehosteten Anlage eingehend: 5060/UDP (SIP), 5061/TCP (SIP-TLS), 9000–10999/UDP (RTP-Sprachdaten), 5090/TCP+UDP (3CX-Tunnel für Apps und SBC) und 443/TCP (HTTPS, Web Client, Provisionierung). Dazu kommen ausgehende Freigaben zu den 3CX-Cloud-Diensten. Die vollständige Liste nach Szenario finden Sie oben im Technikbereich.
Nur ausgehende: 5090/TCP+UDP (Tunnel zur Anlage), 443/TCP (Provisionierung) sowie DNS und NTP. Eingehende Freigaben oder Port-Weiterleitungen sind am SBC-Standort nicht nötig – der SBC baut alle Verbindungen selbst nach außen auf.
In der Kundenfirewall ausschließlich ausgehende Regeln: 5090/TCP+UDP, 443/TCP, 9000–10999/UDP und – ohne SBC – 5060/UDP zum FQDN der Anlage. Eingehend muss nichts geöffnet werden.
Die beiden häufigsten Ursachen: SIP-ALG ist im Router oder in der Firewall noch aktiv, oder Port 5090 wurde nur für TCP statt für TCP und UDP freigegeben. Danach den 3CX Firewall Checker laufen lassen.
Nein. Die Telefonerkennung nutzt SIP-Multicast an 224.0.1.75:5060, und Multicast ist ohne Multicast-Routing nicht routbar. In segmentierten Netzen provisionieren Sie stattdessen über DHCP Option 66, den RPS des Telefonherstellers – oder stellen den SBC ins Telefonie-VLAN.
Nein. Zwischen V18 und V20 sind keine Änderungen an den Firewall-Ports dokumentiert; der RTP-Bereich bleibt 9000–10999/UDP. Neu ist lediglich, dass 443 statt 5001 der Standard-HTTPS-Port ist.
Als 3CX- und WatchGuard-Partner konfigurieren wir Anlage und Firewall in einem Zug – sauber dokumentiert und mit dem Firewall Checker verifiziert.