1781VAW, routenabhängig "Kein Service" bei Yealink / Placetel

[Carsten1972]

Hallo,

ein 1781VAW (10.50.0953) war mit zwei WAN als Loadbalancer betrieben worden:
1. ADSL Vodafone über integriertes Modem
2. ADSL Easybell über FritzBox 7430

Ein paar Yealink SIP-Telefone wurden da dran gehängt, Placetel Cloud-Telefonie. Das lief auf Anhieb sauber.

Nun habe ich den gekündigten Vodafone-Anschluss entfernt und den Loabalancer wegkonfiguriert, anschließend den Easybell-Anschluss direkt mit dem DSL-Port des 1781VAW verbunden und entsprechend konfiguriert. Alles lief nach der kurzen Untebrechung.

Anschließend habe ich einen neuen DOKOK21 FTTH Anschluss über ETH1 am externen Modem konfiguriert und die Route entsprechend geändert, indem ich "Default Route überschreiben" auswählte. Dann habe ich als Backup-Leitung den Zugang über Easybell angegeben.

Nun zeigt sich folgendes Verhalten:
Die normale Internetnutzung läuft problemlos an allen Rechnern.
Aber die Telefone meckern "Kein Service".

Zudem wird die Backup-Verbindung ignoriert.

Ich habe die Route wieder auf "Easybell" gestellt: -> Telefone sind kurz danach betriebsbereit, Internet geht (aber natürlich laaangsam).
Um ein Problem mit Dokom auszuschließen, habe ich die alte 7430 mit den Zugangsdaten von Dokom21 gefüttert, an das FTTH-Modem angeschlossen und ein Yealink-Telefon zur Probe nur an die 7430 angeschlossen -> Telefon funktioniert.

Ich habe keinen Admin-Zugriff auf die Telefone, die wurden von jemand anderem geliefert und eingerichtet. Ich sehe an den Telefonen auch keine hilfreichen Meldungen außer "kein Service".

Vermutlich habe ich gerade nur ein großes Brett vorm Kopf... Wo würdet IHR meinen Fehler als erstes suchen?

Die Firewall hat nur die rudimentären, voreingestellten Regeln.

Der Firmeninhaber ist ein guter Bekannter, aber noch zwei Wochen im Urlaub. DIe Büromitarbeiter sind aktuell etwas "schwierig" und reagieren etwas gereizt.

[Dr.Einstein]

Hey,

hast du zwei Subnetze, eins für Data eins für Voice?

[Carsten1972]

zwei Subnetze

Leider nein.
Es war auch mein erster Gedanke, Telefonie und "Rest" in zwei Netze zu stecken - es handelt sich um eine "gewachsene Infrastruktur" (Kabelchaos), wild gemischte Switches, alles undokumentiert und die Firma heuerte bislang jedesmal jemand anderen an.

Die Telefonie wurde auf die "Cloud" umgestellt, weil jemand geraten hat, dass das "besser" sei. Derjenige hat die Telefone verteilt, eingesteckt, Netzteile dazu verkauft und das war's. Dass der DHCP Range, der nur 10 Adressen umfasste, damit kritisch ausgereizt wurde? Egal, warum fragen, warum prüfen.

Ich habe das eher aus Mitleid übernommen und bin kurz davor, "Tschüss" zu sagen.

Dokumentation ist da so dermaßen unbekannt, dass man meine Konfigurationsseiten weder in gedruckter noch in digitaler Form aufbewahrt und ich auf die Frage "Kann ich bitte einmal das Blatt mit den Zugangsdaten haben" höre: "Ja, das haben SIE doch alles eingestellt!"

Tja, nur speichere ich mir halt Zugangsdaten von Kunden nicht ab.

Anektode:
Nach der Umstellung lief noch EIN Telefon. Da habe ich natürlich nachgeforscht. 192.168.178.0 Netz - und damit völlig daneben. Weiter gesucht: Da hängt ne Fritzbox 7590AX unter dem Schreibtisch, daran ein analoges Fax. Und ein ATA, daran noch ein analoges Fax. Und das eine IP-Telefon steckt natürlich auch in dieser Fritzbox.
Tja, da existiert völlig abgetrennt vom Rest halt noch ein Vodafone-Anschluss, der nur für die beiden Faxgeräte da ist und von dem niemand was wusste.
Ist doch toll, wie sorgfältig da die Umstellung auf die Cloud-Telefonie vorbereitet und durchgeführt wurde.

Ich könnte auch Bilder vom "Severraum" und einer "Netzwerkecke" machen... Oh je. Wie gesagt, ich bin kurz vom Hinschmeißen.

[Dr.Einstein]

Anhand von einem Debug würde ich das zumindest sehr schnell rausfinden. Auf den Lancom Router via SSH einloggen, 'trace # ip-router @ 192.168.1.100' (IP austauschen mit der Adresse eines Telefons) und warten, bis das Telefon versucht sich zu registrieren. Dort müsstest du dann sehen, welche Route er versucht zu nehmen.

Zudem wird die Backup-Verbindung ignoriert.

Ich habe die Route wieder auf "Easybell" gestellt

Die Firewall hat nur die rudimentären, voreingestellten Regeln.

An deinen Aussagen erkenne ich Unstimmigkeiten. Auch, weil genau hier Routing-Tabelle / Firewallregeln der Fehler zu vermuten ist. "Ich habe die Route wieder auf "Easybell" gestellt". Das Wort wieder passt hier nicht rein. Vorher sollte laut deiner Beschreibung Loadbalancer als Default Route hinterlegt gewesen sein, nicht Easybell. Außerdem zur Info: Eine Backupverbindung funktioniert nur dann, wenn der Name der Backup-Verbindung nirgends in der Routing Tabelle auftaucht. Es darf also keinen einzigen Eintrag mit "Easybell" geben, lediglich mit DOKOK21.

"Die Firewall hat nur die rudimentären, voreingestellten Regeln." => es gibt nur eine Standardregel, die lautet WINS. Sicher, dass es nicht mehr Regeln gibt, die Dinge erlauben und z.B. auf ein Routing Tag zeigen?

Ich vermute, vorher war ein Loadbalancer konfiguriert, und zusätzlich noch z.B. mit Rtg 1 / 2 eine dedizierte Route für Easybell + Vodafone. In der Firewall gibt es eine Regel, die die Telefonie explizit auf ein Routing Tag gezwungen hat. Durch deinen deaktivierten Loadbalancer gibt es jetzt dieses Routing-Tag nicht mehr.

Gruß Dr.Einstein

[Carsten1972]

Anhand von einem Debug würde ich das zumindest sehr schnell rausfinden. Auf den Lancom Router via SSH einloggen, 'trace # ip-router @ 192.168.1.100' (IP austauschen mit der Adresse eines Telefons) und warten, bis das Telefon versucht sich zu registrieren. Dort müsstest du dann sehen, welche Route er versucht zu nehmen.

Danke für die Unterstützung. Das werde ich mal machen.

Zudem wird die Backup-Verbindung ignoriert.

Ich habe die Route wieder auf "Easybell" gestellt

Die Firewall hat nur die rudimentären, voreingestellten Regeln.

An deinen Aussagen erkenne ich Unstimmigkeiten. Auch, weil genau hier Routing-Tabelle / Firewallregeln der Fehler zu vermuten ist. "Ich habe die Route wieder auf "Easybell" gestellt". Das Wort wieder passt hier nicht rein.

"Wieder" bezieht sich auf den "Zwischenstand", also schon mit entferntem Loadbalancer und den Gegenstellen "Internet" (=Easybell) und "Dokom21".
Meinem Verständis nach wähle ich für 255.255.255.255 in der Routing Tabelle "Dokom21" aus und alles läuft über Dokom21 - oder eben "Internet" und alles läuft über Easybell ins Internet - was ja auch für den Datenverkehr aller PCs funktioniert.

Vorher sollte laut deiner Beschreibung Loadbalancer als Default Route hinterlegt gewesen sein, nicht Easybell. Außerdem zur Info: Eine Backupverbindung funktioniert nur dann, wenn der Name der Backup-Verbindung nirgends in der Routing Tabelle auftaucht. Es darf also keinen einzigen Eintrag mit "Easybell" geben, lediglich mit DOKOK21.

Das Backup greife ich an, wenn die Telefonie geht. Vorerst möchte ich das Backup als "Luxusproblem" erst einmal nicht antasten.

"Die Firewall hat nur die rudimentären, voreingestellten Regeln." => es gibt nur eine Standardregel, die lautet WINS. Sicher, dass es nicht mehr Regeln gibt, die Dinge erlauben und z.B. auf ein Routing Tag zeigen?

Es gibt genau diese eine WINS-Regel. Kein weiterer Eintrag.

Ich vermute, vorher war ein Loadbalancer konfiguriert, und zusätzlich noch z.B. mit Rtg 1 / 2 eine dedizierte Route für Easybell + Vodafone. In der Firewall gibt es eine Regel, die die Telefonie explizit auf ein Routing Tag gezwungen hat. Durch deinen deaktivierten Loadbalancer gibt es jetzt dieses Routing-Tag nicht mehr.

Gruß Dr.Einstein

Leider nein. Ich hatte für die Telefonie gar nichts eingestellt, ich habe von der Umstellung auf die Cloud-Telefonie erst etwas erfahren, als ich die Hipath im Schrott liegen sah.

Ich vermute auch, dass ich irgendwo noch einen Rest in der Konfig stehen habe, der dazwischen murkst. Mein momentaner Plan ist, dass ich ganz in Ruhe einen Ersatzrouter vorkonfiguriere und zwischen "Sie können loslegen!" und "Wir haben eigentlich Feierabend, wie lange dauert das denn noch?" ausprobiere. Dieser Zeitraum wird etwa 3 Minuten betragen.

Das macht keinen Spaß. Und eigentlich mache ich das nur, weil es Spaß macht.
Ich hätte absagen sollen, als Dokom21 ins Spiel kam - besser noch früher, als mal wieder ein neuer Berater die Telefonie umstellte.
Und besser noch früher, als ich das vorliegende Chaos das erste Mal sah.

[Dr.Einstein]

Schau mal in die DNS Weiterleitungstabelle, ob dort noch ein Eintrag auf die falsche Gegenstelle zeigt. Ansonsten lade mal bitte die Konfiguration als Skript runter (Rechtsklick im LanConfig oder Dateimanagement in der Weboberfläche) und durchsuche die Datei nach dem alten Gegenstellennamen.

Ansonsten kannst du das Thema mMn auch ohne Kunden nachstellen. Ändere aus der Ferne nach Feierabend die Konfiguration. Anhand des gezeigten Debugs solltest du erkennen können, ob die Registrierung zum Cloudprovider läuft (beidseitige Pakete) oder nicht.

[Carsten1972]

Pakete eines Telefons nach Umstellung der Route:

Code: Alles auswählen

IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 185.79.24.138, SrcIP: 192.168.2.221, Len: 52, DSCP: AF31 (0x1a), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 5061, SrcPort: 12041, Flags: S
Seq: 1030452360, Ack: 0, Win: 5840, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: NOP
Option: SACK permitted
Option: NOP
Option: Window scale = 1 (multiply  by 2)
Route: WAN Tx (DOKOM21)

Keine Antworten von 185.79.24.138 (Broadsoft Germany = Placetel).
Das hatte ich mir zwei Minuten lang angeschaut, das Telefon ist dabei auch nicht anrufbar gewesen.

Also zurück auf Easybell:
A new configuration is being uploaded ...

Es folgte noch ein Anmeldeversuch über Dokom:

Code: Alles auswählen

[IP-Router] 2022/09/17 14:00:50,547
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 185.79.24.138, SrcIP: 192.168.2.221, Len: 52, DSCP: AF31 (0x1a), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 5061, SrcPort: 12041, Flags: S
Seq: 1030452360, Ack: 0, Win: 5840, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: NOP
Option: SACK permitted
Option: NOP
Option: Window scale = 1 (multiply  by 2)
Route: WAN Tx (DOKOM21)

Das hat sich wohl zeitlich überschnitten.
Anschließend der erste Versuch über Easybell:


Configuration has been uploaded successfully

Code: Alles auswählen

[IP-Router] 2022/09/17 14:01:32,566
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 185.79.24.138, SrcIP: 192.168.2.221, Len: 52, DSCP: AF31 (0x1a), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 5061, SrcPort: 12042, Flags: S
Seq: 2020464669, Ack: 0, Win: 5840, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: NOP
Option: SACK permitted
Option: NOP
Option: Window scale = 1 (multiply  by 2)
Route: WAN Tx (INTERNET)

[IP-Router] 2022/09/17 14:01:32,597
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.2.221, SrcIP: 185.79.24.138, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 12042, SrcPort: 5061, Flags: SA
Seq: 3811662684, Ack: 2020464670, Win: 64240, Len: 0
Option: Maximum segment size = 1452
Option: NOP
Option: NOP
Option: SACK permitted
Option: NOP
Option: Window scale = 12 (multiply  by 4096)
Route: LAN-1 Tx (INTRANET)

Da kam also unverzüglich die Antwort und ich bekam beim Anrufversuch auch direkt ein Freizeichen.

Ich verstehe nicht, warum über die Route DOKOM21 die PCs funktionieren, aber die Telefone (im selben Netz) keine Registrierung hinbekommen.

[GrandDixence]

Die Meldung "Kein Service" auf dem Display der VoIP-Telefone bedeutet, dass sich das Telefon nicht per SIP beim VoIP-Anbieter registrieren konnte.

Auf Serverport TCP 5061 horcht SIPS. Also mit TLS verschlüsseltes SIP. Wurde vorgängig abgeklärt, ob all diese VoIP-Anbieter SIPS unterstützen? Wenn nein, VoIP-Telefonkonfiguration auf UDP Port 5060 umkonfigurieren (SIP ohne TLS-Verschlüsselung).
https://de.wikipedia.org/wiki/Session_I ... n_Protocol

Generell empfiehlt sich hier am entsprechenden LAN-Port Packet Capture einzusetzen und den damit aufgezeichneten Netzwerkdatenverkehr mit Wireshark auszuwerten. Wireshark besitzt mächtige Funktionen für die Auswertung der Signalisierung per SIP.
viewtopic.php?f=14&t=17510&p=99340&hili ... ker#p99340

https://support.yeastar.com/hc/en-us/ar ... -Wireshark

Eventuell macht auch ein Einsatz von OpenSSL sinn, um festzustellen ob der Serverport TCP 5061 offen ist. Zum Beispiel:

# openssl s_client -CApath /etc/ssl/certs/ -connect 185.79.24.138:5061

[Carsten1972]

Es läuft.

Ich weiß nicht, warum es läuft. Aber es läuft.
Ich habe aus Spieltrieb die 10.50.0819 eingespielt und ich kann mindestens zwei der betroffenen Telefone wieder anrufen.

OK. Aber woran lag? Neustarts (auch einen echten Kaltstart vor Ort) hatte ich schon probiert.

Also habe ich nochmal die aktuelle 10.50.0953 hochgeladen - und nach kurzer Wartezeit darf ich sagen: Auch jetzt funktioniert es.

[Dr.Einstein]

Hattest du noch etwas an den Maskierungseigenschaften angepasst? Diese greifen erst nach einer WAN-Trennung (bzw Kaltstart)

[Carsten1972]

Wurde vorgängig abgeklärt, ob all diese VoIP-Anbieter SIPS unterstützen?

Natürlich wurde nichts abgeklärt und nichts abgesprochen. Auch nicht mir mir.

Hattest du noch etwas an den Maskierungseigenschaften angepasst?

Nein.

Eine Frage noch:
Ich habe ja nun diese zwei Gegenstellen. Dokom21 nutzt dynamische IPv4-Adressen (ohne CG-NAT), bei Easybell gibt es eine feste IPv4.
Der Alarmanlagen-Errichter hat einen Wartungsvertrag, in welchem er einen Fernwartungszugang über eine Portweiterleitung als Voraussetzung verlangt.


Wenn ich es richtig sehe, wählt sich der Router nur dann bei Easybell (WAN VDSL1) ein, wenn auch ein entsprechender Eintrag in der Routing Tabell existiert.
Diesen habe ich mit dem Routing Tag 123 angelegt, welches ansonsten unbenutzt ist.

Wird ein Portforwarding über den Easybell-Anschluss dennoch funktionieren?
Unter dieser Voraussetzung wird aber ein Backup über Easybell nicht klappen, da Easybell dann ja in der Routing Tabelle steht.

[Dr.Einstein]

Wird ein Portforwarding über den Easybell-Anschluss dennoch funktionieren?

ja

Unter dieser Voraussetzung wird aber ein Backup über Easybell nicht klappen, da Easybell dann ja in der Routing Tabelle steht.

ja. Vielleicht schaust du dir mal das Thema administrative Distanzen an. Sollte innerhalb von einer Minute funktionsfähig umgesetzt sein.

[Carsten1972]

ja. Vielleicht schaust du dir mal das Thema administrative Distanzen an. Sollte innerhalb von einer Minute funktionsfähig umgesetzt sein.

Zunächst einmal herzlichen Dank für deine Bemühungen.
Zweitens werde ich das nun an jemand anderen abgeben. Ich habe mal wieder meine Grenzen erfahren und für einen Art bezahlten Freundschaftsdienst wird das einfach zu viel.
Leider kenne ich hier im Bereich keinen Netzwerker, dem ich vertraue. Also eigentlich kenne ich nur drei - und denen vertraue ich leider nicht.

Das "warum" gehört hier nicht hin.

Da mindestens einmal eine physische Anwesenheit notwendig wäre (um sich die Pracht des Vorhandenen anzusehen und damit der Chef sich auch mal aus berufenem Mund eine ehrliche Meinung zu dem anhören kann, was da bislang geleistet wurde), wäre meine Frage in die Runde: Wie sieht es denn so im PLZ Bereich 586 aus? 44 ist quasi direkt um die Ecke...

Ein Blick in den "Serverraum":

IMG_20220404_105943.jpg

Hier die Netzwerkecke mit den Anschlüssen:

IMG-20190212-WA0001.jpg