Warum IPsec + DS-Lite = kein Homeoffice

Ein tiefes Tauchen in das Drama zwischen Dual-Stack Lite, NAT444, IPsec und dem Wunsch, von zuhause arbeiten zu können - plus der Lösung, die tatsächlich funktioniert.

Das Problem: "Mein VPN funktioniert nicht!"

Es ist Montagmorgen. Ein Mitarbeiter sitzt im Homeoffice, öffnet seinen VPN-Client und klickt auf Verbinden. Der Client dreht, dreht, dreht - und bricht dann ab. Fehlermeldung: Connection timed out. Der IT-Helpdesk ist ausgelastet, und niemand versteht, warum es bei manchen Kollegen funktioniert und bei anderen nicht.

Die Antwort liegt tief in der Infrastruktur des Internetanschlusses: DS-Lite - ein Übergangsmechanismus, der den schwindenden IPv4-Adressraum verwaltet, dabei aber IPsec-basierten VPN-Verbindungen das Leben nahezu unmöglich macht.

Kurzfassung für Eilige

DS-Lite bedeutet: kein natives IPv4 mehr am Kundenanschluss. IPsec benötigt aber natives IPv4. Shared NAT über CGN zerstört IPsec-Sessions. Die Lösung: IPv6-natives IPsec am Gateway aktivieren und IPv4-Traffic darüber tunneln.

Was ist DS-Lite überhaupt?

Dual-Stack Lite (DS-Lite) ist ein Übergangsmechanismus, der in RFC 6333 definiert wurde. Er wurde entwickelt, weil der IPv4-Adressraum (4,3 Milliarden Adressen) spätestens seit 2011 global erschöpft ist.

Das Grundprinzip: Der Heimanschluss bekommt vom Provider eine vollwertige, öffentliche IPv6-Adresse. IPv4-Traffic hingegen wird in einen IPv6-Tunnel gepackt und durch das Netz des Providers zu einem sogenannten AFTR (Address Family Transition Router) geleitet. Dort wird der IPv4-Traffic ausgekapselt und über eine gemeinsam genutzte, öffentliche IPv4-Adresse ins Internet geroutet - bekannt als Carrier-Grade NAT oder CGN / NAT444.

Für normale Webseiten, Streaming, E-Mail - alles kein Problem. Das Problem beginnt, sobald man protokollspezifische Anforderungen hat - wie IPsec-basiertes VPN.

Welche Provider setzen DS-Lite ein - und welche nicht?

Das Thema DS-Lite vs. Dual-Stack ist in Deutschland stark technologieabhängig. Die entscheidende Trennlinie verläuft nicht allein zwischen Anbietern, sondern zwischen Anschlusstechnologien.

Hinweis: "DS-Lite" vs. "CGNAT"

Manche Provider (z.B. Deutsche Glasfaser) verwenden technisch gesehen kein DS-Lite nach RFC 6333, sondern Dual-Stack mit CGNAT. Das Ergebnis für den Endkunden ist jedoch identisch - keine öffentliche IPv4-Adresse, kein funktionierendes IPsec-VPN.

Dual-Stack nativ - öffentliche IPv4 standardmäßig inklusive

• Deutsche Telekom (DSL & Glasfaser/FTTH): Dual-Stack nativ, öffentliche dynamische IPv4 standardmäßig. Kein DS-Lite, keine CGN für Privatkunden.
• O2 / Telefonica (DSL & Glasfaser über Telekom-Vorleisternetz): Dual-Stack nativ. DS-Lite nur für Kabelanschlüsse.
• 1&1 (DSL über Telekom-Netz WIA): Vollwertiges Dual-Stack. Bei Versatel-Anbindung teils andere Mechanismen - Vorleisternetz vorab prüfen.

Kein natives IPv4 - CGNAT oder DS-Lite für alle Privatkunden

• ueDeutsche Glasfaser (FTTH): Ausschliesslich IPv6 + CGNAT-IPv4 (100.64.x.x). Öffentliche IPv4 nur für Geschäftskunden gegen Aufpreis. IPsec-VPN ohne Gateway-Anpassung nicht möglich.
• O2 / Telefonica Kabel: Ausschliesslich DS-Lite. Umstellung auf Dual-Stack für Privatkunden nicht möglich, auch nicht auf Anfrage.
• Pyur / Tele Columbus (Kabel, Ostdeutschland/Berlin): Nur DS-Lite. Zuverlässige Umstellung auf Dual-Stack für Privatkunden nicht vorgesehen.

DS-Lite Standard - natives IPv4 gegen Aufpreis oder auf Anfrage

• Vodafone Kabel (ehem. Unity Media West/Nord): DS-Lite Standard. Dual-Stack mit dynamischer öffentlicher IPv4 auf Anfrage bei der Technik-Hotline als Kulanzleistung kostenlos aktivierbar. Feste IPv4 nur im Business-Tarif kostenpflichtig.
• M-net (Glasfaser & DSL, München/Bayern): DS-Lite als Standard. Dual-Stack als IPv4-Option gegen ca. 4,90 EUR/Monat zubuchbar.

Achtung: Providerwechsel löst das Problem nicht immer

Wer von einem Kabel- oder Glasfaser-CGNAT-Anbieter zum nächsten wechselt, tauscht DS-Lite gegen DS-Lite. Ein Wechsel auf DSL oder Telekom-Glasfaser löst das Problem vollständig.

IPsec: Was es braucht und warum es scheitert

IPsec ist das Rückgrat der meisten unternehmens- und behördlichen VPN-Lösungen: Cisco AnyConnect, Fortinet, Palo Alto GlobalProtect, Check Point, strongSwan - alle basieren im Kern auf IPsec.

Die drei kritischen IPsec-Protokolle

• IKE / IKEv2 — Port / Kennung: UDP 500 · Funktion: Schlüsselaushandlung, SA-Aufbau (Security Associations)
• ESP — Port / Kennung: IP-Protokoll 50 · Funktion: Verschlüsselung und Authentifizierung der Datenpakete
• NAT-T — Port / Kennung: UDP 4500 · Funktion: NAT Traversal - Fallback wenn ESP nicht direkt läuft

ESP (Encapsulating Security Payload) hat keine Portnummern - NAT-Router können ESP-Pakete daher nicht unterscheiden und zuordnen. Das ist der erste fundamentale Konfliktpunkt.

Das NAT-Problem bei ESP

NAT arbeitet auf Basis von IP-Adressen und Portnummern (TCP/UDP). ESP hat keine Portnummern. Ein NAT-Router kann ESP-Pakete mehrerer gleichzeitiger Clients nicht korrekt zuordnen - simultane ESP-Sessions hinter demselben NAT stören sich gegenseitig.

NAT-T als Pflaster - und warum es bei CGN reißt

NAT Traversal (NAT-T) kapselt ESP-Traffic in UDP-Pakete auf Port 4500 - jetzt hat man wieder Portnummern. NAT-T funktioniert gut bei einfachem NAT. Aber bei DS-Lite oder CGNAT gibt es zwei Übersetzungsebenen über drei Adressräume (NAT444) - und das ist für IPsec kaum zu bändigen.

DS-Lite / CGNAT vs. klassischer Dual-Stack-Anschluss

Probleme mit IPsec bei DS-Lite / CGNAT:

• Keine eigene öffentliche IPv4-Adresse
• CGN blockiert / verwirft ESP (Proto 50)
• UDP 500 / 4500 werden durch CGN oft nicht stabil weitergeleitet
• Session-Timeouts durch aggressive NAT-State-Tables im CGN
• Mehrere Kunden teilen dieselbe IPv4 - Port-Kollisionen
• Kein eingehendes IPsec möglich (kein Port-Forwarding durch CGN)

Vorteile eines klassischen Dual-Stack-Anschlusses:

• Eigene öffentliche IPv4-Adresse (auch wenn dynamisch)
• Direktes NAT auf Heimrouter-Ebene kontrollierbar
• ESP passiert nur ein NAT-Layer
• NAT-T funktioniert zuverlässig
• Port-Forwarding möglich
• DynDNS kompensiert dynamische IP

Die technischen Versagenspunkte im Detail

1. Das CGN-Timeout-Problem

CGN-Implementierungen entfernen inaktive Sessions aggressiv aus der State-Table. Typische UDP-Timeouts liegen bei 30-120 Sekunden - deutlich unter den Standard-IKE-Keepalive-Intervallen vieler VPN-Clients. Der Tunnel baut sich kurz auf, das CGN räumt den State-Eintrag auf, alle weiteren Pakete landen im Nirgendwo.

2. Das Port-Kollisions-Problem

Hunderte Kunden teilen sich eine öffentliche IPv4-Adresse. Alle versuchen gleichzeitig eine IKE-Verbindung auf UDP 500 zum gleichen Unternehmens-VPN-Gateway aufzubauen. Das CGN muss Sessions mit unterschiedlichen Source-Ports zum gleichen Ziel durchleiten - das führt zu Stabilitätsproblemen und Paketverwürfen.

3. Das ESP-Protokoll-Problem

Viele CGN-Implementierungen unterstützen nur TCP und UDP. IP-Protokoll 50 (ESP) wird schlicht verworfen (DROP) - ohne ICMP Unreachable. Selbst wenn NAT-T aktiviert ist, bleibt das Timeout- und Stabilitätsproblem des CGN bestehen.

4. Das eingehende Verbindungs-Problem

Manche VPN-Architekturen benötigen eingehende IPsec-Verbindungen. Bei DS-Lite oder CGNAT ist das schlicht unmöglich: Port-Forwarding durch ein CGN, das man als Endkunde nicht kontrolliert, ist nicht realisierbar.

Realität im Support

In der Praxis sieht das so aus: IPsec-VPN funktioniert bei Mitarbeitern mit einem klassischen Internetanschluss mit nativer IPv4 einwandfrei. Bei Kollegen mit DS-Lite oder CGNAT - Vodafone, Pyur und viele weitere lokale Anbieter - funktioniert es gar nicht oder nur sporadisch. Die IT sieht das oft als Benutzerproblem, dabei ist es ein fundamentales Netzarchitektur-Problem des Anschlusses.

Selbst-Test: Habe ich DS-Lite oder CGNAT?

Erkennen kann man DS-Lite daran, dass der Router intern eine IP-Adresse aus dem 100.64.0.0/10-Bereich (RFC 6598) erhält und beim Aufruf einer IP-Prüfseite eine andere IPv4 angezeigt wird.

1. Router-Weboberfläche öffnen und die WAN-IPv4-Adresse notieren
2. Die Website wieistmeineip.de aufrufen und die angezeigte öffentliche IPv4 notieren
3. Wenn beide IPs unterschiedlich sind: CGN ist aktiv - DS-Lite oder CGNAT wahrscheinlich
4. Wenn die WAN-IP im Bereich 100.64.x.x liegt: CGN zu 100% bestätigt
5. Prüfen ob eine globale IPv6-Adresse zugewiesen wurde - ebenfalls über wieistmeineip.de erkennbar

Die Lösung: IPv6-natives IPsec am Gateway

DS-Lite- und CGNAT-Anschlüsse haben zwar kein natives IPv4, aber eine vollwertige, öffentliche IPv6-Adresse - direkt erreichbar, ohne CGN, ohne geteilten Adressraum. Die Lösung nutzt genau das.

Teil 1: Das Unternehmens-VPN-Gateway erhält eine öffentliche IPv6-Adresse und einen AAAA-DNS-Eintrag. Der Homeoffice-Mitarbeiter baut den IPsec-Tunnel direkt über IPv6 auf - komplett am CGN vorbei.

Teil 2: Sobald der Tunnel über IPv6 steht, wird der gesamte IPv4-Traffic des Mitarbeiters durch diesen Tunnel geroutet. Das Gateway übernimmt das IPv4-Routing intern.

Voraussetzungen auf Gateway-Seite

1. Dual-Stack-Konnektivität: Öffentliche IPv6-Adresse am VPN-Gateway einrichten
2. IKEv2 auf IPv6-Socket: VPN-Daemon auf dem IPv6-Interface lauschen lassen - keine Protokolländerungen nötig
3. Traffic Selectors: IPv4-Subnetze (z.B. 10.0.0.0/8) über den IPv6-Tunnel erreichbar machen
4. Firewall-Regeln für IPv6: UDP 500 und 4500 auf der IPv6-Adresse freigeben - häufig vergessen!
5. DNS AAAA-Record: VPN-Hostname bekommt einen AAAA-Record - moderne VPN-Clients priorisieren IPv6 automatisch

Angenehmer Nebeneffekt

Bei DS-Lite- und CGNAT-Anschlüssen ist IPv6 oft direkter geroutet als der IPv4-Umweg über AFTR und CGN. Benutzer sehen nach der Umstellung häufig sogar eine bessere VPN-Performance.

Mögliche Client-seitige Fallstricke

• Client verbindet nur per IPv4 — Ursache: Kein AAAA-Record oder Client forciert IPv4 · Lösung: AAAA-Record setzen, Client-Config prüfen
• IPv6 im Client deaktiviert — Ursache: Alte Gruppenrichtlinie oder Registry-Eintrag · Lösung: GPO anpassen: IPv6 auf Client-OS aktivieren
• Split-Tunnel kappt IPv6 — Ursache: VPN-Policy routet auch IPv6-Traffic intern · Lösung: Traffic-Selectors und Routing-Policy prüfen
• Firewall auf Client blockiert IKE — Ursache: Windows-Firewall blockiert UDP auf IPv6-Interface · Lösung: Eingehende UDP 500/4500 auf IPv6 freigeben

Zusammenfassung: Das Rezept

1. Gateway mit Dual-Stack ausstatten: Öffentliche IPv6-Adresse am VPN-Gateway einrichten
2. AAAA-DNS-Eintrag setzen: VPN-Hostname bekommt sowohl A- als auch AAAA-Record
3. IKEv2 auf IPv6-Socket aktivieren: VPN-Daemon auf IPv6-Interface lauschen lassen
4. Firewall-Regeln für IPv6: UDP 500 und 4500 auf der IPv6-Adresse freigeben
5. IPv4 Traffic Selectors konfigurieren: Interne IPv4-Subnetze über den IPv6-Tunnel erreichbar machen
6. DPD-Intervall verkürzen: Dead Peer Detection auf 10-15 Sekunden für bessere Stabilität
7. Testen mit DS-Lite-Anschluss: Testlaptop an DS-Lite-Router anschliessen und Verbindung verifizieren

Fazit

DS-Lite und CGNAT sind die Realität bei einem wachsenden Anteil deutscher Internetanschlüsse - bei Kabelanbietern flächendeckend, bei regionalen Glasfaseranbietern wie Deutsche Glasfaser ebenfalls. IPsec-basierte VPNs, die nur auf IPv4 ausgelegt sind, werden für diese Nutzer schlicht nicht funktionieren. Die einzige robuste Lösung ist, IPv6 am Gateway zu aktivieren und den IPsec-Tunnel nativ über IPv6 aufzubauen.

Sie haben trotzdem Probleme mit Ihrer VPN-Verbindung?

Nicht jede Umgebung ist gleich - manchmal steckt der Teufel im Detail: eine restriktive Firewall-Regel, ein veralteter VPN-Client oder eine unerwartete Provider-Konfiguration. Wenn Sie nach der Umstellung auf IPv6-basiertes IPsec noch immer keine stabile Homeoffice-Verbindung aufbauen können, helfen wir Ihnen gerne weiter. Sprechen Sie uns an - wir analysieren Ihre konkrete Infrastruktur und unterstützen Sie Schritt für Schritt bei der Fehlerbehebung.