[Gelöst] ESP Paketverluste über IPv6 (1und1?)

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: ESP Paketverluste über IPv6 (1und1?)

Beitrag von beki »

Jirka hat geschrieben:Genau: Telekom, Telefónica, QSC, ...? Bei wem seid Ihr denn in Wirklichkeit, beki? Weißt Du das?

Code: Alles auswählen

$ { whois $(dig +short rkirchen.de @8.8.8.8 A); whois $(dig +short bkirchen.de @8.8.8.8 A); whois $(dig +short rkirchen.de @8.8.8.8 AAAA); whois $(dig +short bkirchen.de @8.8.8.8 AAAA); } | grep origin
origin:         AS3320
origin:         AS3320
origin:         AS3320
origin:         AS3320

Code: Alles auswählen

$ whois AS3320 | grep '\-name'
as-name:        DTAG
org-name:       Deutsche Telekom AG
VLAN-ID ist 7. Ist das hinreichend um anzunehmen, dass die beiden Anschlüsse letztlich von der Telekom bereitgestellt sind?
Dr.Einstein hat geschrieben:Ersten Tests nach ja ...
Das heißt, du hast es ausprobiert? Das freut mich! Das Problem scheint also auch bei anderen Menschen aufzutreten.
Dr.Einstein hat geschrieben:Ohne Connections kommst du bei Telefonica, QSC, Telekom oder wem auch immer niemals bis zum Coreteam durch.
Das mag ja sein, aber wenn das Problem eindeutig beim Provider zu suchen ist, dann muss im Zweifel social media oder heise/c't helfen um diesem Problem die Aufmerksamkeit zu besorgen, die es aus meiner Sicht verdient.
Jirka hat geschrieben:ich hoffe das war jetzt kein so extrem großer Aufwand. Alternativ hätte man auch ZYXEL VMG1312-B30A vorsetzen können als blöde Modems.
Das hätte meiner Vorstellung nach Eingriffe nötig gemacht, die nur lokal zu bewerkstelligen gewesen wären. Aus meiner Sicht war es einfacher, die FB vorzukonfigurieren und meinen Vater lediglich die Stecker umstöpseln zu lassen.
GrandDixence hat geschrieben:a) Es werden von der Fritzbox 7412 IPv6-Pakete versendet, die einen nicht korrekten IPv6-Header enthalten (next header type).
b) [...] Zwischen Frame 4 und Frame 5 fehlen einige (per ICMP nachweislich) von der Fritzbox 7412 versendete IPv6-Pakete!
  • Ich weiß nicht, warum der Empfänger-Rechner (Linux) diese ICMPv6 Nachrichten schickt. Es wäre wirklich toll, wenn du das erklären könntest. Alles, was ich deinem Post lese ist "IPv6 Paket ist kaputt", aber leider machst du es uns nicht deutlich, *warum* das so ist. Die IPv6 Pakete sehen für mich alle gültig aus. Was glaubst du denn gibt den Anlass zu dieser ICMPv6 Nachricht?
  • Korrekt, es fehlen Pakete, die in diesem Capture zu erwarten sind. Ich schiebe die Schuld darauf, dass dies ein Remote-Capture über die Schnittstelle, welche getraced wurde, ist. Ärgerlich. Den Test müsste ich theoretisch wiederholen. Glücklicher Weise ist das praktisch *nicht* nötig, weil die ICMP Nachrichten nachweisen, dass (ein Teil der) vermissten Nachrichten angekommen ist -- obwohl das hier von gar keiner Relevanz ist. Es ist nämlich zum Beispiel ersichtlich, dass das ESP-Paket mit Sequenznummer 24 verschickt wurde, aber nicht ankam -- was den Fehlerfall verdeutlicht.
GrandDixence hat geschrieben:Ich denke, die Probleme liegen vor der Tastatur...
Siehe persönliche Nachricht.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: ESP Paketverluste über IPv6 (1und1?)

Beitrag von GrandDixence »

Die ICMPv6-Nachricht informiert den Absender darüber, dass der Parameter "next header" im IPv6-Header/Kopf einen inakzeptablen Wert oder ein inakzeptables Format aufweist. Siehe die Angaben in der Spalte "Info" von Wireshark.
Screenshot_Wireshark_ICMP.png
Siehe auch:
https://www.cisco.com/en/US/technologie ... 4d37d.html

TCPDump wird mit dem Aufzeichnungsfilter (CaptureFilter) "ESP" verwendet. Siehe auch "#man tcpdump". So werden in der *.pcap/*.pcapng-Datei (wahrscheinlich) nur IPv6-Pakete aufgezeichnet, welche im IPv6-Header für das Feld "Next Header" den Wert "50" aufweisen (ESP).
http://www.ipv6-portal.de/informationen ... eader.html

https://en.wikipedia.org/wiki/List_of_I ... ol_numbers

Bei IPv4-Paketen werden in der *.pcap/*.pcapng-Datei nur IPv4-Pakete aufgezeichnet, welche im IPv4-Header für das Feld "Protocol" den Wert "50" aufweisen (ESP).

Die per ICMPv6-Nachricht bemängelte IPv6-Pakete enthalten mit hoher Wahrscheinlichkeit im IPv6-Header für das Feld "Next Header" nicht den Wert "50" und werden somit auch nicht von TCPDump aufgezeichnet!

Aufzeichnungsfiltern (CaptureFilters) sollte man nur für langfristige Aufzeichnungen (> 60 Minuten) einsetzen. Aufzeichnungsfiltern (CaptureFilters) sollte man nur einsetzen, wenn man genau weiss, was man macht und sucht!

Ich empfehle das Arbeiten mit Anzeigefiltern (DisplayFilters) in Wireshark!

Bitte mit dem Unterschied von CaptureFilters und DisplayFilters in Wireshark vertraut machen:
https://wiki.wireshark.org/CaptureFilters

https://wiki.wireshark.org/DisplayFilters

Für Wireshark gibt es zahlreiche gute Youtube-Lernvideos.

Unter Linux ist die zu empfehlende Aufzeichnungsmethode:

Code: Alles auswählen

# su
# dumpcap -i eth0 -B 10 -w /tmp/test.pcapng
# chown hans:users /tmp/test.pcapng
< Als normaler Benutzer "hans" anmelden und Wireshark ohne Root-Rechte starten >
Siehe auch:
https://wiki.wireshark.org/CaptureSetup ... Privileges

Unter Windows ist die zu empfehlende Aufzeichnungsmethode:

Code: Alles auswählen

< "DOS"-Kommandozeile mit Administratorrechte öffnen >
# dumpcap -i 2 -B 10 -w c:\test.pcapng
< Als normaler Benutzer "hans" anmelden und Wireshark ohne Administrator-Rechte starten
Siehe auch:
https://www.cellstream.com/intranet/ref ... puter.html
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von GrandDixence am 31 Mai 2018, 20:50, insgesamt 1-mal geändert.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: ESP Paketverluste über IPv6 (1und1?)

Beitrag von GrandDixence »

Der Empfänger sendet die ICMP-Nachrichten "unrecognized Next Header type encountered" konform zu RFC 8200:
https://tools.ietf.org/html/rfc8200

RFC 8200, Kapitel 4

Code: Alles auswählen

If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Next Header value in
   the current header is unrecognized by the node, it should discard the
   packet and send an ICMP Parameter Problem message to the source of
   the packet, with an ICMP Code value of 1 ("unrecognized Next Header
   type encountered") and the ICMP Pointer field containing the offset
   of the unrecognized value within the original packet.  The same
   action should be taken if a node encounters a Next Header value of
   zero in any header other than an IPv6 header.
Diese ICMP-Nachricht wird wahrscheinlich durch die stetige Änderung der ESP SPI verursacht. Bitte das Anschauungsbeispiel "ipsec_esp_capture_1.tgz":
https://wiki.wireshark.org/SampleCaptur ... ture_1.tgz
studieren. Der Wireshark-Anzeigefilter "ipv6" ist zu empfehlen.
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

Re: [Gelöst] ESP Paketverluste über IPv6 (1und1?)

Beitrag von beki »

Copy'n'Paste aus dem 1und1 Kundenforum, weil ich faul bin:
Hallo zusammen,

nach praktisch einem halben Jahr komme ich heute wieder zu diesem Thema. Die Rückmeldungen waren sehr spärlich, daher hatte ich mich gezwungen dieses Thema zur Seite zu legen, damit ich nicht ungeduldig werde. Mein VPN Tunnel zu meinen Eltern war unter IPv4 stabil.

Heute habe ich die Tests (mehrere Varianten) wiederholt. Es kommen nun alle Testpakete an ihrem Ziel an. Ich habe nun den Tunnel auf IPv6 umgeschwenkt. Der Tunnel funktioniert und ich hoffe, dass er zuverlässig ist (Erinnerung: Das Symptom war, dass der Tunnel häufig und zufällig zusammengebrochen war, offenbar abhängig vom neu gewählten ESP SPI).

=> Gelöst!

Mir ist völlig intransparent, ob meine ausführliche Fehlermeldung tatsächlich jemanden aktiviert und geholfen hat oder ob es andere Umstände gibt, dass das Problem nicht mehr auftritt. Leider habe ich versäumt, die Tests kurz vor meiner Tarifumstellung auf DSL100 zu wiederholen. Und auch nicht, als ich plötzlich und positiv überrascht feststellte, dass VDSL Vectoring eingeschaltet wurde....

Das ist arg unbefriedigend. Ich hätte mich sehr gefreut, einen technischen Dialog über das Problem zu führen, stattdessen hat man mich um Geduld gebeten und ich hab keine Rückmeldung, wo in etwa das Problem behoben wurde oder ob meine Vermutung korrekt war. Schade.

Gruß
Antworten