Cisco-Router-Konfiguration für sicheren Remote-Zugriff: VPN + Policies

Sicherer Remote-Zugriff auf Unternehmensnetze ist mehr als „VPN einschalten“: Ohne saubere Policies, Segmentierung und Logging wird Remote Access schnell zum Risiko. Eine robuste Cisco-Router-Konfiguration kombiniert daher verschlüsselte VPN-Tunnel (typisch IKEv2/IPsec), klare Zugriffsregeln (Least Privilege), sichere Administration (SSH/AAA) und betriebsfähiges Monitoring. Dieser Leitfaden zeigt praxisnah, wie Sie Remote-Zugriff sicher planen, konfigurieren und verifizieren – inklusive typischer CLI-Bausteine und erwarteter Ergebnisse.

Zielbild: Was „sicherer Remote-Zugriff“ technisch bedeutet

Ein sicherer Remote-Zugriff stellt sicher, dass nur autorisierte Benutzer auf definierte Ressourcen zugreifen können, dass Verbindungen nachvollziehbar protokolliert werden und dass Remote-Clients nicht als „Bridge“ in interne Netze missbraucht werden.

• Starke Authentifizierung (AAA/MFA je nach Umgebung)
• Verschlüsselung und moderne Kryptoparameter (IKEv2 bevorzugt)
• Least Privilege: nur benötigte Netze/Ports, Rollenmodelle
• Split-Tunneling nach Policy (oder Full-Tunnel, wenn gefordert)
• Logging/Audit: Zeitstempel, zentrale Logs, nachvollziehbare Zugriffe

Remote-Zugriff-Modelle: Was passt zu Ihrem Szenario?

Es gibt zwei typische Wege: Site-to-Site (Standort/Partner) und Remote Access (Einzelbenutzer). Für „Homeoffice“ ist Remote Access die übliche Wahl, für Filialen/Partner eher Site-to-Site. In der Praxis werden beide kombiniert.

• Remote Access: Benutzer verbinden sich individuell (Admin, Homeoffice, Dienstleister)
• Site-to-Site als „Remote“: externer Standort wird per IPsec gekoppelt
• Hybrid: Remote Access für Admins, Site-to-Site für Außenstandorte

Planung: Inputs, die vor der Konfiguration feststehen müssen

Remote-Zugriff scheitert selten an der Syntax, sondern an unklaren Policies. Klären Sie daher: wer darf wohin, mit welchen Clients und mit welchen Sicherheitsauflagen.

• Zielnetze: welche Subnetze/Services dürfen remote erreichbar sein?
• Rollen: Admin, Support, Standard-User, Dienstleister (jeweils eigene Policies)
• Adresspool für VPN-Clients (virtuelles Netz)
• Split-Tunnel-Definition (nur Unternehmensnetze) oder Full-Tunnel
• Logging/Compliance: Syslog, NTP, Audit-Anforderungen
• Starke Authentifizierung: AAA/MFA (abhängig von Plattform/Setup)

Security-Baseline: Management absichern, bevor Remote Access live geht

Remote-Zugriff erhöht die Exposition. Daher müssen Management-Zugriffe strikt abgesichert sein: SSH-only, Zugriff nur aus Management-Netzen, saubere Zeitstempel und zentrale Logs.

Beispiel: NTP und Syslog für Audit

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging host 192.0.2.20
logging trap informational

Beispiel: SSH-only und Management-Restriktion

no ip http server
no ip http secure-server
ip ssh version 2
ip access-list standard MGMT_ONLY

permit 10.10.99.0 0.0.0.255

deny   any
line vty 0 4

transport input ssh

access-class MGMT_ONLY in

login local

exec-timeout 10 0

VPN-Baustein: IKEv2/IPsec als Standard für sicheren Remote-Zugriff

Für moderne Umgebungen ist IKEv2 der bevorzugte Standard. Der VPN-Teil umfasst Kryptoprofile, Authentifizierung, Adresspool und Policy-Steuerung. Die konkrete Remote-Access-Implementierung hängt stark von Plattform und Lizenzierung ab, daher sollten Sie das Design prinzipiell und policy-getrieben aufbauen.

Krypto-Standards (praxisnah)

• Starke Verschlüsselung (z. B. AES-256) und Integrität (z. B. SHA-256)
• DH-Gruppe passend zur Policy (z. B. 14 als verbreiteter Standard)
• Klare Rekey- und DPD-Strategie (Stabilität)

Beispiel: IKEv2 Proposal/Policy (Baustein)

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

proposal IKEV2-PROP

Policies für Remote-Zugriff: Split-Tunnel und Least Privilege

Der entscheidende Sicherheitshebel ist die Policy: Remote-Clients sollen nur die Netze sehen, die sie brauchen. Split-Tunnel reduziert zusätzlich unnötigen Verkehr durch das Unternehmensnetz und begrenzt Risiko.

Split-Tunnel-Liste definieren (Netze, die durch den Tunnel dürfen)

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

Rollenbasierte Zugriffe (Konzept)

• Role Admin: Zugriff auf Management-Netze und definierte Server
• Role Support: Zugriff nur auf Jump Host/Remote-Tools
• Role User: Zugriff auf definierte Business-Apps, kein Zugriff auf MGMT

Segmentierung: Remote Access in ein eigenes Segment führen

Ein bewährtes Muster ist, Remote-Clients logisch wie ein eigenes Segment zu behandeln. Damit können Sie Policies genauso anwenden wie bei Guest/IoT: klare Grenzen, klare erlaubte Flows.

• VPN-Client-Pool als eigenes Netz (z. B. 10.99.0.0/24)
• Policies: VPN-Clients dürfen nur zu definierten Zielnetzen/Ports
• Kein „Any-Any“ zwischen VPN-Pool und internen Netzen

Beispiel: VPN-Client-Pool (Planung)

Ein /24 bietet 256 Adressen (254 nutzbar) und ist für viele Remote-Access-Szenarien ausreichend.

28 = 256

DNS und Namensauflösung: Damit Remote Access „benutzbar“ ist

Remote Access scheitert im Alltag häufig nicht am Tunnel, sondern an DNS: Nutzer erreichen zwar IPs, aber keine Namen. Planen Sie daher DNS-Server, Suchdomänen und Split-DNS sauber.

• Interne DNS-Server für interne Namen
• Suchdomänen (z. B. example.local) definieren
• Split-DNS falls nötig: interne Namen intern, externe Namen extern

Verifikation: Was Sie nach der Umsetzung sehen müssen

Die Abnahme muss nicht „gefühlt“, sondern messbar sein: VPN-Status, Paketzähler, Erreichbarkeit definierter Ressourcen und Logeinträge für Sessions. So erhalten Sie einen auditierbaren Nachweis.

VPN-Status-Checks (Runbook)

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

Pfad- und Policy-Checks

show ip route
show access-lists
show logging | last 50

Erwartete Ergebnisse

• IKEv2 SA steht stabil, IPsec SA zählt Pakete bei aktivem Traffic
• Remote-Client erreicht nur definierte Netze (Split-Tunnel/Policies)
• Management-Netze sind nur für Admin-Rollen erreichbar
• Syslog enthält nachvollziehbare Events (Login/Session/Errors)

Typische Fehlerbilder und schnelle Ursachen

Remote-Access-Probleme sind meist Policy-, NAT- oder DNS-bedingt. Mit klaren Checks lässt sich die Ursache schnell eingrenzen.

• VPN „up“, aber kein Zugriff: Routing/Policies, Split-Tunnel-Liste falsch
• Nur IPs gehen, keine Namen: DNS/Suchdomäne fehlt
• VPN bricht ab: WAN-Loss, DPD/Rekey, MTU/MSS, UDP 500/4500 blockiert
• Zu breite Rechte: kein RBAC, keine Segmentgrenzen, „Any-Any“-Regeln

Minimal-Runbook: Standard-Checks bei Störungen

Ein kurzer SOP-Block reduziert Reaktionszeit bei Incidents. Diese Kommandos sind die Basis für die meisten Remote-Access-Troubleshooting-Fälle.

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show ip route
show logging | last 50
show processes cpu sorted

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.