Eigener FQDN / CompanyFlex ohne funktion.

[itip]

Hi,

wir wollten heute unseren CompanyFlex Telekom Anschluss anbinden. Dabei mussten wir feststellen das es scheinbar nicht möglich ist, wenn der Server über eine eigenen FQDN verfügt.

Wir haben insgesamt drei Anlagen. Alle sind selbst gehostet, alle haben einen eigenen FQDN. Den CompanyFlex haben wir nur auf einer Anlage, die anderen beiden mussten nur zum testen herhalten.

A – Debian 10 - Lokal auf EXSI

B – Debian 10 - Gehostet bei Hetzner

C – Debian 10 – Gehostet bei Hetzner

Alle drei Anlagen sind mit dem Google DNS ausgestattet. Es geht um die Anlage C. Hier wollten wir heute einen CompanyFlex Trunk hinzufügen. Dieser Verbindet sich gar nicht, es wird nicht einmal der Versuch unternommen. „Anmeldung gesendet“ und „Anmeldung OK“ bleibt leer.

Daraufhin haben wir den Trunk auf den anderen beiden Anlagen getestet und hatten das gleiche Fehlerbild.

Anschließend haben wir die Anlage C durch apt-get remove –purge… entfernt und mit einem Test Key erneut installiert. Diesmal haben wir einen durch 3CX zugewiesenen FQDN genommen. Hier hat sich der Trunk sofort verbunden. VServer, Hardware, DNS bliebt alles gleich wie mit dem eigenen FQDN.

Daraufhin haben wir diesen Schritt wiederholt, nur haben wir dieses mal wieder unseren eigenen FQDN genommen. Frische Installation, kein Backup. Auch hier wieder keine Funktion. Diese Konstellation haben wir mehrfach durchgespielt, mit der 3CX ISO, mit einem Debian 10 und dem manuellen Hinzufügen der 3CX Repository.

Kurz gesagt, es gab keinen Unterschied in den Anlagen bis auf den eigenen FQDN. Wir haben sämtliche Optionen verglichen und auch Kontakt zur Telekom gehabt, um herauszufinden ob eventuell bestimmte FQDNs gesperrt werden. Und den Trunk wiederholt an unseren anderen Anlagen getestet. Am Ende bliebt für uns nur ein Nenner:

„Hat die Anlage einen eigenen FQDN, funktioniert der CompanyFlex Trunk nicht“

Hat hier jemand schon mal ähnlich Erfahrung gemacht und eine Idee dazu. So komisch das auch klingt, sobald wir einen FQDN von 3CX nehmen, klappt es auf Anhieb mit dem Trunk, was ist hier anders? Andere Trunks funktionieren problemlos, unter anderem ein Telekom NGN.

Gruß

 

[fxbastler]

Hallo @itip
Danke für die Info, das erklärt es. Ja, wir haben die gleiche Erfahrung gesammelt, aber noch lange nicht alle Möglichkeiten und Szenarien ausgereizt. Morgen ist Portierungstag zu einem anderen Provider, das ist unsere Lösung.

 

[itip]

Ich denke wir haben die Lösung gefunden. In einer neuen Anlage mit 3CX FQDN ist unter „Sicherheit“ Secure SIP aktiv. Mit einem eigenen FQDN ist diese Option nicht aktiv bzw. bei uns nicht aktiv.

Sobald wir diese Option auf der Testanlage deaktivieren, geht der Trunk Offline und zeigt das gleiche Fehlerbild. Wir sind davon ausgegangen, dass diese Option für die Verbindung Client<->3CX notwendig ist und nicht für die SIP-Trunks.

Ob das aktiveren auf der produktiven Anlage des Rätsel Lösung ist, können wir nicht sagen da dafür die Services auf der Anlage neu gestartet werden müssen. Das geht gerade nicht

Eine Info dazu haben wir im Forum oder der Dokumentation nicht gefunden, was nicht bedeuten soll das es die Info nicht gibt.

Wir schauen jetzt, wie wir das Ganze Thema „Secure-SIP“ mit Letsencrypt automatisieren um dort gültige Zertifikate ohne Wartungsaufwand liegen zu haben.

Unter den Parametern findet man „SECURESIPPATH“ und die Pfadangabe /var/lib/3cxpbx/Instance1/Bin/Cert hier befindet sich die Zertifikatdateien.

Warum 3CX hier nicht auf den bereits vorhandenen Ordner für die Webserver Zertifikate /var/lib/3cxpbx/Bin/nginx/conf/Instance1/ zugreift können wir uns an dieser Stelle nicht erklären. Dafür hat 3CX sicher Gründe. Eventuell möchte man das aus Sicherheitsgründen trennen.

 

[avraammich_3CX]

Hi @itip,

nach meiner Erfahrung sind es zwei Szenarien in welchen Anlage kein Register versuch sendet.

1. DNS nicht wie unter Anleitung beschrieben auf google DNS 8.8.8.8 https://www.3cx.de/docs/sip-trunk/deutsche-telekom-companyflex/
2. Unter Dashboard->Sicherheit->Secure SIP ist key und cert Inhalt nicht hinterlegt bzw. Secure SIP/TLS ist nicht aktiviert.

Bei Verwendung einer Telekom Leitung(Public IP) und transport TCP Optionen am SIP Trunk sollte es jedoch auch klappen.

 

[itip]

Hi @avraammich_3CX

Mittlerweile funktioniert es. Die Lösung habe ich auch bereits genannt.

Punkt 2. war die Lösung und es wäre echt hilfreich wenn dieser Punkt unter https://www.3cx.de/docs/sip-trunk/deutsche-telekom-companyflex/ ergänzt wird.

 

[avraammich_3CX]

Hi @itip,

das hier TLS verwendet als transport Protokoll für provider ist dieses verständlich.
In Verwendung von 3cx FQDN ist Secure SIP aktiviert und .pem Inhalte von key und cert werden automatisch hinzugefügt.

Wir gehen davon aus und empfehlen dass ein 3cx FQDN verwendet wird.

 

[itip]

Hallo @avraammich_3CX

Ich verstehe jetzt nicht so ganz wie das verständlich sein kann. Wenn ich mir die Infoseite dazu ansehe: https://www.3cx.com/docs/secure-sip/ wird hier auf von der Client <-> 3CX Seite gesprochen nicht von 3CX zu SIP Provider Verbindung.

Die Option ein Zertifikat zu hinterlegen habe ich zusätzlich im Trunk, dieses Feld suggeriert doch schon die Aktivierung von TLS in der Trunk Einrichtung und nicht nochmal an anderer Stelle.

Die Funktion ist schlecht dokumentiert und man kann den Hinweis auch einfach mal annehmen, anstatt sich zu rechtfertigen und dem Auszuweichen.

Solange die Funktion des eigenen FQDN angeboten wird, was nebenbei für CI viel charmanter ist, kann man doch nicht davon ausgehen das der Kunde einen 3CX FQDN benutzt und sollte dies so auch so berücksichtigen.

Off Topic: Vor ein paar Jahren rief mich mal ein Mitarbeiter von 3CX an, dieser Fragte, ob wir zufrieden sind. Ich sprach Ihn daraufhin auf das Problem mit den Unverschlüsselten Passwörtern in der DB an. Die Antwort war „Als Admin sind Sie ja dafür verantwortlich, dass die Datenbank nicht verloren geht“

Es tut mir leid aber diese Antwort hier erinnert mich doch stark an diese Situation. Die eigenen Fehler, wenn dieses Mal auch deutlich kleiner, werden dem Kunden zugesprochen.

Das werden wir für uns einfach mal so mitnehmen und das Thema als erledigt betrachten.

 

[mbehrens]

Eine Info dazu haben wir im Forum oder der Dokumentation nicht gefunden, was nicht bedeuten soll das es die Info nicht gibt.

Genau dies steht doch in der Dokumentation der Telekom:

...so müssen die Signalisierungs- und Gesprächsdaten durch das Endgerät des Kunden zwingend verschlüsselt werden.

 

[itip]

Hi, @mbehrens


die Info der Telekom spricht von der Verschlüsselung des Trunks zum Endgerät. Also das Gerät an welches der Trunk angebunden wird. Das kann ein VoIP-Telefon, Softclient oder wie in diesem Fall die 3CX Anlage sein. Danach ist es egal denn „PBX überträgt Audio“

Dafür habe ich die Möglichkeit in den Trunk Optionen ein TLS Zertifikat zu hinterlegen, TLS als Übertragungsprotokoll zu wählen und SRTP zu erzwingen.

Da diese Optionen auch ohne aktiviertes „SecureSIP“ verfügbar sind macht es hier nicht den Anschein, dass ich dies an anderer Stelle nochmal aktivieren muss denn ->

Die Option SecureSIP in der 3CX verlangt das Hinterlegen eines Zertifikates/Keys. Dies ist für die Client (Softclient, VoIP Telefon etc.) zu Server (3CX) Verschlüsselung, hat also nichts mit dem Provider zu tun, daher ist es hier auch möglich selbst signierte Zertifikate zu hinterlegen was für einige Unternehmen eventuell die bessere Lösung ist weil man z.B.: eine interne PKI betreibt. Die ROOT CA muss dann nur auf den Geräten hinterlegt werden die verschlüsselt kommunizieren sollen. Diese Information findet man so auch in der Dokumentation

Dies ist optional, ich kann die internen Clients, trotz der Aktivierung von SecureSIP, ohne SSIP betreiben, was auch gerade mit ein paar YEALINK Telefonen so bei uns läuft. Der Telekom ist diese Verbindung egal. Hier gibt es hier keinen Anhaltspunkt das diese Option für die Verbindung eines Trunks zum Anbieter notwendig sein könnte.

Und hier ist der Knackpunkt. Die Option „SecureSIP“ schaltet nicht wie diese in der oben verlinkten Dokumentation beschrieben und im Anlagenmenü suggeriert, nur die Option frei die Client-Server Verbindung zu verschlüsseln, sondern allgemein die Option mit SIP/TLS umgehen zu können.

Und das ist so nicht dokumentiert, auch nicht bei der Telekom. Wie denn auch, das ist eine 3CX Eigenart. Diese Info gehört meiner Meinung nach in die Anleitung wie der Trunk angebunden wird oder optional als Info in die Trunk Optionen, wenn man hier TLS/SRTP als Übertragungsart wählt. Alternativ kann man diese Funktionen auch ausgrauen, wenn SecureSIP nicht aktiv ist.

Es ist ja auch nicht so das ich hier eine "unmögliche Anforderung" stelle. Ein einfacher Satz in der SIP Trunk Anleitung zu Company Flex würde dieses Problem bereits für viele Kunden lösen. Wie oben zu lesen, scheinen wir nicht die einzigen zu sein die damit zu kämpfen haben/hatten.

 

[fxbastler]

Mit einem eigenen FQDN ist diese Option nicht aktiv bzw. bei uns nicht aktiv.

Bei uns schon. Wir lassen unsere LE dort auch auflaufen.

Wir schauen jetzt, wie wir das Ganze Thema „Secure-SIP“ mit Letsencrypt automatisieren um dort gültige Zertifikate ohne Wartungsaufwand liegen zu haben.

Haben wir (hier die alte Version, noch sshpass und kein ssh key).

Das hatte dennoch bei unseren SIP Trunk Einbindungsversuchen nicht gereicht. Also wurde portiert.

 

[craftunit]

Wir hatten exakt das gleiche Problem mit eigenem FQDN. Durch einen Hinweis von fxbastler in einem anderem Beitrag, fand ich hier dann die Lösung.

Mit aktiviertem Secure SIP ging der SIP-Trunk sofort Online. In der Anleitung von 3CX sollte unbedingt darauf hingewiesen werden.