Telefone verbinden sich nicht mehr nach Appliance tausch

Wir haben den Ernstfall simuliert und eine bestehnde Appliance ausgetauscht (eigenltich nur eine neue SSD in bestehende APU2C4 eingebaut). Gleiche Firmware 18.09, gleiche Schnittstellenkonfiguration und Backup eingespielt.

  • Der Mobileclient verbindet wieder problemlos.
  • SNOM M300 mit M25 verbindet problemlos.
  • Die SNOM D345 (10.1.37.11) jedoch verbinden nicht mehr. Als erstes habe ich das neue TLS Zertifikat in der SNOM UI akzeptiert (dieses wurde natürlich bei der Neuinstallation der Pascom verändert). Dennoch verbinden die Telefone nicht.

Was gibt es hier zu tun? Ich hoffe, es gibt eine einfachere Lösung alls alle D345 neu provisionieren zu müssen!

Nachtrag: Probehalber wurde nun ein Gerät auf Factory geresettet und dann noch aus der Pascom Geräteliste gelöscht. Dieses wurde dann sauber als unzugeordnetes Gerät wiedererkannt und konnte einem User zugewiesen werden. Nach dem Geräterestart, wird diesem auch der Benutzer zugeteilt (erscheint im Display des Gerätes) doch der Benutzer belibt unregistriert.

OK, das Problem könnte das selbstsignierte Zertifikat sein. Und zwar hat die Pascom die IP Adresse: 192.168.x.10, doch das Zertifikat (welche ich im SNOM D345 hinzufügen muss) ist auf 192.168.x.1 ausgestellt.

Hintergrund: Bei der ersten Inbetreibnahme hatte die Pascom die 192.168.x.1 vom DHCP Server erhalten, bevor das Interface auf manuelle IP gewechselt wurde.

Erklärt dies den Umstand?
Wie kann das Zertifikat der Pascom neu generiert werden?

Hallo @schmid01,

in Zeiten der 18.03 war es nicht möglich das (selbst signierte) Zertifikat neu zu erstellen. Bisher gabe es von pascom noch keine Aussage dazu.

Gruß,
Rapha

1 Like

Hallo zusammen,
ab der 18.10 wird das Self Signed Cert mit der angepassten IP/FQDN nach dem Neustart der Schnittstelle frisch generiert. Vermutlich wird es aber noch ein bis zwei Wochen bis zum Release dauern.

Besten Gruß
Sebastian

2 Likes

Danke für die Aussichten @Sebastian_F. Deinen Thread habe ich auch gesehen @rapha.

Gerne probiere ich dieb18.10 umgehend aus - kommt ja einer Neuinstallation der 18.9 um mein Problem zu Lösen gleich.

Kann ich derweil das Zertifikat via SSH Konsole ändern? Müsste doch Möglich sein, oder?

Habe aufgegeben und alles komplett neu aufgesetzt.

Mal einfach ne Frage warum machst du denn kein Lets Ecrypt Zertifikat dann ist das Problem gar nicht vorhanden in Zukunft.

Hab da noch etwas Skrupel wegen der Firewall und den POrts 80 und 443. Momentan braucehn wir diese eben noch für andere Services (und haben nur eine fixe IP).

Könnte ich denn jetzt noch wechseln von Selfsigned auf auf Let’s Encrypt und fällt dann wieder alles zusammen?

Ja klar kann man das Wechseln mußte halt die Telefone neu Provisionieren. Was hast denn für eine Firewall?

Für Lets Encrypt braucht man nur Port 80 und du wirst ja sicher nicht irgendwas unverschlüsselt von Außen zugreifen lassen?

Hmm, das würde ich dann nur bei der Schnittstelle aktivieren, die nach Aussenkommuniziert, also die mit dem Mobile Hub oder beide?

Ich dachte, bei der überschaubaren Anzahl (ca. 5) an externen Geräten ist Selfsigned einfacher, also permanent den Port 80 nach aussen geöffnet zu haben.

Hallo zusammen,

habe den Thread eben erst endeckt. Ich bin mir ziemlich sicher das das verhalten gar nichts mit Zertifikaten zu tun hat!

Falls die Telefone mit Pairing-Url provisioniert wurden, wird die Url mit einem in der Schnittstellekonfiguration hinterlegten Schlüssel erzeugt. Installierst Du nun ein neues System, entsteht erstmal ein neuer Schlüssel. Das restore der Instanz hat nichts mit diesem Key in der Schnittstelle zu tun. Du hast folgende Optionen:

a) den Ursprünglichen Key aus der alten Installation in der UI anzeigen lassen und in die neue Appliance übernehmen
b) alle Telefone mit neuen URLs versehen

Gruß,

Thomas

Das wäre spannend gewesen. Muss ich mir fürs näcshte Mal merken. Nun läuft soweit alles weider mit der frischen Installation.
Was ich nun versuche, ist externe SNOMS anzubiden, siehe Thread SNOM im Homeoffice via Port 8884 an MobileHub problem mit Zertifikat

Da scheint das auch komisch…

Interessanterweise ist nun die Zertifikatsmeldung verschwunden, doch das Telefon scheint sich nicht Porvisionieren zu können.

Es fällt mir auf, dass bei den lokalen (provisionierten) Geräten der Eintrag folgendermassen ausschaut:
<update_server perm="RW">http://192.168.xxx.xxx:8880/p/pascom/{mac}</update_server>

und beim Homeoffice Gerät so (wie ich es aus der Pascom Geräteliste entnommen habe):

<setting_server perm="RW">https://subdomain.domain.ch:8884/p/XXX_VUbi0XlDmbuo0K4o2A9SJhXcmjjsgTE987as372sdf=+</setting_server>

Könnt ihr mir den Unterschied erklären?

Was auch noch auffällt: Nach dem Rebboten, erscheint die Meldung

Provisionierung läuft

Doch die Uhrzeit (-2h wohl UTC) wird falsch angezeigt. Ein NTP Server ist eingetragen und scheint grundsätzlich auch zu funktionieren.

Hi, im anderen Thread fehlen diese Infos leider, das Problem hier ist vermutlich eher split dns, ich vermute dein FQDN wird von der pascom auf die Interne IP aufgelöst. Daher die Empfehlung externe Geräte über ein eigenes Inferface anzubinden, am besten mal das HowTo durchlesen:

Der FQDN bzw die IP die pascom hierfür Auflöst wird an einigen Stellen verwendet, wenn hier die private IP ermittelt wird haben externe Geräte prübleme, wenn hier die externe öffentliche IP übermittelt wird, muss die Kommunikation von Intern über den Router nach intern richtig funktionieren (hairpinnat).

Hoffe das hilft, Grüße
Steve

Danke @Steve bei der Konfiguration bin ich eigentlich von obenstehender Anleitung ausgegangen, sprich: der externe Verkehr (MobileHub) läuft über Interface 2, genau so wie beschireben. Der Mobile Client, funktioniert auch dementsprechend. Macht das Sinn?

Die Details mit dem Hoirpinnat muss ich noch genau anschauen. Wäre es den sinnvoller, die externe IP anstelel subdomin.domain.ch zu verwenden?

Wenn man die externe feste IP direkt einträgt, kann man sich zumindest sicher sein das split DNS keine Probleme macht. Der Endanwender bekommt die IP ohnehin nicht beim pairen zu gesicht bzw kann dennoch manuel den DNS Record verwenden.