Webmeetingport 443 TCP

[joshi]

Hallo zusammen!

Ich habe gerade ein Verständnisproblem. Was mache ich im NAT bzw. Firewall mit dem eingehenden Port 443 TCP im Kontext zum Webmeeting?

Grundsätzlich funktioniert das Webmeeting, wenn ich ein Webmeeting von der Firma oder von mir zu Hause im Homeoffice aus starte. Wenn allerdings der Außendienst versucht ein Webmeeting vom Homeoffice aus mit einem Kunden durchzuführen, funktioniert es nicht. Die Kollegen berichten, dass die Gegenseite sich im Meeting "einwählen" kann, aber es kommt keine Audioverbindung zu stande. Ob Video übertragen wird, kann ich nicht sagen, weil wir nicht darüber gesprochen haben. Ist auch erstmal sekundär.

Wenn ich allerdings in ein Webmeeting mit dem Außendiesnt gehe, klappt es immer ohne Probleme. Also gehe ich davon aus, dass im Kundennetzwerk irgendetwas geblockt wird. Aber was? Wenn dann der Kunde ein Teams-Webmeeting startet, funzt dies. Teams scheint also kundenseitig irgendwie "freigeschaltet" zu sein. Nur halt 3cx-Webmeeting nicht.

Nun habe ich natürlich keinen Zugriff auf das Kundennetzwerk und der Kunde weiß natürlich auch keine Einzelheiten zum Firmennetzwerk. Die IT wird aber auch kaum für uns irgendetwas an ihrer Config ändern.

Also was könnte die Ursache sein?

Ich lese halt was von Port 443 TCP. Unsere Firewall lässt diesen Port bidirectional durch. Eine Weiterleitung durch NAT haben wir nicht eingerichtet. Die Beschreibungen dazu verstehe ich nicht so richtig.

Kann jemand was zu dem Thema sagen?

EDIT:
Der Lancom ist nach Anleitung eingestellt.

 

[bitn2]

Welchen HTTPS Port nutzt eure 3CX denn? Dieser wird auch für das Webmeeting genutzt.

 

[mbehrens]

Ich lese halt was von Port 443 TCP. Unsere Firewall lässt diesen Port bidirectional durch. Eine Weiterleitung durch NAT haben wir nicht eingerichtet. Die Beschreibungen dazu verstehe ich nicht so richtig.

EDIT:
Der Lancom ist nach Anleitung eingestellt.

Das widerspricht sich irgendwie.

 

[joshi]

Der 3cx-https-Port ist auf 5001 eingestellt.

@mbehrens Wieso widerspricht sich das? Der 5001 ist seitens der NAT durchgelassen und die FW ist auf dem Port auch frei. Der 443 ist eingehend nicht vom Internet errreichbar. Raus geht's über den 443 natürlich schon.

Wie auch immer. Ich suche halt nach Erklärungen, warum das Webmeeting mit Kunden nicht funktioniert. Hat ja vielleicht gar nichts mit dem 443 zu tun?!?!

 

[bitn2]

Nein hat es dann auch nicht, Port 5001 ist dann der Port fürs Webmeeting und der wird ausgehend beim Kunden geblockt sein.

 

[fxbastler]

Genau das Problem macht Schule, von Tag zu Tag mehr.

Deswegen rüsten wir inzwischen bei allen Anlagen den HTTPS Port auf 443 um. Davor kommt i.d.R. ein Reverse Proxy (ist fast überall vorhanden) weil die Kunden eben nicht alle mehrere öffentliche IP haben und eben nicht nur einen Dienst an ihrem Port 443 betreiben.

Wir nutzen i.d.R. haproxy, bei HTTPS aktuell bei den meisten noch per SNI Identifikation. Das funktioniert bisher problemlos (aber gefällt uns nicht). Wir fahren aktuell bei zwei Anlagen den haproxy als Reverse Proxy per HTTPS offload an Port 443. Das ist nicht ganz intuitiv, Bisher (einige wenige Monate) funktioniert das reibungslos (Webmeeting, Status der NSt. u.a.). Wenn es dabei bleibt werden alle bisher noch laufenden 3CX v16 und die schon umgestellten v18 wohl damit betrieben.

 

[joshi]

Ach so... der 5001 müsste dann auch beim Kunden ausgehend frei gemacht werden?!!? Ja, dann wird es das sein. Privat (also im Homeoffice) hat man i.d.R. keine ausgehende Beschränkung (auch wenn es z.B. über die AVM-Kindersicherung gehen würde). Und deshalb klappt es da immer. Und bei Firmen gibt es "immer" einen Beschränkung bei ausgehendem Netzwerkverkehr.

Deshalb wäre der Port 443 anstatt dem 5001 viel sinnvoller gewesen. Kann man das nachträglich umstellen? Oder zieht das einen Rattenschwanz hinter sich her?

 

[fxbastler]

@joshi
Ja, bei einer Neuinstallation / Wiederherstellung, siehe Anleitung. Wichtig ist ein aktuelles, gut funktionierendes Backup ausserhalb der 3CX.
Thema Port 443, siehe auch mal hier.

 

[mbehrens]

Der 3cx-https-Port ist auf 5001 eingestellt.

@mbehrens Wieso widerspricht sich das? Der 5001 ist seitens der NAT durchgelassen und die FW ist auf dem Port auch frei. Der 443 ist eingehend nicht vom Internet errreichbar. Raus geht's über den 443 natürlich schon.

Wie auch immer. Ich suche halt nach Erklärungen, warum das Webmeeting mit Kunden nicht funktioniert. Hat ja vielleicht gar nichts mit dem 443 zu tun?!?!

Port 443 ist eingehend erlaubt (wohin auch immer ohne NAT), es findet kein NAT statt aber der LANCOM ist nach Anleitung eingericht.

 

[joshi]

Sehr interessant, dass es das Thema hier schon gab. Hatte es bei meiner Suche nicht auf Anhieb gefunden.

Ich will es jetzt nicht auf dem Produktivsystem ausprobieren, aber würde es reichen bei der bestehenden Anlage einfach eine Wiederherstellung anzuwerfen, und man kann in dem Zuge den Port umstellen? Oder muss es zwangweise ein leeres System sein, auf dem man die Wiederherstellung macht?

Mir fällt gerade noch was ein. Könnte man nicht auch im Lancom den eingehenden Port 443 auf 5001 mappen. Dann müsste man natürlich noch im Einladungslink den 5001 entfernen. Dann müsste es doch laufen, oder? Der Port 443 ist bei uns nämlich nicht belegt.

@mbehrens Ja, du hast recht. Hatte mich nicht richtig ausgedrückt.

 

[fxbastler]

@joshi
- mach ein Backup
- sichere dir das vollständig irgendwohin
- log dich in der 3CX Debian Shell ein
- leere die 3CX Einrichtung mit /usr/sbin/3CXWizard --cleanup
- Rest nach Anleitung, Link s.o.

Könnte man nicht auch im Lancom den eingehenden Port 443 auf 5001 mappen. Dann müsste man natürlich noch im Einladungslink den 5001 entfernen. Dann müsste es doch laufen, oder?

Nein, danach wird so einiges nicht mehr funktionieren.

 

[joshi]

@fxbastler hmmm...? Auch nicht, wenn die eigentliche Weiterleitung von Port 5001 erhalten bleibt? Also zusätzlich 443 -> 5001 mappen?

Danke für Deine obige Erklärung. Werde das zunächst bei mir zu Hause testen. Wenn's Probleme gibt, gehe ich einfach auf den Snapshot zurück, den ich vorher erstelle. Ich liebe Virtualisierungen

 

[fxbastler]

Auch nicht, wenn die eigentliche Weiterleitung von Port 5001 erhalten bleibt? Also zusätzlich 443 -> 5001 mappen?

Das würde vmtl. schon funktionieren - rein technisch gesehen. Sofern die eigene 3CX MCU ist. Das ist ja prinzipiell kein asymmetrisches Routing. Der Router leitet - je nach Vermögen - die Anfragen von eingehend Port 443 an 5001 der 3CX weiter und auf Grund dieser Session natted der Router das zurück. Der Status u.a. würde ja auch so übertagen werden. Habe das noch nie probiert oder gar in Erwägung gezogen.

Organisatorisch funktioniert das eher nicht. Die Konferenz E-Mails und deren Links werden automatisch und individualisiert generiert. Da einfach 'irgendwie' das :5001 zu entfernen (bei einer E2E Verschlüsselung) wird vmtl. ein Problem. Insbesonders bei spontanen Konferenzen und / oder ab einer gewissen Menge an Teilnehmern. Ein E-Mail Zwangsproxy mit Offloading, dem gleichen Zertifikat und einem Relay Skript welche das verarbeitet wäre eine sehr krude Lösung - aber wer will das schon. Irgend etwas wird sicher nicht funktionieren.

 

[joshi]

OK, dann werde ich die Anlage ordentlich von Port 5001 auf 443 ändern. Danke für Deine Erklärung.