Trace-Ausgabe erstellen über WAN-Verbindung

[Jirka]

Es wäre mal interessant zu wissen, ob überhaupt jemand den Tracer über eine VPN-Verbindung zum Laufen bekommt.

Definitiv. Schon immer. Wenn das nicht gehen würde, dann bräuchte ich das ganze Programm nicht. Lokal trace ich im Allgemeinen per Hand mit PuTTY, geht schneller. Aber Langzeit-Traces über VPNs, die durch Zwangstrennungen oder dergleichen mal wegbrechen können, da nehme ich dann gerne LANtracer um dann im entscheidenden Moment auch alles mitgetracet zu haben.

[GrandDixence]

Die Paketgrössenangaben im Beitrag vom 09.03.2023 um 12:26 Uhr sind nicht in Ordnung. Siehe dazu:
https://de.wikipedia.org/wiki/Maximum_Transmission_Unit

Ethernet und jeder ordentliche Internetanschluss hat eine MTU von 1500 Byte. Bekannte Ausnahme: Steinzeitliche Deutsche Telekom. Somit muss ein Ping mit einer Paketgrösse von 1472 Byte und gesetztem DF-Flag (Don't fragment) ordnungsgemäss mit einem Pong beantwortet werden.
https://de.wikipedia.org/wiki/Ping_(Dat ... ertragung)

Wenn Ping's mit gesetztem DF-Flag (Don't fragment) nur bis zu einer Paketgrösse von 1464 Byte mit einem Pong beantwortet werden, beträgt die Path-MTU (des Internetanschlusses) nur 1492 Byte.

Mit Wireshark das ICMP-Paket mit:

Type 3 - Destination Unreachable
Code 4 - Fragmentation required, and DF flag set

einfangen und kontrollieren, welcher Router klemmt. Eventuell muss ein "Packet Capture" im LAN durchgeführt werden.
https://en.wikipedia.org/wiki/Internet_ ... e_Protocol

Ping unter Linux gibt die Angaben in diesem ICMP-Paket als Rückmeldung aus.

Wie unter:
fragen-zur-lancom-systems-routern-und-g ... ml#p104994
beschrieben, hat ein VPN-Tunnel (IKEv2/IPSec) zwischen zweier LANCOM-Geräte eine MTU von 1400 Byte. Somit muss ein durch den VPN-Tunnel wanderndes Ping mit einer Paketgrösse von 1372 Byte und gesetztem DF-Flag (Don't fragment) ordnungsgemäss mit einem Pong beantwortet werden.

LANCOM-Router setzten für TCP-Verbindungen durch VPN-Tunneln "MSS Clamping" ein. Mit MSS Clamping wird dafür gesorgt, dass für die TCP-Datenverbindung keine IP-Datenpakete versendet werden, welche grösser als die Path-MTU sind (=> Path-MTU bei VPN: 1400 Byte).
https://www.cloudflare.com/learning/net ... at-is-mss/

Die Firewall des LANCOM-Routers wurde korrekt mit "Re-assemblieren" konfiguriert?
https://www.lancom-systems.de/docs/LCOS ... 64294.html

Dann allerdings reagiert der Client nicht mehr und der Server (Router) schickt alle 60 Sekunden eine Anfrage an den Client (Tracer).

Alle 60 Sekunden wird (erfolgreich) ein (verschlüsseltes) SSH-Keep alive oder ein (unverschlüsseltes) TCP Keepalive gesendet. Somit steht die verschlüsselte Kommunikationsverbindung (SSH) über längere Zeit. Somit ist das Problem wohl auf Anwendungsebene zu suchen...
https://stackoverflow.com/questions/250 ... sion-alive

PMTU-Reduzierung ausgeschaltet?
fragen-zur-lancom-systems-routern-und-g ... 18492.html

[Hagen2000]

Vielen Dank für die Mühe, diese lange Antwort zu schreiben.

Die Paketgrössenangaben im Beitrag vom 09.03.2023 um 12:26 Uhr sind nicht in Ordnung. Siehe dazu:
...

DSL und auch Glasfaser nutzen PPPoE, daher sind 8 Byte von der maximalen Paketgröße zu subtrahieren.
Die von mir ermittelten Werte stimmen also.

...
beschrieben, hat ein VPN-Tunnel (IKEv2/IPSec) zwischen zweier LANCOM-Geräte eine MTU von 1400 Byte. Somit muss ein durch den VPN-Tunnel wanderndes Ping mit einer Paketgrösse von 1372 Byte und gesetztem DF-Flag (Don't fragment) ordnungsgemäss mit einem Pong beantwortet werden.

IPSec wird hier nicht mit IKEv2 verwendet sondern mit IKEv1. Ob das einen Einfluss auf die maximale Paketgröße hat, ist offen, jedenfalls sind die von mir ermittelten maximalen Paketgrößen (1390 bzw. 1394) sogar höher als die von Dir genannten.

LANCOM-Router setzten für TCP-Verbindungen durch VPN-Tunneln "MSS Clamping" ein. Mit MSS Clamping wird dafür gesorgt, dass für die TCP-Datenverbindung keine IP-Datenpakete versendet werden, welche grösser als die Path-MTU sind (=> Path-MTU bei VPN: 1400 Byte).

Gibt es eine echte Quelle dafür bei LANCOM (im Wesentlichen zitierst Du dich nur selbst)?

Die Firewall des LANCOM-Routers wurde korrekt mit "Re-assemblieren" konfiguriert?

Ja.

PMTU-Reduzierung ausgeschaltet?

Betrifft doch den Voice Call Manager, der ist nicht aktiv.

Einzig merkwürdig bleibt die Beobachtung, dass ein ping auf den LANCOM-Router selbst eine um 4 Byte höhere unfragmentierte Paketgröße zulässt als auf ein Gerät, das sich im LAN des LANCOM-Routers befindet.

Nachtrag: Es geht nochmal um den ping aus dem Homeoffice in die Firma. Bei einer Paketgröße von 1396 erhalte ich die ICMP-Meldung "Destination unreachable (Fragmentation needed)" von der FRITZ!Box im Homeoffice. Scheint mir plausibel, hier scheint das Limit für den VPN-Tunnel zu liegen.
Bei einer Paketgröße von 1394 geht das Paket zunächst durch. Sende ich den ping an den LANCOM-Router auf der anderen Seite des VPN-Tunnels, so antwortet dieser mit pong. Sende ich den ping mit 1394 Bytes an ein anderes Gerät im LAN des LANCOM-Routers, so erhalte ich vom LANCOM-Router die ICMP-Meldung "Destination unreachable (Fragmentation needed)" zurück. Erst wenn ich die Paketgröße weiter reduziere auf 1390 Bytes, leitet er den ping weiter. Dieses Verhalten kann ich nicht verstehen.

[GrandDixence]

DSL und auch Glasfaser nutzen PPPoE, daher sind 8 Byte von der maximalen Paketgröße zu subtrahieren.

Nochmals: Ein ordentlicher Internetanschluss weist eine MTU von 1500 Byte auf. Ist der Internetanschlussanbieter nicht gewillt, einen Internetanschluss mit einer Path-MTU von 1500 Byte anzubieten, ist der Internetanschlussanbieter zu wechseln!

Wenn PPPoE zum Einsatz kommt, muss der Internetanschlussanbieter dafür sorgen, dass die (Path-)MTU des Internetanschlusses mindestens 1508 Byte beträgt. Zum Beispiel mit Jumbo-Frames:
https://forum.openwrt.org/t/pppoe-mtu-1 ... est/4206/5

https://www.bsdforen.de/threads/jumbo-f ... uss.32202/

Sinnvoller wäre wohl der Einsatz einer anderen Technologie als PPPoE für den Internetanschluss:
https://www.wenks.ch/fabian/ADSL-PPPoA.html

Wie das MSS-Clamping im LANCOM-Router funktioniert, kann leicht mit Wireshark untersucht werden.

Sende ich den ping mit 1394 Bytes an ein anderes Gerät im LAN des LANCOM-Routers, so erhalte ich vom LANCOM-Router die ICMP-Meldung "Destination unreachable (Fragmentation needed)" zurück. Erst wenn ich die Paketgröße weiter reduziere auf 1390 Bytes, leitet er den ping weiter. Dieses Verhalten kann ich nicht verstehen.

Die MTU jedes Netzwerkpfades ist unter:

LCOS-Menübaum > Status > WAN > MTU

einsehbar. Wenn der Router ein IP-Datenpaket über einen Netzwerkpfad versenden soll, dass grösser als die MTU des Netzwerkpfads ist, wird das IP-Datenpaket zerstückelt (fragmentiert) oder bei gesetztem DF-Flag mit einer ICMP-Fehlermeldung abgewiesen.

Ein direkt an den LANCOM-Router gerichtetes IP-Datenpaket läuft nicht über das IP-Routermodul vom LANCOM-Router. Ein an einen LAN-Teilnehmer gerichtetes Datenpaket läuft über das IP-Routermodul vom LANCOM-Router.

Die MTU vom VPN-Tunnel kann unter:

LCOS-Menübaum > Setup > VPN > IKEv2

konfiguriert werden. Standard-Wert: 0 => Was bei LCOS 10.42 SU10 bei einer Path-MTU von 1500 Byte der Netzwerkverbindung zwischen den beiden VPN-Endpunkte offenbar einer MTU von 1400 Byte für die Datenpakete durch den VPN-Tunnel entspricht.

Auf IKEv1 gehe ich nicht ein, da sowieso hoffnungslos veraltet.

[Dr.Einstein]

Bei einer Paketgröße von 1394 geht das Paket zunächst durch. Sende ich den ping an den LANCOM-Router auf der anderen Seite des VPN-Tunnels, so antwortet dieser mit pong. Sende ich den ping mit 1394 Bytes an ein anderes Gerät im LAN des LANCOM-Routers, so erhalte ich vom LANCOM-Router die ICMP-Meldung "Destination unreachable (Fragmentation needed)" zurück. Erst wenn ich die Paketgröße weiter reduziere auf 1390 Bytes, leitet er den ping weiter. Dieses Verhalten kann ich nicht verstehen.

4 Byte würden dem Lancom proprietärem VPN-Rtg-Tag Feature entsprechen. Vielleicht was falsch zusammengebaut? Wie dem auch sei, ich würde testweise mal die MTU der VPN Verbindung auf 1300 Byte reduzieren und schauen, ob das Problem damit gelöst ist. Ärgerlich nur, dass du auf Seite der Fritzbox nichts einstellen können wirst:

Kommunikation / Protokolle / MTU-Liste => nach Anpassung einmal den Tunnel trennen

Aber fokusiere dich nicht zu doll auf meine Theorie, kann auch was ganz anderes sein. Aber auffällig ist es schon, dass LAN + WAN stabil funktioniert, und VPN nicht, und du dann noch Abweichungen festgestellt hast.

[GrandDixence]

Und vielleicht sollte auch die ganze LANCOM-spezifische Softwareinstallation inklusive Firmware (LCOS) auf den aktuellsten Stand gebracht werden. Ich lese zum Beispiel in der Release Notes vom LCOS 10.42 RU7 über Fehlerkorrekturen im Bereich MTU und Path-MTU (PMTU):

Bei Verwendung eines WLC-Tunnels müssen Datenpakete eine Paketgröße
mit einem Vielfachen von 8 aufweisen. Je nach verwendeter PMTU konnte
es aber vorkommen, dass der WLAN-Controller Datenpakete mit einer
Paketgröße sendete, bei denen dies nicht der Fall war. Dies führte in
Verbindung mit Access Points mit LCOS LX-Betriebssystem dazu, dass diese
die entsprechenden Datenpakete nicht verarbeiten konnten und die Pakete
somit verworfen wurden.

Vielleicht gab es auch irgendwann mal eine Fehlerkorrektur im Bereich SSH und LANtracer.

[tstimper]

Und vielleicht sollte auch die ganze LANCOM-spezifische Softwareinstallation inklusive Firmware (LCOS) auf den aktuellsten Stand gebracht werden. Ich lese zum Beispiel in der Release Notes vom LCOS 10.42 RU7 über Fehlerkorrekturen im Bereich MTU und Path-MTU (PMTU):

Bei Verwendung eines WLC-Tunnels müssen Datenpakete eine Paketgröße
mit einem Vielfachen von 8 aufweisen. Je nach verwendeter PMTU konnte
es aber vorkommen, dass der WLAN-Controller Datenpakete mit einer
Paketgröße sendete, bei denen dies nicht der Fall war. Dies führte in
Verbindung mit Access Points mit LCOS LX-Betriebssystem dazu, dass diese
die entsprechenden Datenpakete nicht verarbeiten konnten und die Pakete
somit verworfen wurden.

Vielleicht gab es auch irgendwann mal eine Fehlerkorrektur im Bereich SSH und LANtracer.

Anmerkung:

Diese konkrete in LCOS 10.42 RU7 erfolgte Änderung betraf ausschliesslich den WLC Tunnel in Zusammenhang mit LX-APs.
Der WLC Code beachtete bis dahin nicht die etwas anderen Anforderungen der LX-APs an die Paketgröße.
Das führte z.b. beim VPN Aufbau eines Clients am LX-AP aus dem WLAN durch den WLC-Tunnel duch ein VPN zu Paketverlust.
Der WLC schcilte einfach für LX falsch dimensionierte Pakete zum AP. LCOS APs betraf das nicht.

Firma: LANCOM 1784 VA an VDSL-Anschluss:
ping an Ziel im Internet fragmentiert nicht bei Paketgröße <= 1464 Bytes
Homeoffice: FB 7530 AX an Glasfaser (externes Modem):
ping an Ziel im Internet fragmentiert nicht bei Paketgröße <= 1464 Bytes
==> Soweit also gleiches Verhalten.

Jetzt hängt ja der VPN-Tunnel dazwischen.
ping von Firma an Homeoffice fragmentiert nicht bei Paketgröße <= 1390 Bytes
(Gilt sowohl für ping von einem PC aus als auch für ping aus der LANCOM-Router-Konsole heraus).
ping von Homeoffice an Firma verhält sich unterschiedlich:
ping an LANCOM-Router fragmentiert nicht bei Paketgröße <= 1394 Bytes.
ping an LAN-Teilnehmer hinter LANCOM-Router fragmentiert nicht bei Paketgröße <= 1390 Bytes.
Das ist doch schon mal etwas merkwürdig, warum funktioniert das Anpingen des LANCOM-Routers mit einer höheren Paketgröße als das Anpingen anderer LAN-Teilnehmer?

Wir mussten in einem Fall für die VPN Gegenstelle die MTU in LCOS auf 1280 bis 1250 stellen, damit Traffic möglich war.
Der Provider hatte 1300 empfohlen, das reichte nicht.

Viele Grüße

ts

[GrandDixence]

Wir mussten in einem Fall für die VPN Gegenstelle die MTU in LCOS auf 1280 bis 1250 stellen, damit Traffic möglich war.
Der Provider hatte 1300 empfohlen, das reichte nicht.

Wenn die Path-MTU der Netzwerkverbindung zwischen den beiden VPN-Endpunkte deutlich kleiner als 1500 Byte ist, muss der VPN-MTU händisch unter 1400 Byte reduziert werden. Je nach den vorkonfigurierten und ausgehandelten VPN-Verschlüsselungsmethoden ist der VPN-Overhead grösser oder kleiner.



Als Faustregel sollte die VPN-MTU-Reduktion 100 Byte betragen, wie es LANCOM mit der Standardkonfiguration (VPN MTU:=0) implementiert hat. Beim Einsatz von Techniken zur Datenkapselung wie GRE, PPPoE, "Lancom proprietärem VPN-Rtg-Tag Feature" kann die erforderliche MTU-Reduktion diese 100 Byte-Faustregel überschreiten!

Bei MTU < 1500 Byte immer Path-MTU ausmessen mit Ping-Messungen mit gesetzten DF-Flag. Danach Ping-Messungen mit übergrossen Datenpakete und ohne DF-Flag durchführen um zu kontrollieren, ob die übergrossen Datenpakete korrekt zerstückelt (fragmentiert) und zusammengesetzt (reassembliert) werden.

Eine zu kleine VPN-MTU kann zu VPN-Performanceeinbrüche führen, wie man dem LANCOM Performance-Techpaper entnehmen kann.

[Hagen2000]

Wie groß die vom ISP zur Verfügung gestellte MTU nun auch immer sein mag (in diesem Fall sind es 1492 Bytes), spätestens beim Einsatz von VPN kommt der Overhead von IPSec dazu und alle beteiligten Geräte müssen mit der daraus resultierenden deutlich kleineren MTU zurecht kommen, Stichwort "Path MTU Discovery".

/Status/WAN/MTU/ gibt für die VPN-Verbindung den Wert 1419 aus, subtrahiert man die Länge des ICMP-Pakets von 28, so können also maximal 1391 Bytes übertragen werden. In meinen früheren Beiträgen hatte ich von 1390 Bytes geschrieben, weil ich ungerade Werte nicht ausprobiert hatte. Ein ping mit 1391 Bytes geht folglich auch noch unfragmentiert durch den VPN-Tunnel. Der Overhead für IPSec beträgt also bei dieser Paketgröße 73 Bytes (= 1492 - 1419).

4 Byte würden dem Lancom proprietärem VPN-Rtg-Tag Feature entsprechen.

Ein direkt an den LANCOM-Router gerichtetes IP-Datenpaket läuft nicht über das IP-Routermodul vom LANCOM-Router. Ein an einen LAN-Teilnehmer gerichtetes Datenpaket läuft über das IP-Routermodul vom LANCOM-Router.

Das erklärt meine von mir als merkwürdig eingestufte Beobachtung. Da die eingestellte MTU der VPN-Verbindung auf dem kleineren der beiden Werte steht, sollte daraus also kein Problem entstehen.

Die Fokussierung auf das Thema "MTU" stammte ursprünglich nicht von mir, brachte aber viele interessante Erkenntnisse und Beiträge hervor. Vielen Dank an alle Beteiligten, die sich ja zum Teil auch am Wochenende die Zeit genommen haben, hier zu helfen.

Was mir nicht aus dem Kopf ging, war die Tatsache, dass einige Zeit nach dem Starten der Trace-Ausgabe nach den Zugangsdaten des Routers gefragt wurde, obwohl diese in LANconfig bzw. LANmonitor gespeichert sind (siehe auch meinen Beitrag vom 09.03.2023 10:02 Uhr dazu). Auffällig auch, dass der Dialog keine Checkbox zum Speichern der Zugangsdaten enthält. Das führt mich letztlich zur Lösung, die ich im folgenden Beitrag beschreiben möchte.

[Hagen2000]

Der eigentliche Fehler scheint an den Tools LANconfig und LANmonitor zu liegen. Die von den Tools gemerkten Zugangsdaten werden offenbar nicht mit den Zugangsdaten der Trace-Ausgabe synchronisiert.

Abhilfe: Den Router aus der Liste der Geräte löschen und neu hinzufügen. Dann beim ersten Zugriff die Zugangsdaten eingeben und das Speichern erlauben bzw. gleich in den Geräteeigenschaften die Zugangsdaten eintragen.

Fehler reproduzieren: Der Fehler lässt sich sehr einfach reproduzieren: LANconfig starten und nun das Gerät konfigurieren. Unter Management / Admin das Hauptgerätepasswort ändern und den Dialog schließen. LANconfig übernimmt zwar das geänderte Passwort, so dass man weiter auf das Gerät zugreifen kann, allerdings tritt ab diesem Zeitpunkt das beschriebene Problem mit dem Aufruf der Trace-Ausgabe auf (Gerät / Trace-Ausgabe erstellen). Nach Rückänderung des Passworts funktioniert auch der Aufruf der Trace-Ausgabe wieder. Gleiches gilt für LANmonitor.

Der Fehler hängt also nicht mit dem Zugriff über das WAN (mit VPN) zusammen sondern mit dem Ändern des Hauptgerätepassworts und dem Umgang von LANconfig und LANmonitor damit.

[Jirka]

Die von den Tools gemerkten Zugangsdaten werden offenbar nicht mit den Zugangsdaten der Trace-Ausgabe synchronisiert.

Meinst Du mit diesem Satz ganz am Anfang Deines Beitrags folgendes?:

Die von den Tools temporär gemerkten Zugangsdaten werden offenbar nicht mit den Zugangsdaten der Trace-Ausgabe synchronisiert.

Also speicherst Du in LANconfig das Passwort nicht ab?
Dann ist mir der Fehler bekannt. Dabei passieren die ulkigsten Sachen. Ich bin da seit Jahren kein Freund mehr von.

[Hagen2000]

Nein, es geht um die dauerhaft gespeicherten Zugangsdaten.

[Jirka]

Ok, aber Du weißt, dass die Zugangsdaten für LANtracer in LANconfig separat hinterlegt werden können?
(Geräte-)Eigenschaften -> Protokolle & Logins -> Logindaten -> ... -> LANtracer

LANconfig übernimmt zwar das geänderte Passwort,

Ja, aber evt. nur temporär.

Ich kann mich hier mit meinem alten LANconfig aber nicht zu weit aus dem Fenster lehnen, nachher ist es in Wirklichkeit schon alles ganz anders. Trotzdem schön, dass Du hier die Ursache beschreibst.

[Hagen2000]

Ok, aber Du weißt, dass die Zugangsdaten für LANtracer in LANconfig separat hinterlegt werden können?
(Geräte-)Eigenschaften -> Protokolle & Logins -> Logindaten -> ... -> LANtracer

Danke - das Menü kannte ich tatsächlich nicht. Bleibt aber das Problem, dass der LANtracer zwar offensichtlich merkt, dass die gespeicherten Logindaten nicht korrekt sind, auch nach neuen fragt, aber damit dann nicht hochkommt.

Und ist eine konsistente Namensgebung wirklich so schwer? Warum heißt es einmal "Trace-Ausgabe" und einmal "LANtracer"?

Noch eine Auffälligkeit: LANconfig (10.72.0012 RU2) fragt nach den Zugangsdaten beim Aufruf der Trace-Ausgabe und speichert diese unter Logindaten bei Protokolle & Logis ab. LANmonitor (10.72.0007 RU2) jedoch fragt nicht nach separaten Zugangsdaten und es gibt auch keinen Eintrag bei den Logindaten!

[Jirka]

Und ist eine konsistente Namensgebung wirklich so schwer? Warum heißt es einmal "Trace-Ausgabe" und einmal "LANtracer"?

Keine Ahnung, der Name LANtracer wurde nie offiziell eingeführt. Auch wenn Du das Programm startest, heißt es ja nicht so (die exe-Datei schon, aber der Programmname eben nicht). Andererseits musste das Ding irgendwie benannt werden und was lag da nicht näher als LANtracer.

Noch eine Auffälligkeit: LANconfig (10.72.0012 RU2) fragt nach den Zugangsdaten beim Aufruf der Trace-Ausgabe und speichert diese unter Logindaten bei Protokolle & Logins ab. LANmonitor (10.72.0007 RU2) jedoch fragt nicht nach separaten Zugangsdaten und es gibt auch keinen Eintrag bei den Logindaten!

Hmm. Früher gab es noch kein SNMPv3 (verschlüsseltes SNMP). Wenn man also SNMPv2 mit LANmonitor gemacht hatte, hatte man aus Sicherheitsgründen dafür ein extra Passwort hinterlegt (z. B. die SNMP-Community, aber es gingen auch Benutzerdaten mit eingeschränkten Rechten). Wenn LANmonitor jetzt merkt, dass das Gerät SNMPv3 unterstützt, dann nimmt es einfach die bereits hinterlegten Zugangsdaten ohne Rückfrage. Bei LANtracer ist das vermutlich anders. Auch LANtracer könnte, wenn es SSH nutzt oder Telnet-SSL, eigentlich auch das hinterlegte Passwort nutzen, das wurde aber offenbar mit der Erweiterung auf SSH so nicht geändert. Vielleicht geht es auch gar nicht?