6
3CXPhone Clients hinter Firewall mit 3CX Tunnel
Hallo,
wir arbeiten hier mit 3CX VoIP-Server der draußen gehostet wird und die Clients des Büros hinter NAT / Pfsense sind.
ich hatte mal wertvolle Hinweise zu diesem Thema bekommen: PfSense VoIP-Ports manuell einrichten
Ich habe es auch so umgesetzt: Fritzbox mit DECT vor PfSense, Fritzbox mit WLAN nach PfSense.
Aktuell haben wir aber den Bedarf, dass auch Softphones der unterschiedlichen Notebooks telefonieren können, die sich hinter Firewall befinden. Aus diesem Grund haben wir angefangen 3CXPhone-Clients einzusetzen, die mit sog. 3CXTunnel auf den Server zugreifen können. Mit diesem Tunnel besteht die Möglichkeit, dass du den Port 5090 alle VoIP Traffic umgeleitet werden kann. Wenn ich also richtig verstehen sind Ports für RTP nicht notwendig.
Hat jemand Erfahrung wie die beiden Ports 5060 und 5090 geöffnet werden sollen?
- Sowohl LAN als auch WAN?
- Muss 5090 auf den jeweiligen Client geroutet werden?
- Wenn ja was mache ich mit mehrere Clients?
Wenn jemand mit 3CX Clients hinter Firewall Erfahrungen hat, wäre ich für Hinweise dankbar.
Ein weiteres Problem ist, dass der Router sich nach wie vor hinterm SFR Router befindet. Ich habe dabei zwei Optionen:
- ich kann die interne LAN IP des Routers im Modem als DMZ einstellen (der Router wird dadurch von Draußen frei zugänglich)
- Ich kann die entsprechenden Ports vom Modem (5060, 5090) auf die LAN-interne IP des pfSense routen.
Aktuell sind auf pfSense alle Ports in beide Richtungen offen, Client kann sich anmelden, es klingelt bei Testanrufen aber beide Seiten hören nichts, während des Telefonats. PfSense war dabei als DMZ eingerichtet, der Modem hatte also keinen aktiven NAT.
Wie würdet ihr es machen?
Danke für die Tipps.
Gr. I.
wir arbeiten hier mit 3CX VoIP-Server der draußen gehostet wird und die Clients des Büros hinter NAT / Pfsense sind.
ich hatte mal wertvolle Hinweise zu diesem Thema bekommen: PfSense VoIP-Ports manuell einrichten
Ich habe es auch so umgesetzt: Fritzbox mit DECT vor PfSense, Fritzbox mit WLAN nach PfSense.
Aktuell haben wir aber den Bedarf, dass auch Softphones der unterschiedlichen Notebooks telefonieren können, die sich hinter Firewall befinden. Aus diesem Grund haben wir angefangen 3CXPhone-Clients einzusetzen, die mit sog. 3CXTunnel auf den Server zugreifen können. Mit diesem Tunnel besteht die Möglichkeit, dass du den Port 5090 alle VoIP Traffic umgeleitet werden kann. Wenn ich also richtig verstehen sind Ports für RTP nicht notwendig.
Hat jemand Erfahrung wie die beiden Ports 5060 und 5090 geöffnet werden sollen?
- Sowohl LAN als auch WAN?
- Muss 5090 auf den jeweiligen Client geroutet werden?
- Wenn ja was mache ich mit mehrere Clients?
Wenn jemand mit 3CX Clients hinter Firewall Erfahrungen hat, wäre ich für Hinweise dankbar.
Ein weiteres Problem ist, dass der Router sich nach wie vor hinterm SFR Router befindet. Ich habe dabei zwei Optionen:
- ich kann die interne LAN IP des Routers im Modem als DMZ einstellen (der Router wird dadurch von Draußen frei zugänglich)
- Ich kann die entsprechenden Ports vom Modem (5060, 5090) auf die LAN-interne IP des pfSense routen.
Aktuell sind auf pfSense alle Ports in beide Richtungen offen, Client kann sich anmelden, es klingelt bei Testanrufen aber beide Seiten hören nichts, während des Telefonats. PfSense war dabei als DMZ eingerichtet, der Modem hatte also keinen aktiven NAT.
Wie würdet ihr es machen?
Danke für die Tipps.
Gr. I.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 258564
Url: https://administrator.de/forum/3cxphone-clients-hinter-firewall-mit-3cx-tunnel-258564.html
Ausgedruckt am: 13.04.2025 um 03:04 Uhr
6 Kommentare
Neuester Kommentar
Danke sehr Aqui,
In dem Artikel geht es um die FW-Einstellungen des Servers und nicht die der Clients. Die muessen etwas anders eingerichtet werden. Die haben nicht mal dann funktioniert als ich die die FW deaktiviert habe. ich vermute mal, dass bestimmte Ports im NAT fest auf die Clients umgeleitet werden müssen. Aber welche? Die 5060, 5090 oder die für RTP?
Gr. I.
In dem Artikel geht es um die FW-Einstellungen des Servers und nicht die der Clients. Die muessen etwas anders eingerichtet werden. Die haben nicht mal dann funktioniert als ich die die FW deaktiviert habe. ich vermute mal, dass bestimmte Ports im NAT fest auf die Clients umgeleitet werden müssen. Aber welche? Die 5060, 5090 oder die für RTP?
Gr. I.
ich vermute mal, dass bestimmte Ports im NAT fest auf die Clients umgeleitet werden müssen. Aber welche?
Jein, SIP nutzt dynamische Ports beim Verbindungsaufbau, das ist die Crux. Die SIP Antwortpakete nutzen einen Random Port und den lässt die NAT Firewall dann nicht durch.Als Lösung müsste man eine riesige Range an Ports an der Firewall freigeben, was dann die FW als solches vollkommen konterkariert, da sie damit ja dann quasi nutzlos geworden ist !
Die Lösung lautet STUN ! Definiere einfach einen STUN Server oder aktiviere STUN, das löst das Problem.
http://de.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT
Idealerweise supportet deinen FW ggf. ALG (Application Layer Gateway) kann also intelligent mit solchen Protokollen wie SIP umgehen. Die FW "merkt" dann wenn SIP durch sie durchgeht und erkennt das aktiv und öffnet dann selektiv den Random Port.
Bei Voice sollte man immer auf solche Features achten wie STUN oder ALG !
Danke Aqui,
ich habe versehentlich das "gelöst" Button gedrückt, es ist aber noch nicht gelöst.
STUN ist bei dem 3CX-Server standardmäßig eingerichtet und ist bei allen 3CXPhone Client standard. Es geht trotzdem nicht.
Ich versuche mal Januar den Support zu erreichen ...
Gr. I.
ich habe versehentlich das "gelöst" Button gedrückt, es ist aber noch nicht gelöst.
STUN ist bei dem 3CX-Server standardmäßig eingerichtet und ist bei allen 3CXPhone Client standard. Es geht trotzdem nicht.
Ich versuche mal Januar den Support zu erreichen ...
Gr. I.
Es geht trotzdem nicht.
Das kann eigentlich niemals sein ! Das würde bedeuten das sich deine NAT Firewall nicht standardkonform verhält ?! Bei einer pfSense nicht wirklich glaubwürdig.... rennt hier zu SIPGate und T-Com fehlerlos intern über einen SPA-112 z.B.Dann musst du vermutlich doch den Kabelhai mal drauf loslassen und dir ansehen WAS genau da vor oder hinter der NAT FW passiert ?!
Ich habe mal meinen Händler beuaftragt. WS hat ergeben, dass STUN in Tunnel-Modus nicht greift.
Als Direkt-SIP hat es funktioniert. LAN-seitig mussten wir Port 9000-9049 öffnen.
So war es Ok...
Als Direkt-SIP hat es funktioniert. LAN-seitig mussten wir Port 9000-9049 öffnen.
So war es Ok...
