Netzwerk & WAN
IPsec
IPsec ist ein Standard-Protokollrahmen, der IP-Pakete authentifiziert und verschlüsselt und damit die Grundlage der meisten Site-to-Site-VPNs bildet.
- Layer-3-Sicherheitssuite
- ESP: Verschlüsselung + Integrität
- IKEv2 (IKEv1 abgelöst)
- IETF-Standard
- AES-GCM, AES-NI-beschleunigt
IPsec ist keine einzelne Anwendung, sondern eine Sicherheitssuite, die IP-Verkehr direkt auf Schicht 3 absichert (RFC 4301), für IPv4 und IPv6 gleichermaßen. Sie liefert Vertraulichkeit, Integrität, Authentizität und Schutz gegen das Wiedereinspielen von Paketen.
Dieser Artikel erklärt die Schutzprotokolle AH und ESP, Transport- und Tunnel-Modus, den Schlüsselaustausch mit IKEv2 (und warum IKEv1 abgelöst ist), die Datenbanken SA/SPD/SAD, die empfohlene Kryptografie samt PFS, NAT-Traversal, MTU-Fragen und die häufigsten Konfigurationsfehler.
1. AH und ESP: die zwei Schutzprotokolle
IPsec kennt zwei Schutzprotokolle. ESP (Encapsulating Security Payload, RFC 4303) liefert Verschlüsselung, Integrität und Authentizität, AH (Authentication Header, RFC 4302) nur Integrität und Authentizität, ohne Verschlüsselung.
| Merkmal | ESP (Proto 50) | AH (Proto 51) |
|---|---|---|
| Verschlüsselung | ja | nein |
| Integrität/Authentizität | ja | ja (auch über den äußeren IP-Header) |
| NAT-tauglich | ja (mit NAT-T) | nein (NAT bricht die Integritätsprüfung) |
| Praxis heute | Standard | kaum noch genutzt |
Warum fast nur ESP
AH bezieht den IP-Header in die Integritätsprüfung ein und ist dadurch mit NAT unverträglich. Da NAT praktisch überall vorkommt, nutzt man ESP, das mit einem AEAD-Verfahren wie AES-GCM Verschlüsselung und Integrität ohnehin in einem Schritt erledigt.
2. Transport- und Tunnel-Modus
Im Transport-Modus bleibt der originale IP-Header stehen, geschützt wird nur die Nutzlast; das passt für Host-zu-Host zwischen zwei IPsec-fähigen Endpunkten. Im Tunnel-Modus wird das gesamte innere IP-Paket gekapselt und ein neuer äußerer IP-Header vorangestellt; das ist der Modus für Gateways, die Netze dahinter schützen, also der Normalfall bei Site-to-Site und Remote-Access.
3. IKE: Schlüsselaustausch mit IKEv2
Bevor Verkehr fließt, handeln die Partner über IKE Algorithmen und Schlüssel aus. IKEv2 (RFC 7296) ist der aktuelle Standard: Es braucht nur zwei Nachrichtenpaare (IKE_SA_INIT für Krypto und Diffie-Hellman, IKE_AUTH für Authentifizierung und erste Child-SA), kennt eingebaute Lebendigkeitsprüfung, EAP für Remote-Access und MOBIKE (Adresswechsel ohne Neuaufbau, RFC 4555).
IKEv1 ist seit RFC 9395 (2023) formell abgelöst: Die ursprünglichen IKEv1-RFCs wurden auf Historic gesetzt. Sein Aggressive Mode überträgt den PSK-Hash angreifbar; die BSI-Richtlinie TR-02102-3 trifft nur noch Aussagen zu IKEv2. Für neue Setups ist IKEv1 keine Option mehr.
IKEv2 ist nicht nur ein Update, sondern der einzige zukunftsfähige Weg: weniger Roundtrips, kein unsicherer Aggressive Mode, MOBIKE für mobile Clients und integrierte Liveness. IKEv1 ist abgelöst und sollte abgeschaltet werden.
4. SA, SPD und SPI
IPsec verwaltet seinen Zustand in Datenbanken. Eine Security Association (SA) ist die ausgehandelte Schutzbeziehung und immer gerichtet: Eine bidirektionale Verbindung braucht zwei SAs. Identifiziert wird eine SA über den SPI (Security Parameter Index) im Paket. Die SPD (Security Policy Database) legt fest, welcher Verkehr geschützt, durchgelassen oder verworfen wird; die SAD hält die aktiven Schlüssel und Parameter.
5. Kryptografie: empfohlen und veraltet
Das Herz der Sicherheit sind die gewählten Algorithmen. AES-GCM ist ein AEAD-Verfahren und liefert Verschlüsselung und Integrität in einem Schritt (schnell, besonders mit AES-NI). Wichtig: Perfect Forward Secrecy (PFS) erzwingt beim Rekey einen frischen Diffie-Hellman, sodass ein später kompromittierter Schlüssel vergangene Sitzungen nicht preisgibt. Orientierung an RFC 8221 (ESP), RFC 8247 (IKEv2) und der BSI TR-02102-3:
strongSwan: empfohlene Suite (Proposal)
# IKE und ESP, AEAD mit ECDH P-384, PFS
ike = aes256gcm16-prfsha384-ecp384
esp = aes256gcm16-ecp384| Einsatz | empfohlen | vermeiden |
|---|---|---|
| Verschlüsselung (ESP) | AES-GCM (AEAD); ChaCha20-Poly1305 (nach RFC 8221) | 3DES, DES, NULL |
| Integrität | HMAC-SHA-256/384/512 | MD5, SHA-1 |
| DH-/ECP-Gruppe | ECP 256/384 (19/20) oder MODP ≥ 3072 (Gruppe 15+); Gruppe 14 nur für Altbestand | Gruppe 1/2/5 (≤ 1024-bit) |
| IKE-Version | IKEv2 (RFC 7296) | IKEv1 (Historic, RFC 9395) |
6. NAT-Traversal, DPD und Anti-Replay
ESP hat keine Ports und überlebt NAT nicht direkt. NAT-Traversal (RFC 3948) kapselt ESP daher in UDP auf Port 4500, sobald ein NAT auf dem Pfad erkannt wird. Dead Peer Detection erkennt tote Gegenstellen und räumt verwaiste SAs ab (in IKEv2 als Liveness-Check integriert). Gegen das Wiedereinspielen von Paketen schützt ein Sequenznummern-Fenster (Anti-Replay), bei sehr hohem Durchsatz mit Extended Sequence Numbers.
7. MTU, Overhead und MSS-Clamping
Die ESP-Kapselung kostet je nach Verfahren und NAT-T rund 54 bis 80 Byte. Bei 1500 Byte Außen-MTU bleiben dadurch nur noch etwa 1400 Byte nutzbar. Ist das DF-Bit gesetzt und werden ICMP-Fehlermeldungen unterwegs gefiltert, gehen große Pakete still verloren (PMTU-Blackhole). Robuste Abhilfe ist MSS-Clamping auf dem Tunnel-Pfad, sodass TCP-Segmente von vornherein in die Tunnel-MTU passen.
8. Typische Fehler in der Praxis
- IKEv1 Aggressive Mode mit PSK der PSK-Hash ist mitlesbar und offline angreifbar. Aggressive Mode mit PSK nie einsetzen; besser IKEv2 mit Zertifikaten.
- Schwache Algorithmen 3DES, MD5, SHA-1 und DH-Gruppen ≤ 1024 Bit sind angreifbar und gehören abgeschaltet.
- Kein PFS ohne frischen Diffie-Hellman beim Rekey gefährdet ein kompromittierter Schlüssel auch vergangene Sitzungen.
- Proposal-Mismatch unterschiedliche Algorithmen oder Lebensdauern auf beiden Seiten lassen die SA scheitern, oft schwer zu debuggen.
- IV-Wiederholung bei AES-GCM ein wiederholter Initialisierungsvektor pro Schlüssel bricht die Sicherheit; bei Zählerüberlauf muss neu ausgehandelt werden.
9. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Offener IETF-Standard, herstellerübergreifend interoperabel | Komplexe Suite; viele Optionen laden zu Fehlkonfiguration ein |
| ESP mit AES-GCM: Verschlüsselung und Integrität in einem Schritt | Ohne AES-NI/Hardware-Offload spürbar geringerer Durchsatz |
| Flexible, compliance-fähige Krypto (BSI/NIST), PFS | Schwache Defaults werden akzeptiert, wenn nicht explizit gesperrt |
| IKEv2 mit MOBIKE, EAP und integrierter Liveness | AH NAT-untauglich; NAT-T kostet Bytes und etwas CPU |
| Native Integration in Linux, Windows, macOS, iOS, Android | MTU-/Overhead-Management nötig (MSS-Clamping) |
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
IPsec im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.