Site icon BintoroSoft PDF Tools

IPSec Site-to-Site konfigurieren: Praxisbeispiel mit Checkliste

Red Snapper

Computer Network concept . 3d rendered illustration

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:

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)

Route-based (VTI / Tunnel-Interface)

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

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:

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.

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:

Typische GUI-Felder (sinngemäß):

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

Danach setzen Sie Routing:

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:

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:

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:

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:

Maßnahmen:

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:

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:

Praktische Checks:

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

Weiterführende Quellen (Outbound-Links)

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:

Lieferumfang:

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.

 

Exit mobile version