Webclient wird durch falschen STUN-Server geleitet

[drh8ball]

Hallo zusammen, mein erster Beitrag, und dann gleich so ein Hammer.
Ich weiß nicht mehr weiter ...
Wir haben unsere 3CX neu installiert, hinter einer OPNSense Firewall, der Firewall Checker markiert auch alles als erfolgreich.
SNOMs werden provisioniert, und können auch telefonieren, und hören auch alles, und werden gehört.
Die 3CX App wird auch richtig provisioniert. Kann auch anrufen, und Audio in beide Richtungen.

Aber...

Der Webclient macht Probleme.
Ich kann mich ohne Probleme beim Webclient über die externe URL anmelden, sehe auch all meine Gruppenmitglieder mit Status. Ich kann Rufnummer eingeben, wählen, klingelt auch beim angerufenen, Aber ich kann nicht sprechen, auch nicht hören.
Ich habe dazu mal einen Trace mit Wireshark gemacht (hänge ich auf Anfrage auch gerne noch an, habe ich aber gerade nicht griffbereit) dieser zeigt an dass er als Stun-Server die IP-Adresse der 3CX hinter der Firewall haben will, was ja nicht gehen kann. ist dann eine 192.168.XXX.XXX, die wird ja erst gar nicht ins Internet geroutet.

Wie kann ich den Webclient dazu bewegen über die externe URL zu gehen?

Sollte ich mich komisch ausgedrückt haben, fragt gerne noch mal nach.

Vielen Dank schon mal fürs Lesen.

Daniel

 

[bitn2]

Das hört sich eher danach an als wenn Dein Headset im Browser nicht erlaubt ist. Hast Du Audio entsprechend freigegeben im Browser?

 

[AristotelisK_3CX]

Hallo,

was verwendest du für ein Web-Browser?

Hast du das echo Service *777 probiert?

 

[drh8ball]

Es liegt nicht am Headset. Dann würde er sagen er hat kein Mikrophon gefunden, und baut keinen Ruf auf. Am gleichen PC mit dem gleichen Headset funktioniert der Ruf über die 3CX App. Sogar eine in einem Androidsimulator installierte 3CX-Android-App mit dem gleichen Headset funktioniert. Und wie gesagt ... im Trace wird die falsche IP angezeigt.

 

[drh8ball]

Echo Service auch ohne Ergebnis

 

[bitn2]

Es liegt nicht am Headset. Dann würde er sagen er hat kein Mikrophon gefunden, und baut keinen Ruf auf. Am gleichen PC mit dem gleichen Headset funktioniert der Ruf über die 3CX App. Sogar eine in einem Androidsimulator installierte 3CX-Android-App mit dem gleichen Headset funktioniert. Und wie gesagt ... im Trace wird die falsche IP angezeigt.

Die App hat ja aber nichts mit dem Browser zu tun, da mal prüfen ob Audio erlaubt ist. Anderen Browser testen kann auch nicht schaden.

 

[drh8ball]

hier ein Screenshot vom Wireshark, der zeigt dass es nicht am Mikrophon liegt.
Ein Test in Firefox, bei dem beim ersten Anruf die Frage kommt ob ich den Zugriff auf das Mikrofon zulassen will, war auch ohne Ton

 

[avraammich_3CX]

Hi drh8basl.

läuft der Firewall Checker erfolgreich durch?
Du verbindest dich mit FQDN URL Webclient oder interne IP?
Das Pcap ist auf dem server oder auf dem Client?
wie es aussieht bekommst du keine Responses zurück nur request.
Dieses deutet auf Firewall problem.
Web RTC ports sind von 10500 und abwärts.

 

[drh8ball]

Der Firewall Checker läuft erfolgreich durch.
Ich verbinde mich mit dem https://fq.dn:5001/webclient.
Das Capturing war auf dem Client.
Ich kann keine Response zurück bekommen, weil er ja die interne IP-Adresse nehmen will, statt der externen.

 

[avraammich_3CX]

starte auch gleichzeitig ein pcap auf dem Server.

Wenn das pcap auf dem Client ist solltest du Public IP von der Anlage als ziel Request bekommen.
Option WebRTC-Softphone in 3CX-Webclient/Browser-Erweiterung sowie zugehörige Funktionen (WordPress-Plug-in und Konferenzeinwahl-Integration) aktivieren auf der Anlage unter Dashboard->Einstellungen->Allgemein sit aktiviert?

 

[drh8ball]

Da ist doch genau das Problem. für alles was per Config provisioniert wird, werden die Server richtig gesetzt, nur für den Webclient nicht.
Und ja, Die Optionen sind gesetzt. Ich werde mich jetzt mal in ein VPN rein hängen, dann wird es auch mit der Audioübertragung klappen. Aber das ist als Lösung für unsere Mitarbeiter nicht tragbar.

 

[drh8ball]

Ja, mit VPN geht es. Also muss es ja daran liegen dann er die interne IP Adresse an den Client weiter gibt.
Auf der Firewall läuft ein HAProxy falls das noch wichtig ist. Wobei es bei allen anderen Clients ja auch funktioniert .

 

[fxbastler]

Die Tischtelefone benutzen den SIP Port (5060 UDP/TCP Standard) und die RTP Ports (9000-10499 UDP Standard) für Audio (secure SIP tickt ein klein wenig anders). Die App benutzt den Tunnel Port Port (5090 TCP und UDP Standard) und wenn geht den Web Port (5001 TCP Standard). Der Webclient benutzt den Web Port (5001 TCP Standard) und einen Teil der RTP Ports (10500-10999 UDP Standard, WebRTC, ein Schreibfehler bei avraammich?). Siehe auch hier und in dem Bild unten, man möge mich gern korrigieren.

Daher auch die Situation dass die Tischtelefone und auch die 3CX App funktionieren aber die Webclients nicht. Das sieht nach Firewall Problem aus.

Kann es sein du behandelst den 5001 durch haproxy? Ich habe das noch nicht komplett erfolgreich funktionierend für alles Erforderliche geschafft und lasse das sein.

 

[bitn2]

Das ist ne gute Idee... Der Proxy haut Dir da wahrscheinlich dazwischen, da solltest Du mal die Einstellungen überprüfen.

 

[drh8ball]

Naja, wenn der Webclient den FQDN benutzen würde wäre ja alles gut. Schließlich bekomme ich auch den Status meiner Gruppe und alles andere angezeigt.

 

[bitn2]

Schalte doch mal den Proxy für den FQDN aus und teste es mal, dann weisst Du ob es daran liegt.

 

[drh8ball]

Das kann ich schon machen, heute Nacht. Aber zum Verständnis:
https geht über HAProxy in das Webinterface der Anlage.
alle anderen verwendeten Ports werden per eingehendem NAT an die Anlage geforwarded.

Ich werde mal noch an meinem Linux-PC per IPTables Pakete an 192.168.17.164 an den FQDN erzwingen. Wenn es dann geht, dann liegt es immer noch daran dass dem WEBClient falsche Optionen mitgegeben werden

 

[bitn2]

Du bist momentan relativ alleine mit dem Problem, deswegen vermute ich weiterhin den HA Proxy. Ich kenne und nutze selber Proxys für meine Dienste und wenn man etwas nicht richtig konfiguriert hat, dann nimmt er die interne und nicht die externe IP und das ist ja genau das was bei Dir passiert.

 

[bitn2]

Als Tip für die Suche, da sollte der X-Forwarded-For Header für zuständig sein.