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
- 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
- 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)
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)
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.