V18 Videokonferenz und Port 5001/443

[moellerheide]

Hallo,

wir haben mit der V18 Probleme mit den Videokonferenzen. Wir haben die 3CX mit dem "Standard" https Port 5001 aufgesetzt und haben Webmeetings bisher gerne genutzt.
Seit V18 laufen die Videokonferenzen ja direkt über die 3CX-Adresse, also https://xxx.my3cx.de:5001/...
Das ist intern kein Problem, da wir aber oft externe Teilnehmer in Schulen oder in Firmen haben bei denen per default 5001 ausgehend geblockt ist können wir die neuen Videokonferenzen nicht mehr nutzen.

Ich sehe im Moment 3 Möglichkeiten:
a) alle externen Partner überzeugen, dass 5001 kein böses Voodoo ist und in der Firewall freigeschaltet wird
b) die 3CX auf Port 443 umlegen
c) einen reverse-proxy der von 443 auf 5001 weiterleitet

a) ist nahezu aussichtslos, da wir hier über dutzende - und vorallem externe - Partner reden.
b) finde ich auch nicht so richtig "klasse", da wir über 700 Nebenstellen haben und alle Mitarbeiter die Apps neu einrichten müssen und ich auch die 13SBCs anpassen muss
c) wäre am charmantesten, da auf der externen ipv4 noch ein anderer Webserver läuft. Ich habe das schonmal mal erfolglos versucht - damals wollte ich aber alles von 5001 auf 443 abbilden - jetzt würde mir ja schon eine Teilfunktionalität (Videokonferenz) reichen.

Wie sind eure Erfahrungen mit den neuen Videokonferenzen und der Port 5001 Problematik?
Gibt es noch eine andere Variante?
Wie sind eure Erfahrungen bei einer nachträglichen Änderung des https Ports von 5001 auf 443 ?

Viele Grüße
Michael Möller

 

[bitn]

Hallo Michael,

ja diese Umstellung das die Webmeeting URL nun über die URL der eingerichteten 3CX läuft ist echt ein Problem.
Selbst wenn man es hinbekommt mit dem Reverse Proxy was nicht supportet und unterstützt wird von 3CX. Hat man danach noch das Problem das Die Einladungen ja trotzdem mit dem bei der Installation vergebenen Port in diesem Fall 5001 versendet werden.
Weiterhin hat man das Problem das ein Proxy ja nicht die Ursprüngliche IP durchreicht sondern eine Interne IP und dadurch kann die interne 3CX Firewall die IP dann nicht blacklisten bei Fehlerhaften Anmeldungen.
In meinen Augen kommt man wohl nicht drum rum auf 443 umzustellen um die externen User glücklich zu machen.

Beste Grüße

 

[stefanb]

Ja. Und leider "windet" sich der 3CX-Support aus der Verantwortung.

Wir stehen vor dem selben Dilemma.

 

[moellerheide]

Mein größtes Problem sind 14 Kunden die nur über eine ipv4 Adresse verfügen (kein ipv6) und parallel einen E-Mailserver auf dem Anschluss betreiben. Natürlich mit Webinterface und activesync - da ist 443 schon belegt, eine Portänderung bei der 3CX auf 443 ist also gar nicht möglich...

Ich werde doch mal versuchen einen reverse-proxy aufzusetzen - wenn ich das richtig sehe läuft ja "nur" das Management über die lokale 3CX - die Media-Streams laufen nach wie vor über die 3CX Server.

Den richtigen und wichtigen Hinweis von bitn bezgl. der blacklists würde ich dann im 2. Schritt mittels fail2ban versuchen in den Griff zu kriegen.

Dann noch ein script welches die ausgehenden Mails umschreibt.... super...

Ich verstehe die Produktpolitik auch nicht: einerseits ist die 4SC in allen Varianten zumindest im ersten Jahr kostenlos und das ganze läuft auf einem Raspberry Pi -> also aus meiner Sicht ganz klar als Appetizer für kleine Firmen (z.B. Arztpraxis) - und dann schließt man genau diese Zielgruppe mit der V18 aus, weil die 3CX jetzt exklusiv auf 443 sitzen will.

 

[avraammich_3CX]

Von 3CX Benutzer den 3CX HTTPs FQDN : PORT ausgehend öffnen zu 3cx Phone System
Von Externen Teilnehmer 3CX HTTPs FQDN: Port ausgehend öffnen zu 3cx Phone System.

Es muss nicht unbedingt 5001 oder 443 für https Port benutzt werden im Setup der Installation.

Es kann ein X beliebiger Port verwendet werden auf dem kein anderen Dienst läuft.

 

[moellerheide]

Das Problem ist, das bei externen Partnern wie im ersten Post beschrieben (Schulen, Firmen, Kommunale Verwaltungen) i.d.R. alles außer 80/443 gesperrt ist. Bisher war das mit dem 3CX Server via 443 alles machbar - jetzt geht das nicht mehr. Ob ich 5001, 12001 oder sowas nehme spielt keine Rolle -> das muss schon 443 sein, damit das bei ALLEN Kunden funktioniert. Wir haben z.B. eine kommunale Verwaltung die 3CX Chat im Kundenverkehr eingesetzt hat. Das kann ich auf :5001 nicht mehr brauchen, da ich damit einige Kunden ausklammere (bei denen 5001 ausgehend gesperrt ist oder Webtraffic 443 über einen Proxy läuft).

Die Idee alles zum Kunden zu verlagern (eine URL für alles) finde ich ja nicht schlecht, aber die Umstellung wirft mehr Probleme als Vorteile auf. Schön wäre es gewesen hier eine Wahlmöglichkeit zu haben - so wie bei dem FQDN - durch 3CX oder selbst verwaltet.

Optional würde mit eine Reverse-Proxy Option reichen -> aber so ist das ein KO Kriterium für viele Kunden die nur eine ipv4 IP haben.

 

[fxbastler]

Mit haproxy und SNI (ohne offload) geht das, erst letztens kurz getestet. Das gefällt uns aber nicht, da einige Dienste SSL Offloading im haproxy + weitere Behandlung benötigen. Bei Nutzung des haproxy und der Option SSL Offload hatte irgendwas auf Anhieb nicht funktioniert und uns fehlte da gerade die Zeit um dem nachzugehen. Mal schaun ob das die nächsten Tage noch mal klappt.

 

[Marco Bollow]

Gibt es hierzu eigentlich eine nennenswerte Lösung? Das Problem liegt er weiterhin auf der Hand

 

[moellerheide]

Ich löse das bei unseren Kunden mittlerweile konsequent durch das Vorschalten eines nginx sni proxy. Ist zwar nicht ganz unaufwendig, funktioniert aber (bis jetzt) zuverlässig.

 

[fxbastler]

Wir stellen seit geraumer Zeit alle Kunden - neue Anlagen / sofern die Notwendigkeit bzgl. Videokonferenzen besteht / so wie gerade Zeit übrig ist - auf haproxy mit SSL Offloading um (wg. paralleler Nutzung mit Exchange, Cloud Lösungen, Video Server Lösungen, Alarmanlagen, Zabbix usw. sowie div. Filtern), d.h. weg von SNI. Das funktioniert gut, keine Einschränkungen bisher. Das sind alles ausschließlich pfSense Installationen, funktioniert aber auch problemlos mit opnSense. Das läuft i.d.R. mit LE Zertifikaten und autom. Upload in die Firewall für deren haproxy, manchmal auch andersrum (Generierung der LE Zertifikate in der Firewall und Verteilung auf die Server + Dienste).
Ja, die Einrichtung ist ein gewisser Aufwand.