IPsec IKEv2 auf Cisco: Profile-Design, Crypto Maps vs. VTIs (Pro/Contra)

IPsec mit IKEv2 ist auf Cisco Routern der moderne Standard für Site-to-Site VPNs: robustes Negotiation-Framework, bessere Security-Defaults und saubere Erweiterbarkeit (z. B. EAP/AAA, Mobility, Rekey). In der Praxis entscheidet jedoch weniger „IKEv2 ja/nein“, sondern das Design: Wie baust du Profile, Authentifizierung und Policy sauber, und welche Implementationsform nutzt du – klassische Crypto Maps oder Route-based VPNs über Virtual Tunnel Interfaces (VTIs)? Beide funktionieren, aber sie unterscheiden sich massiv in Betrieb, Skalierung und Troubleshooting. Dieser Artikel erklärt IKEv2 Profile-Design und zeigt Pro/Contra von Crypto Maps vs. VTIs mit praxisnahen Konfigurationsmustern.

IKEv2 Bausteine: Proposal, Policy, Keyring, Profile

IKEv2 trennt sauber zwischen Kryptoparametern (Proposal/Policy) und Peer-Identität/Authentifizierung (Keyring/Profile). Ein gutes Design vermeidet „global spaghetti“ und arbeitet mit klaren Profiles pro Peer-Typ.

• IKEv2 Proposal: Algorithmen (Encryption, Integrity, DH)
• IKEv2 Policy: Auswahl/Matching von Proposals
• Keyring: Pre-Shared Keys oder Referenzen
• IKEv2 Profile: Identity-Matching + Auth + Keyring + DPD

Merker

$\text{IKEv2 Profile}=\text{Wer ist der Peer?}+\text{Wie authentifizieren wir?}+\text{Welche Policy gilt?}$

IPsec Bausteine: Transform Set / Proposal, PFS, SA Lifetime

Nach IKE (Phase 1) kommt IPsec (Phase 2). Auch hier definierst du Algorithmen, optional PFS und Lifetimes. Moderne Empfehlungen bevorzugen starke AEAD-Suiten (z. B. AES-GCM) und klare Lifetime-Standards.

• IPsec Proposal/Transform: ESP Encryption/Integrity (oder AES-GCM)
• PFS: zusätzliche DH für Phase 2 (Sicherheitsplus, etwas CPU)
• Lifetime: konsistent, sonst häufige Rekeys oder Mismatches

Profile-Design in der Praxis: Skalierbar statt „Peer-zu-Peer Copy/Paste“

Ein skalierbares Design nutzt wenige standardisierte Proposals und Profiles, und unterscheidet Peers über Match-Regeln (Identity, FQDN, IP). Das reduziert Fehlkonfigurationen und macht Rollouts auditierbar.

• Standard-Policy: 1–2 IKEv2 Proposals, 1–2 IPsec Proposals
• Profile pro Peer-Klasse: Branch, DC, Partner
• Keyring mit Einträgen pro Peer oder pro Peer-Gruppe

IKEv2 Proposal/Policy (Pattern)

crypto ikev2 proposal IKEV2-PROP
 encryption aes-gcm-256
 prf sha256
 group 14
crypto ikev2 policy IKEV2-POLICY

proposal IKEV2-PROP

Keyring + Profile (Pattern)

crypto ikev2 keyring KR-BRANCH
 peer BRANCH1
  address 203.0.113.10
  pre-shared-key local 0 SuperSecretKey
  pre-shared-key remote 0 SuperSecretKey
crypto ikev2 profile IKEV2-PROF-BRANCH

match identity remote address 203.0.113.10 255.255.255.255

identity local address 198.51.100.2

authentication remote pre-share

authentication local pre-share

keyring local KR-BRANCH

dpd 10 3 on-demand

Crypto Maps vs. VTI: Der grundlegende Unterschied

Crypto Maps sind policy-based: „Traffic Selector“ (ACL) definiert, welcher Traffic in den Tunnel darf. VTIs sind route-based: Der Tunnel ist ein Interface, und Routing (static/IGP/BGP) entscheidet, welcher Traffic darüber läuft. Das wirkt sich direkt auf Betrieb, Skalierung und Failover aus.

• Crypto Map: selektiert Traffic per ACL (interessanter Traffic)
• VTI: routet Traffic über Tunnel-Interface (Routing entscheidet)
• IKEv2 Profile kann in beiden Modellen genutzt werden

Crypto Maps: Pro/Contra im Betrieb

Crypto Maps sind weit verbreitet und funktionieren zuverlässig, aber sie werden bei vielen Peers und dynamischen Routinganforderungen schnell unhandlich. Debugging ist oft „ACL-zentriert“ und Änderungen sind risikoreich, wenn viele Selectors existieren.

• Pro: einfach für wenige statische Netze und wenige Peers
• Pro: klare Traffic Selector pro Peer
• Contra: Skalierung schlecht (viele ACLs, viele Einträge)
• Contra: dynamisches Routing/Failover schwieriger
• Contra: Änderungen an ACL können Traffic unbeabsichtigt aus/in den Tunnel schieben

Crypto Map Pattern (IKEv2 + IPsec)

crypto ipsec transform-set TS-ESP-AESGCM esp-gcm 256
 mode tunnel
ip access-list extended ACL-VPN

permit ip 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255
crypto map CMAP 10 ipsec-isakmp

set peer 203.0.113.10

set transform-set TS-ESP-AESGCM

set ikev2-profile IKEV2-PROF-BRANCH

match address ACL-VPN
interface GigabitEthernet0/0

crypto map CMAP

VTI (Route-based VPN): Pro/Contra im Betrieb

VTIs sind im Enterprise-Betrieb oft die bessere Wahl: Routing entscheidet, Failover ist leichter, und du kannst IGP/BGP über den Tunnel fahren. Der Preis ist: du musst Routing sauber designen und Split-Horizon/Leaking bewusst steuern. Dafür bekommst du deutlich bessere Skalierbarkeit und oft besseres Troubleshooting.

• Pro: Routing-gesteuert (static/OSPF/BGP möglich)
• Pro: leichteres Failover (Floating Routes, Tracking, BFD)
• Pro: weniger ACL-Spaghetti, bessere Skalierung bei vielen Netzen
• Contra: falsches Routing kann Traffic in den Tunnel „ziehen“
• Contra: Policy-Granularität erfordert zusätzliche ACLs/Firewall-Zonen

VTI Pattern (IKEv2 + Tunnel Interface)

crypto ipsec transform-set TS-ESP-AESGCM esp-gcm 256
 mode tunnel
crypto ipsec profile IPSEC-PROF

set transform-set TS-ESP-AESGCM

set pfs group14
interface Tunnel100

description VTI to BRANCH1

ip address 169.254.100.1 255.255.255.252

tunnel source GigabitEthernet0/0

tunnel destination 203.0.113.10

tunnel mode ipsec ipv4

tunnel protection ipsec profile IPSEC-PROF

Routing über VTI (Pattern)

ip route 10.20.20.0 255.255.255.0 Tunnel100

Welche Variante ist „besser“? Entscheidungskriterien

Die richtige Wahl hängt vom Betriebsmodell ab. Für wenige statische Subnetze ist Crypto Map ok. Für wachsende Netze, mehrere VRFs, dynamische Pfade und sauberen Betrieb sind VTIs fast immer die stabilere Architektur.

• Wenige Peers, statische Netze → Crypto Map oft ausreichend
• Viele Peers, viele Netze, Routing/Fast Failover → VTI bevorzugen
• Multi-VRF, Overlays, SD-WAN-ähnliche Patterns → VTI klar im Vorteil

Edge-Cases: NAT, MTU/MSS und Fragmentierung

Viele IPsec-Probleme sind nicht Crypto-Suite-Probleme, sondern MTU/MSS/PMTUD. IPsec erhöht Overhead, und wenn ICMP blockiert ist, entstehen Blackholes. MSS Clamping an der richtigen Stelle ist oft der schnellste Fix.

• IPsec Overhead reduziert effektive MTU
• ICMP/PMTUD muss funktionieren (IPv6 besonders)
• MSS Clamping hilft bei TCP, nicht bei UDP

MSS Clamping (Pattern)

interface Tunnel100
 ip tcp adjust-mss 1360

Troubleshooting: IKEv2 und IPsec sauber prüfen

Im Betrieb prüfst du immer in Ebenen: IKEv2 SA (Phase 1), IPsec SA (Phase 2), Traffic Counters, Routing/Selectors. Crypto Maps: ACL/Selectors prüfen. VTI: Routing über Tunnel prüfen.

IKEv2/IPsec Status

show crypto ikev2 sa
show crypto ipsec sa

Crypto Map spezifisch

show crypto map
show access-lists ACL-VPN

VTI spezifisch

show interface Tunnel100
show ip route 10.20.20.0 255.255.255.0
show ip cef 10.20.20.10 detail

Best Practices: Betriebssicheres IKEv2/IPsec Design

Stabiler Betrieb entsteht durch Standardisierung und klare Guardrails: wenige starke Proposals, klare Profile, saubere Lifetimes, Monitoring und kontrollierte Changes. Das reduziert „Negotiation Mismatch“-Tickets massiv.

• Standard-Proposals (AES-GCM, SHA256, DH14/19 je Policy)
• Profile pro Peer-Klasse, kein Wildwuchs
• DPD aktiv und sinnvoll getuned
• MTU/MSS bewusst gesetzt, ICMP nicht blind blocken
• Runbooks: Pre/Post Checks (SAs, Counters, Routing)

Quick-Runbook: Incident Checkliste (IKEv2/VPN)

Diese Sequenz liefert in wenigen Minuten den Status von Phase 1/2 und zeigt, ob es ein Routing/Selector Problem ist.

show crypto ikev2 sa
show crypto ipsec sa
show interface Tunnel100
show ip route <remote-prefix>
show ip cef <remote-host> detail
show interfaces | include drops|error

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.