3CX v20 On-Prem: Mobile Clients & VPN-User offline trotz erfolgreichem Firewall Check

[ni_ox]

Hallo zusammen,

Vorab-Hinweis:
Leider war es mir nicht möglich, das Thema in einer passenderen Kategorie zu erstellen.

Umgebung / Lizenz​

• Lizenz: 3CX PRO 8 SC
• Upgrade: von Version 18 auf Version 20
• Betriebsart: On-Premise
• Serverbetriebssystem: Windows Server 2019

Aktueller Funktionsstatus​

• Die Telefonanlage ist grundsätzlich funktionsfähig:
  
  • Interne Softphones sind registriert
  • DECT-Endgeräte sind angebunden und funktionsfähig
• Externe Telefonie (Inbound) funktioniert erwartungsgemäß:
  
  • Eingehende Anrufe von extern werden korrekt signalisiert
  • Nebenstellen sind von außen erreichbar

Problembeschreibung​

Seit dem Upgrade auf 3CX v20 treten Probleme mit Endgeräten außerhalb des internen Netzwerks auf.
Diese Konstellationen haben vor dem Upgrade fehlerfrei funktioniert.


Konkret betroffen:

• Mobile Endgeräte:
  
  • Registrierung über QR-Code schlägt fehl
  • Fehlermeldung: TLS-Fehler
• Notebooks über VPN-Anbindung:
  
  • Client verbleibt im Status „grau / nicht verbunden“
  • Kein Zugriff auf Kontakte

Netzwerk / Firewall​

• Firewall: WatchGuard Firebox
• Konfiguration:
  
  • SNAT-Regeln für 3CX eingerichtet
  • Entsprechende Firewall-Policies zur Portfreigabe konfiguriert
• 3CX Firewall Check:
  
  • Wird vollständig und ohne Fehler abgeschlossen

Vielen Dank vorab für die Unterstützung!
ni_ox

 

[mbehrens]

• Mobile Endgeräte:
  
  • Registrierung über QR-Code schlägt fehl
  • Fehlermeldung: TLS-Fehler
• Notebooks über VPN-Anbindung:
  
  • Client verbleibt im Status „grau / nicht verbunden“
  • Kein Zugriff auf Kontakte

Scheinbar fehlerhafte Konfiguration von Firewall/DNS/fester IP.

 

[fxbastler]

Kann man sich von WAN per FQDN problemlos auf dem 3CX Webinterface als Systemeigentümer anmelden? Kommen auch da Zertifikatfehler im Browser?

Wichtig zu wissen (weil es eben oft vergessen wird): der 3CX Firewall Checker überprüft ausschließlich die benötigten UDP Ports der 3CX. Das Webinterface und die Erreichbarkeit dessen ist somit nicht dabei.

Seit dem Upgrade auf 3CX v20 treten Probleme mit Endgeräten außerhalb des internen Netzwerks auf.
Diese Konstellationen haben vor dem Upgrade fehlerfrei funktioniert.

Wann genau ist das Upgrade auf 3CX v20 erfolgt?

Wenn wirklich erst jetzt erst von v18 auf v20 aktualisiert wurde, dann war das mehr als zu spät. Das hätte schon Mitte vorigen Jahres erfolgen sollen (EOL Debian), spätestens Ende 09/2025. Gibt es noch ein vollständiges 3CX Backup der v18 von vor der Umstellung vor wenigen Tagen?

 

[ni_ox]

Kann man sich von WAN per FQDN problemlos auf dem 3CX Webinterface als Systemeigentümer anmelden? Kommen auch da Zertifikatfehler im Browser?

Wichtig zu wissen (weil es eben oft vergessen wird): der 3CX Firewall Checker überprüft ausschließlich die benötigten UDP Ports der 3CX. Das Webinterface und die Erreichbarkeit dessen ist somit nicht dabei.


Wann genau ist das Upgrade auf 3CX v20 erfolgt?

Wenn wirklich erst jetzt erst von v18 auf v20 aktualisiert wurde, dann war das mehr als zu spät. Das hätte schon Mitte vorigen Jahres erfolgen sollen (EOL Debian), spätestens Ende 09/2025. Gibt es noch ein vollständiges 3CX Backup der v18 von vor der Umstellung vor wenigen Tagen?

Vielen Dank für die schnellen Antworten.

Ja, es gibt noch das v18 Backup und ja, es ist erst vor kurzem erfolgt.

/e: zum Postnr. 1 - ja, da gehe ich auch von aus. Was ich jedoch nicht verstehe, warum deine Änderung der Softwareversion ein solches Problem darstellt, da dies auch vorher funktionierte und an dem Routing ansonsten nicht viel verändert wurde.

Ich habe lediglich zusätzlich die Ports geöffnet, die zusätzlich erforderlich waren.

Nein, ich komme zum aktuellen Zeitpunkt nicht auf das Webinterface. Ich gehe stark davon aus, dass es überwiegend ein Routing Problem ist, leider konnte ich es zum aktuellen Zeitpunkt nicht identizifieren.

Die Telefonanlage läuft in Ihrer Umgebung und verweist ja auf den SIP-Trunk.
Was mich auch damals schon gewundert hat: im Intranet verweist FQDN auf die Telefonanlage im Internet zeigt der gleiche FQDN auf den SIP-Trunk. Bisher hatte ich mich nicht getraut das externe anzufassen, da die Umstellung bei den Domains ja doch einen kurzen Moment dauert, um es kurzfristig auszuprobieren.

 

[bitn2]

Nutzt du einen eigenen FQDN oder 3cx? Aber dein Problem hast du schon gefunden. Ohne Erreichbarkeit der PBX, keine externen Geräte.

 

[fxbastler]

im Internet zeigt der gleiche FQDN auf den SIP-Trunk.

Wenn du mit SIP-Trunk den Provider meinst: das ist nicht richtig. Der FQDN soll von WAN aus auf die öff. IP der 3CX (bzw. des Router davor) verweisen.

 

[ni_ox]

Wir nutzen einen eigenen FQDN.
Also für mein Verständnis: FQDN muss einheitlich auf die Telefonanlage zeigen, lediglich die Telefonanlage muss auf den SIP-Trunk zeigen, oder?

 

[fxbastler]

Also für mein Verständnis: FQDN muss einheitlich auf die Telefonanlage zeigen, lediglich die Telefonanlage muss auf den SIP-Trunk zeigen, oder?

richtig, das war schon immer so™
Auflösung des FQDN von WAN aus auf die öff. IP der 3CX, Auflösung des FQDN von LAN aus auf die int. (LAN) IP der 3CX (Split DNS).

Nachtrag:
Wir haben aktuell ausschließlich on-prem 3CX bei Kunden im Einsatz, alles ENT, alles Debian, alles eigene FQDN. Bei 3CX auf Windows Basis wird eine ENT vorausgesetzt, bin mir nicht sicher ob das nicht gar mind. auch eine 16 SC sein muss.

 

[ni_ox]

Das bedeutet, wir müssten die Lizenz aufrüsten, damit es unter Windows überhaupt wieder annähernd an den alten Status rankommt? bzw. alternativ auf eine Linux Maschine umstellen?

 

[fxbastler]

Das bedeutet, wir müssten die Lizenz aufrüsten, damit es unter Windows überhaupt wieder annähernd an den alten Status rankommt?

ja

bzw. alternativ auf eine Linux Maschine umstellen?

ja

Gibt es einen speziellen Grund weswegen das eine Windows 3CX ist? Läuft die 3CX physisch auf Hardware (steht nirgends und es wurde noch nicht explizit danach gefragt)?

 

[ni_ox]

Jein, ist nahezu ausschließlich eine Windows-Landschaft. Vermutlich hat man sich da bisher nicht rangetraut.
Auch dadurch hatte ich bisher nicht mehr Linux Kontakt. Aber wenn das der einzige Weg ist, schaue ich mir das mal an.

Wobei ich tatsächlich sagen muss, an sich läuft die Telefonanlage ja, allerdings gibt es mit den Verbindungen dahin (die besprochenen) Schwierigkeiten. Ist das dann tatsächlich ein Lizenz-Problem?

 

[fxbastler]

... allerdings gibt es mit den Verbindungen dahin (die besprochenen) Schwierigkeiten. Ist das dann tatsächlich ein Lizenz-Problem?

Grundsätzlich nein soweit ich weiss. Das mit der ext. Auflösung des eigenen FQDN ist völlig unabhängig davon und sollte bei euch schon immer (zumindest seitdem das so besteht) ein Problem gewesen sein.
Wenn der Zugriff auf das Webinterface der 3CX per VPN auch nicht funktioniert, dann ist das entweder iOS (eine vor vielen Monaten umgesetzte Änderung bzgl. DNS Auflösung und ein seitdem bekanntes Problem) oder der VPN Tunnel ist nicht richtig eingerichtet (Split DNS funktioniert dann nicht duchgehend).

Ganz ehrlich: eine Debian 3CX ist langfristig gesehen einiges pflegeleichter und braucht weniger Ressourcen. Ich habe ausschließlich für eigene Spielereien eine 3CX dauerhaft auf einem Windows Server 2019 in Betrieb. Sonst haben wir noch nirgends einen Grund gefunden der das rechtfertigen würde.

 

[ni_ox]

Dann schau ich mir die Debian Variante mal an - viel an Einrichtung sollte ja ohnehin nicht notwendig sein.
Feste IP zuweisen, sofern ich die gleiche nehme, wie die aktuelle müssten ohnehin alle Regeln greifen. Ich such mir mal eine Anleitung als Begleitung raus und probiere es damit mal aus.

Ansonsten kann ich ja auch die Datensicherung zurück lesen und bin ungefähr an dem aktuellen Stand dran. Oder ich könnte von der v20 ein Backup ziehen und das in der Debian Umgebung zurücklesen, oder spricht da was gegen?

 

[fxbastler]

Oder ich könnte von der v20 ein Backup ziehen und das in der Debian Umgebung zurücklesen

Ja, so wird es üblicherweise gemacht. Vorausgesetzt man bleibt bei den für produktiven Betrieb freigegebenen 3CX Versionen (aktuell 3CX v20 u7 b10180) sind keine Schwierigkeiten absehbar.
Notiere dir vorher alle genutzten 3CX Ports, sieh zu dass nicht beide 3CX gleichzeitig in Betrieb sind, halte das eigene Zertifikat und den Key bereit, installiere irgendwann auch ntp und (meine persönliche Empfehlung) deaktiviere IPv6 auf der Debian 3CX.

spricht da was gegen?

nein, außer es wird weitere (i.d.R. nicht von 3CX unterstützte) Software auf der Windows 3CX verwendet oder es wird aktiv Powershell auf der Windows 3CX verwendet. Letzteres ist einer der ganz wenigen Gründe für Windows, weil es von Hause aus dabei ist.

 

[ni_ox]

Sehr gut. Ich würde auch auf dem neusten Stand bleiben. Auch wenn die aktuelle Lage das nicht unterstreicht.

Die Liste der Ports habe ich ja bereits in der Firewall konfiguriert - die müsste damit einhergehen?

Dann teste ich das aus, vielen Dank für die Unterstützung. Ich mache mich dann ans Werk und melde mich bei Komplikationen erneut.

Ich würde auch gerne mich auch gerne durch die Like/Danke Funktion bedanken, allerdings wird mir leider keine Option dazu angezeigt.

 

[bitn2]

 

[ni_ox]

Vielen Dank, sowas habe ich erwartet:

 

[bitn2]

Vielen Dank, sowas habe ich erwartet:

Anhang anzeigen 19644

Das ist in der Tat interessant, hab ich noch nie gesehen oder gehabt...

 

[fxbastler]

Die Liste der Ports habe ich ja bereits in der Firewall konfiguriert - die müsste damit einhergehen?

ja, das sollte auf jeden Fall gleich sein. Nur dass in der Firewall der HTTP Port evtl. nicht vermerkt ist. In der Fw wird vmtl. nur HTTPS, SIP(S), Tunnel und RTP drin stehen - sollte es zumindest. Im Backup ist das grds. auch nicht enthalten.
Wie geschrieben: hol dir die Daten aus der 3CX, man weiss ja nie ..

 

[mbehrens]

Das bedeutet, wir müssten die Lizenz aufrüsten, damit es unter Windows überhaupt wieder annähernd an den alten Status rankommt?

Das hat lizenzrechtliche Gründe.

bzw. alternativ auf eine Linux Maschine umstellen?

Ja, tut auch gar nicht weh.