istike2
Goto Top

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.

Content-Key: 258564

Url: https://administrator.de/contentid/258564

Printed on: April 19, 2024 at 04:04 o'clock

Member: aqui
aqui Dec 27, 2014 at 19:46:01 (UTC)
Goto Top
Member: istike2
istike2 Dec 28, 2014 updated at 10:51:57 (UTC)
Goto Top
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.
Member: aqui
Solution aqui Dec 29, 2014 updated at 13:37:01 (UTC)
Goto Top
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 !
Member: istike2
istike2 Dec 29, 2014 at 13:39:22 (UTC)
Goto Top
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.
Member: aqui
aqui Dec 29, 2014 at 16:12:14 (UTC)
Goto Top
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 ?!
Member: istike2
istike2 Jan 02, 2015 at 12:56:00 (UTC)
Goto Top
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...