Cisco-Router-VPN-Architektur: Site-to-Site, Remote Access und Segmentierung

Eine professionelle Cisco-Router-VPN-Architektur kombiniert drei Ziele: sichere Standortvernetzung (Site-to-Site), kontrollierten Remote-Zugriff für Benutzer (Remote Access) und klare Segmentierung, damit VPN nicht zum „Seiteneingang“ in alle Netze wird. In der Praxis scheitern VPN-Projekte selten am „Tunnel aufbauen“, sondern an Governance und Operability: No-NAT fehlt, Policies sind unklar, MTU/MSS ist nicht bedacht, oder „Tunnel up“ wird als Erfolg gewertet, obwohl kein Traffic fließt. Dieser Leitfaden zeigt eine praxistaugliche Architektur, typische Topologien und die wichtigsten Verifikations- und Segmentierungsregeln.

Architektur-Grundlagen: Was ein VPN-Service im Enterprise bedeutet

VPN ist ein Service, kein Feature. Definieren Sie deshalb Serviceobjekte und Nachweise: „SA up“ reicht nicht, erforderlich ist „traffic-fähig“ mit Mess- und Testkriterien.

• Site-to-Site Service: Tunnel stabil + definierte Netze erreichbar
• Remote Access Service: Benutzer authentifiziert + nur erlaubte Segmente erreichbar
• Security Service: Segmentierung durch Policies/ACLs, Audit durch Logs/AAA
• Operability: Monitoring (SA/Flaps), Runbooks, Eskalationspfade

Topologie-Entscheidung: Hub-and-Spoke, Dual-Hub und (Partial) Mesh

Für viele Standorte ist Hub-and-Spoke der Standard, weil Governance und Skalierung einfacher sind. Dual-Hub ist der Enterprise-Mindeststandard für kritische Umgebungen. Mesh ist nur sinnvoll, wenn viel East-West Traffic zwischen Branches nötig ist.

• Hub-and-Spoke: Standard für 5–200+ Standorte, zentral steuerbar
• Dual-Hub: Redundanz und Wartungsfenster, weniger Single-Point-Risiko
• Partial Mesh: selektiv für Standorte mit direktem Verkehr
• Full Mesh: höchste Komplexität, meist nur bei klarer Notwendigkeit

Site-to-Site (S2S): Standardbausteine für stabile Tunnel

Der S2S-Standard besteht aus Krypto-Profilen (IKEv2/IPsec), klaren „interesting networks“, No-NAT und einer MTU/MSS-Strategie. Für den Betrieb ist die SA- und Traffic-Verifikation Pflicht.

• IKEv2/IPsec als Standard (konsistente Cipher/Hash/DH/PFS)
• VPN-Matrix: Peers, lokale Netze, Remote Netze, Primary/Backup
• No-NAT für VPN-Netze (Pflicht, wenn NAT am Router aktiv ist)
• DPD/Rekey stabil und standardisiert
• Traffic-Nachweis: Paketzähler müssen bei Testtraffic steigen

CLI: S2S-Verifikation (Pflicht)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

Remote Access: Prinzip und Architekturrollen

Remote Access bedeutet: Benutzer verbinden sich aus dem Internet ins Unternehmensnetz. Der Router kann als Remote-Access-Gateway fungieren, häufig ergänzt durch zentrale Authentifizierung (AAA) und klare Zugriffspolicies.

• Authentifizierung: zentral (AAA/RADIUS/TACACS) bevorzugt
• Zuweisung: definierter Adresspool oder virtuelle Interface-Profile
• Segmentierung: Remote-User sind ein eigenes Segment (nicht „Users-LAN“)
• Policy: Least Privilege, Applikationszugriff statt „Netz frei“

Segmentierung: VPN als eigenes Vertrauensniveau

VPN darf nicht automatisch Zugriff auf „alles intern“ bedeuten. Trennen Sie Remote Access und Site-to-Site logisch und setzen Sie Policies segmentbasiert durch. Das reduziert das Risiko lateral movement.

• Remote Access Segment: nur definierte Ziele/Ports, Logging aktiv
• Site-to-Site Segment: Zugriff nach Standortrolle (Branch vs. HQ)
• MGMT Segment: nur Adminzugriff, nie über Remote User
• Guest/IoT: grundsätzlich nicht über Remote Access erreichbar

Policy-Matrix Kurzformat (für VPN-Segmentierung)

• Quelle (Segment/VPN):
• Ziel (Netz/Service):
• Port/Protokoll:
• Zweck/Owner:
• Logging (ja/nein):

No-NAT und Selektoren: Häufigste Ursache für „Tunnel up, kein Traffic“

Wenn NAT aktiv ist, muss für VPN-Traffic explizit No-NAT greifen. Zusätzlich müssen lokale und entfernte Netze (Selektoren) vollständig und konsistent sein. Fehlt eines davon, sind SAs oft „up“, aber Daten laufen nicht.

• No-NAT: VPN-Netze von NAT ausnehmen
• Selektoren: lokale/remote Netze vollständig (keine Overlaps)
• Routing: Routen zu VPN-Netzen vorhanden (Static oder dynamisch)
• MTU/MSS: VPN-Overhead berücksichtigen (Fragmentierung vermeiden)

CLI: NAT/VPN-Indikatoren

show ip nat statistics
show ip nat translations
show crypto ipsec sa

Dual-ISP und VPN: Redundanz ohne Überraschungen

Wenn ein Standort Dual-ISP nutzt, muss die VPN-Architektur das berücksichtigen. Sonst führt Failover zu VPN-Ausfall. Im Enterprise ist Dual-Hub oder Dual-Peer ein häufiges Muster.

• Dual-Hub: Branch baut Tunnel zu zwei Hubs (Primary/Backup)
• Failover-Kriterium: Path-Down (IP SLA) statt nur Link-Down
• Failback: kontrolliert, um Flapping und Rekey-Stürme zu vermeiden

CLI: Path-Down Checks (wenn Tracking genutzt wird)

show ip sla statistics
show track
show ip route 0.0.0.0

Routing über VPN: Static, OSPF oder BGP über Tunnel?

Die Wahl des Routings beeinflusst Stabilität und Betrieb. Static ist einfach, dynamisches Routing über Tunnel ist bei vielen Netzen komfortabler, erfordert aber Stabilitätsregeln (passive-interface, Timer, Summaries).

• Static: kleiner Scope, wenige Netze, klarer Betrieb
• OSPF über Tunnel: skalierbar, aber Area-Design und Flap-Schutz nötig
• BGP über Tunnel: Policies und Skalierung, höherer Designaufwand

CLI: Routing-Verifikation

show ip route summary
show ip ospf neighbor
show bgp summary

Monitoring und Logging: VPN operativ beherrschbar machen

VPN-Probleme sind ohne Logs und KPIs schwer zu greifen. Mindeststandard sind NTP, Syslog und SA-Überwachung. Für Enterprise kommen Alarmkatalog und Retention hinzu.

• Monitoring: SA up/down, SA-Flaps, DPD/Rekey Errors
• KPIs: VPN-Uptime (traffic-fähig), Rekey-Fehler, MTTR
• Logging: IKE/IPsec Ereignisse zentral (Syslog), Zeit korrekt (NTP)

CLI: VPN-Log-Fokus

show ntp status
show logging | include IKEV2|IPSEC|CRYPTO

UAT/Acceptance: End-to-End Tests für VPN-Architektur

Abnahme muss Business-Use-Cases testen: Zugriff auf zentrale Ressourcen, Segmentierung, Failover. Dokumentieren Sie Pass/Fail und Evidence. Besonders wichtig: Traffic-Nachweis statt reiner SA-Status.

• S2S: Zugriff Branch → HQ Services (nach Policy), Paketzähler steigen
• Remote Access: Zugriff nur auf erlaubte Ziele/Ports, Logging aktiv
• Segmentierung: Remote User erreicht kein MGMT/Guest/IoT
• Failover (wenn Dual-ISP): Umschaltung ohne VPN-Ausfall oder mit definierter Recovery

Evidence-Set (Copy/Paste)

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show ip route summary
show ip nat translations
show ntp status
show logging | last 100

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.