IPSec Site-to-Site konfigurieren: Praxisbeispiel mit Checkliste

Eine IPSec Site-to-Site konfigurieren-Aufgabe wirkt auf den ersten Blick wie „einfach zwei Firewalls verbinden“. In der Praxis scheitern viele Projekte jedoch nicht an der Verschlüsselung, sondern an Details: falsche Netz-Selektoren, fehlende Rückrouten, NAT im Pfad, unpassende MTU, unklare Rekey-Lifetimes oder asymmetrisches Routing im Failover. Genau deshalb lohnt ein sauberes Vorgehen mit einem konkreten Praxisbeispiel und einer Checkliste, die Sie vor dem Go-live abarbeiten. In diesem Beitrag richten wir ein IPSec Site-to-Site VPN mit IKEv2 zwischen „Zentrale“ und „Filiale“ ein – herstellerneutral, aber mit genügend technischer Tiefe, damit Sie die Einstellungen auf Ihrer Firewall, Ihrem Router oder einer Linux-Appliance (z. B. strongSwan) sicher abbilden können. Sie lernen, wie Sie das Design (Policy-based vs. Route-based) wählen, wie Sie Kryptoparameter modern festlegen, NAT-T und DPD sauber konfigurieren, welche Firewall-Regeln wirklich nötig sind und wie Sie typische Fehlerbilder schnell diagnostizieren. Ziel ist eine robuste Standortvernetzung, die sicher, auditierbar und betrieblich stabil ist.

Grundlagen: Was passiert bei IPSec Site-to-Site technisch?

Bei einem Site-to-Site-VPN bauen zwei Gateways (z. B. Firewall in der Zentrale und Router/Firewall in der Filiale) einen verschlüsselten Tunnel auf. Der Tunnel schützt den Datenverkehr, der zwischen definierten Netzwerken ausgetauscht wird. IPsec besteht dabei grob aus zwei Ebenen:

• IKE (Internet Key Exchange): Aushandlung von Schlüsseln und Parametern, Authentifizierung der Gegenstelle (oft IKEv2).
• ESP (Encapsulating Security Payload): Verschlüsselung und Authentifizierung des Datenverkehrs (IP-Protokoll 50), optional via UDP-Kapselung (NAT-T).

Für die Architektur und Begriffe sind RFC 4301 (IPsec Architecture) und für IKEv2 RFC 7296 die zentralen Referenzen.

Policy-based vs. Route-based: Welche Variante ist sinnvoll?

Bevor Sie Konfigurationen klicken, entscheiden Sie das Tunnelmodell. Es beeinflusst Troubleshooting, Skalierung und Interoperabilität.

Policy-based (Selector-/SPD-basiert)

• Der Tunnel „greift“, wenn Traffic zu definierten Netz-Selektoren passt (z. B. 10.10.0.0/16 ↔ 10.20.0.0/16).
• Vorteil: häufig schnell eingerichtet, besonders bei einfachen 1:1-Szenarien.
• Nachteil: bei vielen Netzen/Services wird es unübersichtlich, Troubleshooting kann schwieriger sein.

Route-based (VTI / Tunnel-Interface)

• Der Tunnel ist ein Interface (virtuell), und Routing entscheidet, welche Netze darüber laufen.
• Vorteil: skalierbarer, klarer für Routing/Failover, gut mit dynamischem Routing (z. B. BGP) kombinierbar.
• Nachteil: je nach Hersteller etwas mehr Grundsetup (Tunnel-IP, Routing, ggf. Policy).

Praxisempfehlung: Wenn Sie mehr als „ein paar“ Netze verbinden, Failover sauber planen oder dynamisches Routing nutzen wollen, ist Route-based in der Regel die langfristig bessere Wahl. Wenn es ein kleines, stabiles Setup mit wenigen Selektoren ist, kann Policy-based ausreichend sein.

Praxisbeispiel: Zentrale ↔ Filiale

Wir nehmen folgendes Szenario an (vereinfachte, aber realistische Werte):

• Zentrale (HQ): öffentliches Gateway 203.0.113.10, internes Netz 10.10.0.0/16
• Filiale (BR): öffentliches Gateway 198.51.100.20, internes Netz 10.20.0.0/16
• IKEv2 mit PSK (für das Beispiel); produktiv oft besser: Zertifikate
• ESP: AES-GCM, PFS aktiv (moderne DH/ECDH-Gruppe)
• NAT-T: aktiviert (falls NAT im Pfad ist; sicherheitshalber meist an)

Hinweis: Die IPs 203.0.113.0/24 und 198.51.100.0/24 sind Dokumentationsnetze und werden hier bewusst als Beispiel verwendet.

Schritt 1: Parameter festlegen (damit beide Seiten wirklich matchen)

Ein IPsec-Tunnel steht und fällt damit, dass beide Seiten kompatible Proposals/Parameter haben. Legen Sie diese Werte schriftlich fest, bevor Sie konfigurieren:

• IKE-Version: IKEv2
• Authentifizierung: PSK oder Zertifikate (X.509)
• IKE Proposal: z. B. AES-256-GCM, PRF passend, DH/ECDH-Gruppe (PFS/Key Exchange)
• ESP Proposal: z. B. AES-256-GCM, PFS aktiv (Gruppe festlegen)
• Lifetimes: IKE-SA und CHILD-SA (ESP) Laufzeiten/Rekey
• DPD: Dead Peer Detection (Interval/Timeout)
• NAT-T: ja (UDP/4500), falls NAT erkannt wird
• Selektoren (bei policy-based): lokale/remote Subnetze exakt

Für NAT-Traversal sind RFC 3947 und RFC 3948 die Referenzen (UDP-Kapselung von ESP, typischerweise Port 4500).

Schritt 2: Firewall-Ports und Vorbedingungen prüfen

Noch bevor Sie an Policies arbeiten, stellen Sie sicher, dass die Gateways sich überhaupt „sehen“ können.

• UDP/500: IKE
• UDP/4500: NAT-T (wenn NAT im Pfad oder wenn Geräte automatisch auf UDP-Kapselung wechseln)
• ESP (IP-Protokoll 50): wenn kein NAT-T genutzt wird (in vielen Netzen wird ESP direkt gefiltert; NAT-T ist deshalb praktisch)

Wenn Sie Cloud-Security-Groups oder Provider-Firewalls nutzen: Ports/Protokolle müssen auch dort freigegeben sein. Häufiger Fehler: lokal ist alles offen, aber die Cloud-SG blockt UDP/4500.

Schritt 3: Konfiguration policy-based (herstellerneutral)

Wenn Sie policy-based arbeiten, definieren Sie auf beiden Seiten die „Traffic Selectors“ (auch „Phase 2 Selectors“, „Proxy IDs“ oder SPD-Einträge genannt). In unserem Beispiel:

• HQ local: 10.10.0.0/16
• HQ remote: 10.20.0.0/16
• BR local: 10.20.0.0/16
• BR remote: 10.10.0.0/16

Typische GUI-Felder (sinngemäß):

• Remote Gateway: 198.51.100.20 (aus HQ-Sicht) / 203.0.113.10 (aus BR-Sicht)
• Authentication: PSK oder Zertifikat
• IKE Proposal: (z. B. AES-GCM + DH-Gruppe)
• ESP Proposal: (z. B. AES-GCM + PFS-Gruppe)
• Local/Remote Networks: Selektoren wie oben

Wichtig: Selektoren müssen exakt spiegeln. Ein kleiner Fehler (z. B. /24 vs. /16) führt oft dazu, dass IKE zwar hochkommt, aber keine passende CHILD-SA entsteht.

Schritt 4: Konfiguration route-based (VTI) in der Praxis

Bei route-based IPsec nutzen Sie ein Tunnel-Interface (VTI) und vergeben meist Tunnel-IPs, z. B.:

• VTI HQ: 169.254.100.1/30
• VTI BR: 169.254.100.2/30

Danach setzen Sie Routing:

• HQ: Route zu 10.20.0.0/16 via VTI
• BR: Route zu 10.10.0.0/16 via VTI

Der Vorteil: Sie können später zusätzliche Netze einfach als Routen ergänzen (oder via dynamischem Routing verteilen), ohne neue Selektoren in Phase 2 pflegen zu müssen.

Schritt 5: Beispielkonfiguration mit strongSwan (Linux) als Referenz

Auch wenn Sie keine Linux-Gateways betreiben, ist strongSwan als „lesbare Referenz“ hilfreich, weil es die Parameter klar benennt. Offizielle Doku: strongSwan Documentation.

Beispiel: /etc/ipsec.conf (policy-based, IKEv2, PSK)

config setup
charondebug="ike 1, knl 1, cfg 0"
conn hq-to-branch

keyexchange=ikev2

type=tunnel

auto=start
Code
left=203.0.113.10
leftid=203.0.113.10
leftsubnet=10.10.0.0/16

right=198.51.100.20
rightid=198.51.100.20
rightsubnet=10.20.0.0/16

ike=aes256gcm16-prfsha256-ecp256!
esp=aes256gcm16-ecp256!

dpdaction=restart
dpddelay=30s
dpdtimeout=120s

rekey=yes
ikelifetime=8h
lifetime=1h


Beispiel: /etc/ipsec.secrets
203.0.113.10 198.51.100.20 : PSK "HIER_EIN_SEHR_STARKES_PSK_EINTRAGEN"

Hinweise:

Das „!“ am Ende von ike/esp erzwingt das Proposal (keine Fallbacks). In gemischten Umgebungen kann das für Interop zu strikt sein – dann gezielt mehrere Proposals definieren, aber Legacy vermeiden.
PFS ist hier über die ECDH-Gruppe (ecp256) aktiv.
Die Lifetimes sind Beispielwerte; in produktiven Umgebungen sollten Sie sie konsistent mit Ihren Gateways und der Lastplanung setzen.

Schritt 6: Routing und Rückwege prüfen (der häufigste Praxisfehler)
Viele Tunnel sind „up“, aber Traffic fließt nicht. Ursache Nummer 1: Rückwege fehlen. Prüfen Sie:

Hat die Zentrale eine Route zum Filialnetz über das VPN-Gateway/VTI?
Hat die Filiale eine Route zum Zentralnetz über das VPN-Gateway/VTI?
Blockiert eine interne Firewall den Verkehr zwischen den Netzen?
Gibt es NAT-Regeln, die den Traffic verändern (und damit Selektoren brechen)?

Bei policy-based Tunneln ist es besonders wichtig, dass keine „versehentliche“ NAT-Regel den Quellbereich verändert. Sobald die Source-IP nicht mehr zum Selector passt, greift die CHILD-SA nicht.
Schritt 7: NAT-T, Keepalives und „VPN geht nur manchmal“
Wenn eine Seite hinter NAT sitzt (z. B. Filiale hinter Providerrouter oder CGNAT), nutzen IPsec-Setups NAT-Traversal. Dann läuft ESP in UDP/4500. Typische Probleme in der Praxis:

UDP-Timeouts im NAT: Idle-Verbindungen sterben, Tunnel muss neu aufgebaut werden.
Provider blockt UDP/4500: selten, aber in restriktiven Netzen möglich.
IP-Wechsel: bei Mobilfunk-Backups oder Dual-WAN kann Endpoint-IP wechseln (Failover-Fälle).

DPD (Dead Peer Detection) und regelmäßige Keepalives sind essenziell, damit Gateways schnell erkennen, dass der Peer „weg“ ist, und sauber reconnecten. MOBIKE ist für IKEv2 eine zusätzliche Option für Mobilität (RFC 4555), wird aber in klassischen Site-to-Site-Szenarien nicht immer genutzt.
Schritt 8: MTU/MSS und Fragmentierung berücksichtigen
IPsec erzeugt Overhead. Wenn die Pfad-MTU klein ist (PPPoE, LTE/5G, zusätzliche Encapsulation), können große Pakete fragmentieren und verloren gehen. Symptome:

kleine pings funktionieren, große Transfers hängen
bestimmte Anwendungen (z. B. SMB/HTTPS) sind instabil
„Tunnel up, aber einzelne Dienste gehen nicht“

Maßnahmen:

MSS-Clamping für TCP an der Firewall aktivieren
PMTUD ermöglichen (ICMP-„Fragmentation Needed“ darf nicht pauschal geblockt werden)
MTU-Tuning am Tunnel-Interface (bei VTI/route-based) konservativ setzen

PMTUD ist in RFC 1191 (IPv4) und RFC 8201 (IPv6) beschrieben.
Schritt 9: Security-Best-Practices für Site-to-Site IPsec
Ein IPsec-Tunnel ist nur so gut wie seine Kryptopolicy und der Betrieb. Prüfen Sie diese Punkte konsequent:

IKEv2 bevorzugen: weniger Legacy-Risiken und meist stabiler als IKEv1.
AEAD nutzen: z. B. AES-GCM statt „AES-CBC + HMAC“, wo möglich.
PFS aktiv: moderne (EC)DH-Gruppen, keine schwachen Legacy-Gruppen.
Starke Auth: Zertifikate sind oft besser als PSK; wenn PSK, dann lang, zufällig und einzigartig je Tunnel.
Restriktive Policies: nur benötigte Netze/Ports zwischen Standorten freigeben.
Logging & Monitoring: Rekey-Events, DPD-Timeouts, Drops, Fehlversuche sichtbar machen.
Patch-Disziplin: Gateways sind kritisch, Updates müssen planbar und regelmäßig erfolgen.

Für praxisnahe Sicherheitsorientierung ist NIST SP 800-77 Rev. 1 (Guide to IPsec VPNs) hilfreich. Im deutschen Kontext ist der BSI IT-Grundschutz-Baustein NET.3.3 eine gute Referenz für organisatorische und technische Anforderungen (BSI IT-Grundschutz: NET.3.3 VPN).
Troubleshooting in der Praxis: Die häufigsten Fehlerbilder
Wenn ein Tunnel nicht funktioniert, hilft ein strukturiertes Vorgehen. Diese Muster sehen Sie in fast jedem Projekt:

IKE kommt nicht hoch: UDP/500/4500 blockiert, PSK falsch, Proposal mismatch, falsche IDs.
IKE ist up, aber keine Phase 2/CHILD-SA: Selektoren stimmen nicht, PFS/ESP-Proposal mismatch.
Phase 2 ist up, aber kein Traffic: Routing/Rückroute fehlt, Firewall blockt, NAT verändert Quell-IP.
Geht nur sporadisch: NAT-Timeouts, DPD/Keepalive falsch, Dual-WAN-Failover ohne saubere Symmetrie.
Nur große Pakete scheitern: MTU/MSS/Fragmentierung, PMTUD blockiert.
Nach Failover bricht alles: asymmetrisches Routing oder fehlende State-Sync in Active/Active.

Praktische Checks:

Auf beiden Gateways: IKE/SA-Status, Rekey-Logs, DPD-Events.
Testen mit Ping + TCP (z. B. HTTPS) zwischen Hosts in den Netzen.
Traceroute in beide Richtungen (wenn möglich) – Asymmetrie erkennen.
Packet Capture am Gateway: sehen Sie ESP/UDP4500 rein/raus? Kommen Antworten zurück?

Checkliste: IPSec Site-to-Site Konfiguration vor Go-live

Adressplanung: lokale/remote Subnetze kollidieren nicht, VPN-/VTI-IPs dokumentiert.
Erreichbarkeit: UDP/500 und UDP/4500 (und ggf. ESP) sind end-to-end erlaubt.
IKEv2 aktiv: keine unnötigen IKEv1- oder Aggressive-Mode-Fallbacks.
Auth sauber: PSK lang & einzigartig oder Zertifikate mit gültiger Chain; Ablaufdaten/Rotation geplant.
Proposals matchen: IKE- und ESP-Proposals inkl. DH/ECDH-Gruppe stimmen auf beiden Seiten.
PFS aktiv: Gruppe festgelegt und kompatibel.
Lifetimes konsistent: IKE-SA und CHILD-SA Laufzeiten/Rekey nicht widersprüchlich.
DPD/Keepalive: sinnvolle Werte, damit „tote“ Peers erkannt werden.
Selektoren korrekt (policy-based): local/remote exakt gespiegelt; keine NAT-Regeln, die Selektoren brechen.
Routing vollständig (route-based): Routen zu allen Netzen gesetzt; Rückwege geprüft.
Firewall-Regeln: zwischen den Netzen nur benötigte Ports/Services freigeben (Least Privilege).
MTU/MSS: MSS-Clamping/MTU-Tuning geplant, PMTUD nicht blockiert.
Monitoring: Logs für IKE/ESP, Rekey, DPD, Drops, HA-Failover; Alerting definiert.
Failover-Test: wenn Dual-WAN/HA: Umschaltung getestet, kein asymmetrisches Routing.
Dokumentation: Parameterblatt, Change-/Rollback-Plan, Ansprechpartner, Wartungsfenster.

Weiterführende Quellen (Outbound-Links)

RFC 4301: Security Architecture for the Internet Protocol (IPsec)
RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 3947: Negotiation of NAT-Traversal in the IKE
RFC 3948: UDP Encapsulation of IPsec ESP Packets (NAT-T)
RFC 4555: MOBIKE (Mobility and Multihoming Protocol)
NIST SP 800-77 Rev. 1: Guide to IPsec VPNs
BSI IT-Grundschutz: NET.3.3 VPN
strongSwan Dokumentation (Praxisreferenz)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:


Netzwerkdesign & Topologie-Planung


Router- & Switch-Konfiguration (Cisco IOS)


VLAN, Inter-VLAN Routing


OSPF, RIP, EIGRP (Grundlagen & Implementierung)


NAT, ACL, DHCP, DNS-Konfiguration


Troubleshooting & Netzwerkoptimierung


Packet Tracer Projektentwicklung & Dokumentation


CCNA Lern- & Praxisunterstützung


Lieferumfang:


Konfigurationsdateien


Packet-Tracer-Dateien (.pkt)


Netzwerkdokumentation


Schritt-für-Schritt-Erklärungen (auf Wunsch)


Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
  Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.