Cisco-Router-VPN-Konfiguration: Site-to-Site & Remote Access (Leitfaden)

Eine Cisco-Router-VPN-Konfiguration verbindet Standorte sicher über das Internet (Site-to-Site) und ermöglicht autorisierten Benutzern den geschützten Zugriff aus der Ferne (Remote Access). Damit VPNs stabil laufen, müssen Kryptoparameter, Routing, NAT-Ausnahmen, MTU/MSS und Betriebschecks sauber zusammenspielen. Dieser Leitfaden erklärt praxisnah die typischen Bausteine für IKEv2/IPsec, zeigt bewährte SOPs und liefert CLI-Beispiele für eine robuste Umsetzung.

VPN-Grundlagen: Was passiert technisch?

In Cisco-Umgebungen basiert VPN häufig auf IPsec. IKEv2 baut dabei die Security Associations (SAs) auf, verhandelt Schlüsselmaterial und steuert Rekeying. IPsec schützt anschließend die Nutzdaten (ESP) und kapselt den „interessanten“ Traffic, der über Selektoren/ACLs definiert wird.

• IKEv2: Aufbau, Authentifizierung, Schlüssel, Rekey
• IPsec/ESP: Verschlüsselung/Integrität der Nutzdaten
• Selektoren: Welche Netze gehen durch den Tunnel?
• NAT-T: IPsec durch NAT-Umgebungen (UDP/4500)

Site-to-Site vs. Remote Access: Wann welches VPN?

Site-to-Site ist für dauerhafte Standortkopplung gedacht (Filiale–Zentrale, Partnernetze). Remote Access richtet sich an einzelne Clients (Admin, Homeoffice, Dienstleister), meist mit Benutzer-Authentifizierung und dynamischen Policies.

• Site-to-Site: feste Peers, feste Netze, häufig Always-on
• Remote Access: Benutzer-/Gruppen-Policies, Adresspool, Split-Tunnel möglich
• Skalierung: viele Clients eher Remote-Access-Architektur, viele Standorte eher Site-to-Site/DMVPN

Voraussetzungen und Planungsdaten: Ohne diese wird VPN teuer

Vor der Konfiguration müssen Netze, Peers und Policies eindeutig sein. Unklare Selektoren oder fehlende NAT-Ausnahmen sind die häufigsten Ursachen für „Tunnel up, aber kein Traffic“.

• Peer-IPs/FQDNs (ggf. dynamisch) und öffentliche Erreichbarkeit
• Lokale/Remote Subnetze (Interessent Traffic) und Routing-Design
• Authentifizierung: PSK oder Zertifikate (PKI)
• Kryptoprofile: Cipher/Hash, DH-Gruppe, PFS, Rekey-Intervalle
• NAT-Design: No-NAT für VPN-Traffic, NAT-T Anforderungen
• Firewall/Provider: UDP 500/4500, ESP (IP Proto 50) bzw. NAT-T

Best Practices: Stabilität, Sicherheit und Kompatibilität

Ein guter VPN-Standard ist konsistent über Standorte und vermeidet unnötige Komplexität. Besonders wichtig sind starke Kryptoparameter, saubere Selektoren, deterministisches Routing und saubere Betriebschecks.

• IKEv2 bevorzugen (statt IKEv1), konsistente Crypto-Standards
• Selektoren minimal halten (nur benötigte Netze)
• No-NAT konsequent umsetzen, sonst entstehen asymmetrische Pfade
• MTU/MSS beachten (VPN-Overhead), sonst Performance-Probleme
• Monitoring: klare Checks für IKEv2 SA, IPsec SA und Crypto Sessions

MTU/MSS: Warum VPNs ohne Anpassung oft „komisch“ wirken

IPsec fügt Overhead hinzu. Wenn Pfade PMTUD blockieren, kommt es zu Fragmentierung oder Drops. Eine gängige Maßnahme ist MSS-Clamping auf dem LAN-Interface, um TCP-Segmente zu verkleinern.

interface GigabitEthernet0/1
 ip tcp adjust-mss 1360

Site-to-Site VPN (IKEv2/IPsec): Referenz-Bausteine

Die folgenden Beispiele zeigen typische Konfigurationsbausteine. In der Praxis müssen Namen, Interfaces, Peers und Netze angepasst werden. Das Muster zielt auf klaren Aufbau und gute Troubleshooting-Fähigkeit.

Interessent Traffic: ACL für Site-to-Site

ip access-list extended ACL-VPN-S2S
 permit ip 10.10.10.0 0.0.0.255 10.20.10.0 0.0.0.255
 permit ip 10.10.20.0 0.0.0.255 10.20.20.0 0.0.0.255

No-NAT für VPN-Traffic (typischer Baustein)

Wenn NAT genutzt wird, muss VPN-Traffic davon ausgenommen werden. Je nach Design erfolgt das via Route-Map oder ACL-Logik. Das folgende Muster ist bewusst vereinfacht und dient als Orientierung.

ip access-list extended ACL-NONAT-VPN
 permit ip 10.10.0.0 0.0.255.255 10.20.0.0 0.0.255.255
route-map RM-NAT permit 10

match ip address ACL-NONAT-VPN

set interface Null0
route-map RM-NAT permit 20
ip access-list standard ACL-NAT-INSIDE

permit 10.10.0.0 0.0.255.255
interface GigabitEthernet0/0

ip nat outside

interface GigabitEthernet0/1

ip nat inside
ip nat inside source route-map RM-NAT interface GigabitEthernet0/0 overload

IKEv2-Proposal, Policy und Keyring

crypto ikev2 proposal IKEV2-PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
crypto ikev2 policy IKEV2-POL

proposal IKEV2-PROP
crypto ikev2 keyring KR-S2S

peer PEER-HQ

address 203.0.113.10

pre-shared-key local 

pre-shared-key remote 

IPsec-Transformset und Profile

crypto ipsec transform-set TS-ESP-AES256-SHA esp-aes 256 esp-sha256-hmac
 mode tunnel
crypto ipsec profile IPSEC-PROF-S2S

set transform-set TS-ESP-AES256-SHA

set ikev2-profile IKEV2-PROF-S2S

IKEv2-Profile und Tunnel-Interface (VTI-Muster)

Viele Designs nutzen Virtual Tunnel Interfaces (VTI), weil Routing darüber sauber und skalierbar ist. Das reduziert „Policy-Gewusel“ und erleichtert dynamisches Routing über VPN.

crypto ikev2 profile IKEV2-PROF-S2S
 match identity remote address 203.0.113.10 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR-S2S
interface Tunnel10

description S2S-to-HQ

ip address 172.16.10.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-S2S

Routing über Site-to-Site: Static, OSPF oder BGP?

Für wenige Netze reicht oft statisches Routing. Bei vielen Standorten ist dynamisches Routing über Tunnel (z. B. OSPF) häufig stabiler, weil Netze zentral gepflegt werden und Failover schneller erfolgt.

• Static: einfach, aber manueller Pflegeaufwand
• OSPF über Tunnel: gut für Hub-and-Spoke und mehrere Netze
• BGP über Tunnel: sinnvoll bei Policies, mehreren Hubs oder komplexen Anforderungen

Beispiel: Statische Route über Tunnel

ip route 10.20.0.0 255.255.0.0 172.16.10.2

Beispiel: OSPF über Tunnel (kompakt)

router ospf 10
 passive-interface default
 no passive-interface Tunnel10
 network 172.16.10.0 0.0.0.3 area 0

Remote Access VPN: Konzeptionelle Bausteine

Remote Access ist stärker policy-getrieben: Benutzeridentität, Adresspool, Split-Tunnel, DNS und Zugriffsrechte stehen im Vordergrund. Die konkrete CLI-Umsetzung hängt stark von Plattform, Feature-Set und Lizenzierung ab.

• Authentifizierung: lokal/AAA, MFA je nach Unternehmensstandard
• Adresspool für Clients (virtuelles Netz)
• Split-Tunneling: nur Unternehmensnetze durch den Tunnel
• Group-Policies: Rollenbasierte Berechtigungen (Admin, Dienstleister, User)

Split-Tunnel-Netze definieren (Konzept-Beispiel)

ip access-list standard ACL-SPLIT
 permit 10.10.0.0 0.0.255.255
 permit 10.20.0.0 0.0.255.255

Security-Checkliste für VPN: Häufige Schwachstellen vermeiden

VPN schützt Daten, ersetzt aber kein Security-Design. Besonders wichtig sind starke Authentifizierung, minimale Berechtigungen und saubere Trennung zwischen Benutzergruppen und Netzsegmenten.

• Keine „Any-Any“-Selektoren ohne Notwendigkeit
• PSKs regelmäßig rotieren oder besser Zertifikate/PKI nutzen
• Benutzergruppen strikt trennen (Remote Access: Admin vs. Standard-User)
• Management-Zugriffe nicht über VPN „versehentlich“ öffnen
• Logging aktivieren und Zeit synchronisieren (NTP)

Troubleshooting: Wenn der Tunnel „up“ ist, aber Traffic nicht läuft

Das häufigste Fehlerbild ist „IKEv2 SA steht, aber keine IPsec SA“ oder „IPsec SA zählt keine Pakete“. Ursachen sind meist falsche Selektoren, NAT, Routing oder MTU/MSS.

Standard-Checks für IKEv2 und IPsec

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show ip route
show ip arp summary

Typische Ursachen im Schnellcheck

• Selektoren stimmen nicht: lokale/remote Netze falsch oder vertauscht
• NAT greift: No-NAT fehlt oder Reihenfolge ist falsch
• Routing fehlt: Rückweg über Tunnel nicht vorhanden
• MTU/MSS: Fragmentierung, PMTUD blockiert, sporadische Drops
• Firewall/Provider blockiert: UDP 500/4500 oder ESP

SOP: Abnahme und Betrieb von VPNs

VPNs sollten nicht nur „funktionieren“, sondern betrieblich überwachbar sein. Eine SOP definiert Pre-/Post-Checks, Abnahmekriterien, Rollback-Trigger und regelmäßige Kontrollen (Rekey, DPD, Paket-Zähler).

Abnahme-Checks (Site-to-Site)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
ping 10.20.10.10 source 10.10.10.1
traceroute 10.20.10.10 source 10.10.10.1

Betriebschecks (regelmäßig)

show crypto ikev2 sa
show crypto ipsec sa
show logging | include CRYPTO|IKEV2|IPSEC
show processes cpu sorted

Skalierung: Viele Standorte oder viele Benutzer

Wenn die Anzahl der Standorte steigt, werden Templates, VTI-Routing und standardisierte Kryptoprofile essenziell. Für viele Remote-Access-User sind zentrale AAA-Integrationen und klare Gruppen-Policies entscheidend, um Sicherheit und Betrieb stabil zu halten.

• Standorte: VTI + dynamisches Routing, standardisierte Profile, saubere Doku
• Benutzer: AAA/MFA, Rollenmodelle, Split-Tunnel-Design, Monitoring der Sessions
• Beide: klare Abnahmeprotokolle und wiederholbare SOPs

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.