Kein eingehender Audio Stream bei der Nutzung von Windows App und Webclient im VPN

[o.hintzsche]

Hallo zusammen,

wie führen derzeit eine 3CX bei uns im Unternehmen ein und sind voller Vorfreude bzgl. der Erleichterung in der Arbeit im Homeoffice und zur Verbesserung unserer Erreichbarkeit für unsere Kunden. Wir haben auch alle Anforderungen weitestgehend umsetzen können und sind im Grunde glücklich. Jedoch haben wir noch ein massives Problem bei der Nutzung der Windows App und/oder dem Webclient im VPN, welches ich kurz schildern möchte.

• Windows App / Webclient von extern per FQDN (öffentliche IP) -> Verbindung per HTTPS und 3CX Tunnel (5090 UDP/TCP) -> 3CX Server -> zu Extensions und/oder externer Rufnummer = kein Problem
• Windows App / Webclient in internen Netzen per FQDN (interne IP) -> Verbindung per HTTPS und 3CX Tunnel (5090 UDP/TCP) -> 3CX Server -> zu Extensions und/oder externer Rufnummer = kein Problem
• Windows App / Webclient in einem VPN Netzwerk per FQDN (interne IP) -> Verbindung per HTTPS und 3CX Tunnel (5090 UDP/TCP) -> 3CX Server -> keine eingehender Audiostream , ausgehender Audiostream von Remote Extension oder externen Gesprächspartner vorhanden

Ich denke das solch ein Konstrukt nicht einzigartig ist und bitte daher um eure Hilfe, Tipps und Tricks.

 

[nobody]

Ich habe das Problem so gelöst, dass ich mit einer Firewallregel die Verbindung über das mit VPN angebundenen Netzwerk zur 3CX Telefonanlage verbiete. Dann muss der Client den 3CX tunnel verwenden.
Sicher könnte man das auch anders manchen, aber die Zuverlässigkeit und vermutlich auch die Qualität der Telefonie ist ohne VPN besser.

 

[bitn2]

Ist in der Firewall der Port auch vom internen Netz ins VPN Netz freigegeben?

 

[o.hintzsche]

Ist in der Firewall der Port auch vom internen Netz ins VPN Netz freigegeben?

Meines Erachtens Bedarf es keiner bidirektionalen Freischaltung. Die Ports 443 und 5090 sind vom VPN zur 3CX geöffnet. Dieselbe Regel nutzen wir für die Kommunikation aus anderen Netzsegmenten (internal IP's) wo es erstaunlicherweise sauber funktioniert.

Beispiel:

1) AP im lokalen Client-Netz A 192.168.1.0/24 -> lokales 3CX VOIP Netz 192.168.2.0/24 - funktioniert problemlos, kann externe Rufnummer sowie die IP-Tischtelefone im 3CX VOIP Netz 192.168.2.0/24 erreichen und/oder Softphones auf AP im lokalen Client-Netz 192.168.10.0/24

2) AP im lokalen Client-Netz A 192.168.20.0/24 -> lokales 3CX VOIP Netz 192.168.2.0/24 - Audio Probleme, kann zwar externe Rufnummer sowie die IP-Tischtelefone im 3CX VOIP Netz 192.168.2.0/24 erreichen und/oder Softphones auf AP im lokalen Client-Netz 192.168.10.0/24 erreichen (Signalisierung geht) aber höre nur den Angerufenen, mich als hört man nicht.

Alle beiden Netzwerke im Beispiel sind in derselben Firewallregel konfiguriert.

 

[bitn2]

Hmm, ich würde da trotzdem mal gucken ob irgendwo was geblockt wird. Ansonsten mal mit "PBX überträgt Audio" rumspielen.

 

[David.K]

Hmm, ich würde da trotzdem mal gucken ob irgendwo was geblockt wird. Ansonsten mal mit "PBX überträgt Audio" rumspielen.

Ganau das "PBX überträgt Audio" bei mindestens einer Nebenstelle funktioniert bei uns.

Ist da noch ein Rauschen zu hören oder ist es ganz still im Problemfall?

 

[o.hintzsche]

In dem beschriebenen Fall ist es ganz Still.

"PBX überträgt Audio" müsste ich aufgrund der vielen Wechsel zwischen Büro und Homeoffice, Dienstreise dann bei jeder Nebenstelle aktivieren. Ist dies wirklich so gut, habe in den Schulungen und Beiträgen hier im Forum vernommen, dass dies suboptimal wäre bzgl. der Qualität und Last.

 

[David.K]

In dem beschriebenen Fall ist es ganz Still.

"PBX überträgt Audio" müsste ich aufgrund der vielen Wechsel zwischen Büro und Homeoffice, Dienstreise dann bei jeder Nebenstelle aktivieren. Ist dies wirklich so gut, habe in den Schulungen und Beiträgen hier im Forum vernommen, dass dies suboptimal wäre bzgl. der Qualität und Last.

Wir haben hier 35 Nebenstellen. Und bei allen ist die Option an.
Die Gesprächsqualität leidet schon etwas aber es geht.
Mit Traffic ist halt so ne Sache. Bei unseren 8SC spielt das gar keine Rolle da intern auch wenig telefoniert wird.

Ohne "PBX überträgt Audio" verbinden die Clients die RTP-Pakete untereinander direkt. (So mein Wissensstand)

Das war bei uns...

https://www.3cx.de/forum/threads/3-nebenstellen-im-homeoffice-h%C3%B6ren-sich-nicht.97787/#post-318134

 

[o.hintzsche]

Ohne "PBX überträgt Audio" verbinden die Clients die RTP-Pakete untereinander direkt. (So mein Wissensstand)

Das ist korrekt, daher ja die Nutzung des 3CX Tunnel.
Die Media Ports (UDP Highports) und der SIP Port 5060 sind wissentlich per Firewall blockiert. Der Client baut auch sauber einen 3CXTunnel per Port 5090 auf. In allen Netzen funzt dies, ausser im VPN.
Bei 125 Nebenstellen und den verschiedenen Nutzendszenarien (Remote per IO's App, intern per IP Telefon und Softphone gemischt sowie Softphone per VPN) ist "PBX überträgt Audio" denke ich die schlechteste Variante.

 

[o.hintzsche]

Wie gesagt für 8 von 10 unserer Anbindungsszenarien funktioniert unser Setup.

 

[David.K]

Hast du alle Media Ports zum Testen mal geöffnet?
Wir brauchen auch nicht bei allen Nebenstellen diese Option - verwirrend.

 

[nobody]

Meines wissens wird der Tunnel nicht verwendet, wenn die Telefonanlage direkt ueber die interne IP Adresse erreichbar ist.
Und dann hat man die ganzen lästigen Probleme die SIP mit sich bringt.

 

[o.hintzsche]

Hallo zusammen,

nach weiterführender Fehleranalyse sind wir zu der Erkenntnis gekommen, dass das von uns überlegte Design und Nutzungsszenario funktioniert. Wir haben uns eine alternative VPN-Einwahl geschaffen (openVPN) und konnten erfolgreich mit dem Softphone telefonieren, nachdem wir die Konfiguration vollständig auf FQDN umgestellt haben.

Damit konnten wir die Ursache auf die VPN Anbindung per Citrix Client und unseren Netscaler beschränken. Wir untersuchen dieses Thema weitere, was sich jedoch als herausfordernd erweist, da ich aktuell null Pakete per Wireshark ausfindig machen.

Wenn jemand Erfahrungen und Hinweise hat, bin ich offen für diese.

 

[nobody]

Richtig: Wenn Du alles mit dem FQDN machst, dann wird der tunnel verwendet, und dann gibt es auch keine Probleme mit RTP und Sip.
Wireshark, geraten: Dass Du keine Pakete siehst könnte daran liegen, dass Du ein split VPN hast, und der windows Client nun alles über die externe IP port 5090 macht.