Site icon bintorosoft.com

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

Red Snapper

Create a visual aid showing the process of data integration from multiple sources. Include steps like data extraction, transformation, and loading (ETL).

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.

Merker

IKEv2 Profile = Wer ist der Peer? + Wie authentifizieren wir? + 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.

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.

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

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.

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version