[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

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

Beitrag von beki »

Hallo zusammen!

TL;DR:
Weiß jemand von Fällen in denen auf IPv6 aufbauende ESP Pakete vom Provider unter gewissen Umständen nicht zugestellt werden?

Hintergrund:

Setup:
  • 2 LANCOM 1781VA 10.12RU5
  • jeweils 1und1 VDSL Anschluss
  • IKEv2 Site2Site
  • IPv6 als Transport
Status:
  • VPN-Verbindung kommt zustande
  • Verbindungsaufbau benötigt oft mehrere Anläufe
  • VPN-Verbindung tunnelt IPv4 (funktioniert zeitweise)
  • Re-Keying führt zu Problemen
  • Nutzung von ESP auf IPv4: Keine Probleme!
  • Child-SA Lebenszeit auf 60s beschränken => Regelmäßig lange Ausfallzeiten nach Re-Keying
Analyse:
  • Manche ESP Pakete kommen nicht bei der Gegenstelle an (VDSL-LL Packet Capture)
  • Untersuchung mittels manueller Erzeugung von ESP Paketen (Source Code siehe Anhang)
  • Manipulation des SPI im ESP (restliche Werte im Paket unverändert)
  • Beginnt der SPI mit 0x00, 0x2bff (erstes Byte 43), 0x32ff (erstes Byte 50), 0x33ff (erstes Byte 51) oder 0x3cff (erstes Byte 60) so kommt das ESP Paket nicht am Ziel an
  • Weitere SPI-Werte gefunden, welche die Zustellung verhindern (z.B. 0xfffeffff, 0x2a070000)
  • Setzt man den Next-Header Wert im IPv6 Header auf 59 (no next header), dann werden alle Pakete zugestellt (https://www.iana.org/assignments/protoc ... bers.xhtml)
Ich sehe hier ein Softwareproblem (oder Konfigurationsproblem?) bei meinem ISP (1und1) oder gar anderer beteiligter Netzwerke.

Für mich sieht es sehr stark danach aus, als würde
  • mindestens ein Router versuchen den Header nach dem ESP Header zu finden
  • abhängig vom ersten Byte des ESP SPI (IPv6 header extenstion next header)
  • abhängig vom zweiten Byte des ESP SPI (IPv6 header extension length)
Dabei rastet dieser aus, weil er in den verschlüsselte Daten unerwartete Werte findet oder weil das Längenfeld suggeriert der nächste Header läge außerhalb der Nutzdaten.

ESP ist ein "IPv6 extended Header" (siehe Link oben), aber nur aus Sicht des Hosts, welcher das ESP entschlüsselt hat. Für jeden anderen Router sollten die Daten transparent sein. Versucht man den ESP Header zu behandeln wie sonst jeden anderen IPv6 extended Header, dann würde man versuchen in den ersten zwei Byte des SPI des ESP Paketes nach einem Next Header Byte und nach einer Header Länge zu suchen. Dabei kommt Unfug heraus. Das Verhalten, welches ich beobachte, suggeriert, dass genau das geschieht. Nicht umsonst sind ausgerechnet ESP Pakete mit SPI 0x2b, 0x32, 0x33 und 0x3c startend betroffen: Genau diese Werte suggerieren weitere IPv6 extension Header.

Heute habe ich bei 1und1 nachgefragt, aber Sonntags sind da nur die first-level Leute. Morgen würde ich gerne versuchen bei 1und1 jemanden zu erwischen der etwas darüber weiß, dass ESP Pakete mit bestimmten SPI im Nirvana landen.

Gruß

EDIT 2018-08-24: Das Problem tritt nicht mehr auf. VPN Tunnel auf IPv6 umgestellt.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von beki am 12 Feb 2018, 21:07, insgesamt 1-mal geändert.
5624
Beiträge: 865
Registriert: 14 Mär 2012, 12:36

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

Beitrag von 5624 »

Sieht das Problem vergleichbar aus, wenn du den Tunnel über IPv4 aufbaust?
LCS NC/WLAN
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 »

5624 hat geschrieben:Sieht das Problem vergleichbar aus, wenn du den Tunnel über IPv4 aufbaust?
Das Problem tritt mit IPv4 nicht auf (wie oben erwähnt).
5624
Beiträge: 865
Registriert: 14 Mär 2012, 12:36

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

Beitrag von 5624 »

Sorry, dreimal gelesen und doch übersehen.

Jetzt wäre noch interessant, über welche Provider die Anschlüsse realisiert werden, 1&1 hat ja nur sehr wenig eigenes Netz, das meiste ist zugekauft. Nicht, dass die Anschlüsse von zwei Providern kommt und es da Probleme beim Interconnect gibt.

Wenn IPv4 läuft, würde ich erstmal auf die Antwort vom Provider warten. Wenn die negativ ist, registriere mal bei Hurricane Electric einen IPv6-Tunnel und nutz den auf einer Seite, die andere Seite bleibt bei 1&1.
LCS NC/WLAN
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 »

5624 hat geschrieben:registriere mal bei Hurricane Electric einen IPv6-Tunnel und nutz den auf einer Seite, die andere Seite bleibt bei 1&1.
Wow, das war ja eigentlich nur eine Fingerübung!

Geil! Vielen Dank für den Tipp! Das bekräftigt meinen Standpunkt sehr, denn:

Wenn ich am lokalen LANCOM den 6in4 Tunnel anlege und alles fein einrichte, sodass mein IPv6 Verkehr über diesen Tunnel läuft, dann erreichen alle Test-ESP-Pakete das Ziel bei meinem Eltern.

Sobald ich das zurückbaue und wieder die 1und1 Route nehme, kommen von den gleichen (Ausnahme Quell-IPv6-Adresse) 32 Paketen nur 9 Stück an.



EDIT: War: "Aber offenbar nur für Testzwecke brauchbar, denn ich habe keine feste IPv4 Adresse..." Nice! Ich sichere mir mein festes IPv6 Präfix! genial! https://forums.he.net/index.php?topic=1994.0
5624
Beiträge: 865
Registriert: 14 Mär 2012, 12:36

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

Beitrag von 5624 »

Ich hab mein Prefix seit ich glaube 10 Jahren bzw. sogar zwei Prefixe. Einmal das normale /56er und dann noch ein geroutetes /48er dazu. Durch die Tunneltechnik und weil Amsterdam überlastet ist, merkt man schon Performanceeinbußen, aber als Unitymediakunde ist man Schmerz gewöhnt.

Dann hau Aans´n´aans mal auf die Finger.
LCS NC/WLAN
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 »

Habe heute mit drei Menschen bei 1und1 telefoniert und ne Dreiviertelstunde Zeit investiert. Keiner von den Menschen am anderen Ende war in der Lage mein Problem zu verstehen oder mich mit einem Experten in Kontakt zu bringen.

In der Hoffnung, dass jemand angemessen darauf eingeht, habe ich einen ausführlichen Beitrag im 1und1 Kundenforum geleistet und den "an Support weiterleiten" Knopf aktiviert.

Mal sehen, ob dabei etwas rauskommt.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Nicht das erste Mal wo sich jemand über VPN-Tunnelprobleme beim Einsatz von IPv6 beklagt. Deshalb sollte die Fehlereingrenzung systematisch und gründlich erfolgen. Ich empfehle folgendes Vorgehen:

1.) Überprüfung der LANCOM-VPN-Konfiguration:
http://www.lancom-forum.de/fragen-zum-t ... tml#p91268

Den aktuellen Konfigurationswert des Anti-Replay-Schutz hier veröffentlichen:

Code: Alles auswählen

Setup/VPN/Anti-Replay-Window-Size
2.) Die Netzwerkverbindung zwischen den beiden LANCOM-Geräten mit IPerf2/IPerf3 ausmessen (UDP-Messungen mit dem LANCOM-internen IPerf2). Messungen einmal für IPv4 und einmal für IPv6 durchführen. Messresultate der UDP-Messungen hier vollständig veröffentlichen.
http://www.lancom-forum.de/lancom-allge ... 16579.html

3.) Mit der "Packet Capture"-Funktion den Netzwerkverkehr auf der VDSL-Schnittstelle (WAN) für 2 Minuten aufzeichnen ("Child SA"-Rekeying muss enthalten sein). Einmal für jeden VPN-Endpunkt. Dann beide Aufzeichnungen (*.pcap) in ein ZIP-Archiv verpacken und hier zur Wireshark-Analyse hochladen.
https://www2.lancom.de/kb.nsf/bf0ed2a4d ... d7003f3d69

4.) Mit Ping und dem Parameter "Don't fragment" die MTU der Netzwerkverbindung zwischen den beiden LANCOM-Routern herausfinden (ausserhalb des VPN-Tunnels!). Die relevanten Ping-Messresultate inklusive Ping-Parameter hier veröffentlichen.
https://de.wikipedia.org/wiki/Maximum_T ... l_Ethernet
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 »

GrandDixence hat geschrieben:Deshalb sollte die Fehlereingrenzung systematisch und gründlich erfolgen.
Die Fehlereingrenzung wurde bereits systematisch und extrem gründlich durchgeführt. Sie führte, wie im Anfangsposting beschrieben, zu der Erkenntnis, dass das Problem darin besteht, dass offensichtlich der Provider manche ESP Pakete nicht zustellt. Abhängig vom SPI. Es besteht kein Problem mit der Konfiguration.
GrandDixence hat geschrieben:Ich empfehle folgendes Vorgehen:
Nein.



Ich habe versäumt, den Dateianhang mit dem Quellcode für das Test-Tool anzuhängen. Das werde ich jetzt nachholen. Wäre toll, wenn jemand das an seinen Anschluss ausprobiert (Quell-, Ziel- und Next-Hop MAC müssen manuell angepasst werden) und zu ähnlichen Erkenntnissen kommt!
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 »

Ohje, das Spielchen kann man nicht symmetrisch Spielen, wie es scheint:

Code: Alles auswählen

received 9/32:
sudo tcpdump -vv -n -i eth-nuc -w /tmp/esp.cap esp
tcpdump: listening on eth-nuc, link-type EN10MB (Ethernet), capture size 262144 bytes
[...]
tcpdump -n -r /tmp/esp.cap
reading from file /tmp/esp.cap, link-type EN10MB (Ethernet)
23:24:32.678822 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x00040000,seq=0x12), length 120
23:24:32.742324 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x01000000,seq=0x18), length 120
23:24:32.750059 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x02000000,seq=0x19), length 120
23:24:32.760071 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x04000000,seq=0x1a), length 120
23:24:32.770312 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x08000000,seq=0x1b), length 120
23:24:32.780315 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x10000000,seq=0x1c), length 120
23:24:32.790564 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x20000000,seq=0x1d), length 120
23:24:32.800578 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x40000000,seq=0x1e), length 120
23:24:32.811249 IP6 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d > 2003:e3:93bf:e00:baae:edff:fe73:7fb0: ESP(spi=0x80000000,seq=0x1f), length 120

Code: Alles auswählen

received 11/32:
sudo tcpdump -vv -n -i eth-nuc -w /tmp/esp.cap esp
tcpdump: listening on eth-nuc, link-type EN10MB (Ethernet), capture size 262144 bytes
[...]
tcpdump -n -r /tmp/esp.cap
reading from file /tmp/esp.cap, link-type EN10MB (Ethernet)
23:20:29.150732 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x00020000,seq=0x11), length 120
23:20:29.160786 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x00040000,seq=0x12), length 120
23:20:29.170919 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x00080000,seq=0x13), length 120
23:20:29.221145 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x01000000,seq=0x18), length 120
23:20:29.231016 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x02000000,seq=0x19), length 120
23:20:29.241402 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x04000000,seq=0x1a), length 120
23:20:29.250783 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x08000000,seq=0x1b), length 120
23:20:29.260932 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x10000000,seq=0x1c), length 120
23:20:29.270920 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x20000000,seq=0x1d), length 120
23:20:29.280798 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x40000000,seq=0x1e), length 120
23:20:29.290862 IP6 2003:e3:93bf:e00:baae:edff:fe73:7fb0 > 2003:ee:bbbf:256:f64d:30ff:fe65:bb9d: ESP(spi=0x80000000,seq=0x1f), length 120
Warum kommt SPI 0x00020000 bei Host sutter an, aber nicht bei Host ritchie? Das gleiche für 0x00080000...

Spricht das gegen meinen Erklärungversuch (Next-Header Fehlinterpretation)? Was könnte die Ursache dafür sein, dass die beiden Pakete nur in eine Richtung verloren gehen?

Kann ich irgendwie herausfinden, welche Route die Pakete jeweils nehmen (traceroute scheint mir unzureichend)?
Zuletzt geändert von beki am 21 Feb 2018, 20:19, insgesamt 1-mal geändert.
Grund: typo
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 »

Ein gewissen Jörg von 1und1 hat sich im Kundenforum auf meinen Beitrag gemeldet. Natürlich hat er mich gefragt, ob das Problem auch mit Fritzboxen auftritt. Also habe ich mir die Mühe gemacht und lokal als auch bei meinem Eltern eine FB als CPE eingeklemmt.

Das Problem besteht genau so wie mit den LANCOMs als CPEs. IMHO ein klarer Freispruch für die LANCOMs.

Jetzt bin ich gespannt, ob nochmal jemand reagiert.

Als Anhang die Paketmitschnitte der Fritzboxen, welche das Verhalten verdeutlichen sollen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

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

Beitrag von Dr.Einstein »

Hi beki,

da 1und1 doch kein eigenes Backbone im eigentlichen Sinne hat, wird es eh ein Problem bei Vodafone, Telekom oder wem auch immer sein, bzw. da bei einem der Routerhersteller / Firmwareversionen.

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Hallo beki,
beki hat geschrieben:Also habe ich mir die Mühe gemacht und lokal als auch bei meinem Eltern eine FB als CPE eingeklemmt.
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. Da kann man dann auf Ethernet-Ebene wunderbar monitoren (LANCOM: Monitor-Port, oder, wenn man dem LANCOM gar nicht traut, dann mit entsprechender Switch dazwischen).

Ansonsten schön geschrieben da im 1&1-Kundenforum, auch wenn Du Deine eigene Mutmaßung im Verlauf in Frage stellst (ich kann das gut nachempfinden).

Ich hoffe, Du bekommst da wieder eine Antwort.
Dr.Einstein hat geschrieben:da 1und1 doch kein eigenes Backbone im eigentlichen Sinne hat, wird es eh ein Problem bei Vodafone, Telekom oder wem auch immer sein, bzw. da bei einem der Routerhersteller / Firmwareversionen.
Genau: Telekom, Telefónica, QSC, ...? Bei wem seid Ihr denn in Wirklichkeit, beki? Weißt Du das? VLAN-ID und IP-Adresse können da weiterhelfen. Das wurde im Thread übrigens schon mal gefragt.
Dr. Einstein, hälst Du es damit für möglich, dass das an Telekom-Anschlüssen auch ist?

Viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

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

Beitrag von Dr.Einstein »

Jirka hat geschrieben: Dr. Einstein, hälst Du es damit für möglich, dass das an Telekom-Anschlüssen auch ist?
Ersten Tests nach ja ... aber jetzt fällt mir nur ein passendes Wort dazu ein: 'tja' ... und weiter ;) ? Ohne Connections kommst du bei Telefonica, QSC, Telekom oder wem auch immer niemals bis zum Coreteam durch. Und selbst dann muss noch jemand in der Lage dazu sein, das Problem zu verstehen und selbst auch zu analysieren. Coreteams kümmern sich doch vor allem um Routing, Auslastungen etc also musst du auch da den "1st" Level im Core passieren und zum 2nd Level weiter.

Könnte mir höchstens vorstellen, dass z.B. bei Lancom, AVM, Zyxel jeweils zwei drei Leute existieren, die gute Verbindungen zu den Providern in Deutschland haben. Die haben Chancen.

Gruß Dr.Einstein
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Im Fritzbox Paketmitschnitt ""2018-02-21_19-35_7412_sender.pcap" beanstandet die Fritzbox 7490 (korrekterweise) in Frame 18 per ICMP das IPv6-Paket mit dem ESP-Paket mit der Sequenznummer 17, dass dieses IPv6-Paket im Header einen nicht korrekten Wert für "unrecognized next header type" enthält. Das ESP-Paket mit der Sequenznummer 17 ist in den Wireshark-Aufzeichnungen von Fritzbox 7412 nicht sichtbar, jedoch wird dieses ESP-Paket von der Fritzbox 7490 empfangen und korrekterweise beanstandet!

a) Es werden von der Fritzbox 7412 IPv6-Pakete versendet, die einen nicht korrekten IPv6-Header enthalten (next header type).
b) Die Wireshark-Aufzeichnungen sind lückenlos. Zwischen Frame 4 und Frame 5 fehlen einige (per ICMP nachweislich) von der Fritzbox 7412 versendete IPv6-Pakete! Eine seriöse Fehlersuche sieht anders aus...

Ich denke, die Probleme liegen vor der Tastatur...

https://de.wikipedia.org/wiki/Wireshark
Antworten