Filial-VPNs müssen vor allem eins sein: standardisiert. Wenn jede Niederlassung „ein bisschen anders“ konfiguriert ist, steigen Betriebskosten und Ausfallrisiken drastisch – insbesondere bei Rekey, Failover, NAT/No-NAT und MTU. Eine professionelle Cisco-Router-Konfiguration für Filial-VPN setzt daher auf Templates (Golden Config), ein Variablenmodell pro Standort und klare Standardparameter für IKEv2/IPsec, DPD, Rekey sowie Monitoring-Checks. Dieser Leitfaden zeigt bewährte Bausteine und ein Template-Muster, das für Hub-and-Spoke-Filialnetze praxistauglich ist.
Zielbild: Standardisiertes Hub-and-Spoke VPN für Filialen
Das häufigste Filialdesign ist Hub-and-Spoke: Jede Filiale baut einen Tunnel zur Zentrale (Hub) auf. Optional gibt es einen zweiten Hub (Backup) oder Dual-ISP. Ziel ist eine stabile, wartbare Verbindung mit klarer Verantwortung für Routing, NAT und Policies.
- Eine Filiale → ein Standardtunnel (Primary Hub), optional Backup Hub
- Klare Netze: Filial-VLANs (Users/Guest/IoT) vs. zentrale Servernetze
- No-NAT für VPN-Traffic verpflichtend
- Monitoring: SA-Status und Paketzähler als Mindeststandard
Template-Strategie: Golden Config + Standortvariablen
Ein Template reduziert Fehler und macht Rollouts skalierbar. Trennen Sie unveränderliche Baseline-Teile (Crypto-Standards, Logging, Checks) von Standortvariablen (WAN-IP, Filialnetze, Peer-IP/FQDN).
Golden Config (fix, überall gleich)
- IKEv2/IPsec Standardprofile (Cipher/Hash/DH/PFS)
- DPD und Rekey-Standardwerte
- Logging/NTP/Syslog-Baseline
- Standard-Checks (Pre-/Post-Checks, Runbook)
- Naming-Standards (Tunnel, ACLs, Route-Maps, Objects)
Standortvariablen (pro Filiale)
- Hostname/Store-ID
- WAN-Interface (ISP), öffentliche IP (oder NAT), Gateway
- Filialnetze (z. B. 10.<SiteID>.20.0/24)
- Hub-Peer (Primary/Backup), PSK oder Zertifikat
- Optional: Dual-ISP Parameter (Tracking, Prioritäten)
Standardparameter: IKEv2/IPsec stabil und interoperabel
Für Filial-VPNs ist Interoperabilität wichtiger als exotische Optionen. Nutzen Sie konsistente, moderne Parameter und dokumentieren Sie jede Abweichung. Dadurch werden Troubleshooting und Betrieb einfacher.
- IKEv2 statt IKEv1 (modern, stabil)
- Verschlüsselung: AES (z. B. 256), Integrität: SHA-256
- DH-Gruppe: z. B. 14 als verbreiteter Standard
- PFS (Phase 2) nach Policy (z. B. group14)
- DPD aktiv (Dead Peer Detection) für sauberes Recovery
Beispiel: IKEv2 Proposal/Policy (Template-Baustein)
crypto ikev2 proposal IKEV2-PROP
encryption aes-cbc-256
integrity sha256
group 14
crypto ikev2 policy IKEV2-POL
proposal IKEV2-PROP
Policy-Baustein: No-NAT für VPN (Pflicht)
Das häufigste Filial-VPN-Fehlerbild lautet: „Tunnel up, aber kein Traffic“. Ursache ist sehr oft fehlendes No-NAT. Standardisieren Sie daher eine klare No-NAT-Regel für Filialnetze ↔ Zentralnetze.
Beispiel: No-NAT mit Route-Map (konzeptionelles Muster)
ip access-list extended ACL-NONAT-VPN
permit ip 10.12.20.0 0.0.0.255 10.20.0.0 0.0.255.255
permit ip 10.12.30.0 0.0.0.63 10.20.0.0 0.0.255.255
route-map RM-NONAT permit 10
match ip address ACL-NONAT-VPN
Routing über den Tunnel: Standard entscheiden (Static vs. dynamisch)
Für wenige Netze kann Static Routing ausreichen. Ab mehreren VLANs und Standorten ist dynamisches Routing über Tunnel (z. B. OSPF) oft wartungsärmer. Wichtig ist: einheitlich bleiben.
- Static: wenige Netze, sehr klare Hub-and-Spoke-Struktur
- OSPF über Tunnel: skalierbar, automatische Verteilung der Filialpräfixe
- Standardisierung: gleiche Area/Process-ID, passive Interfaces, klare Router-IDs
Beispiel: OSPF über Tunnel (Standortbaustein)
router ospf 10
router-id 10.255.12.1
passive-interface default
no passive-interface Tunnel10
network 10.12.0.0 0.0.255.255 area 0MTU/MSS-Standard: Stabilität bei Filial-VPNs erhöhen
Filialanschlüsse nutzen oft PPPoE oder Providerpfade mit reduzierter MTU. In Kombination mit VPN-Overhead kann das zu sporadischen Timeouts führen. MSS-Clamping ist ein praxisnaher Standardbaustein.
Beispiel: MSS-Clamping (Template-Baustein)
interface GigabitEthernet0/1
ip tcp adjust-mss 1360Monitoring-Standard: Was jedes Filial-VPN liefern muss
Ein VPN ist nur betriebsfähig, wenn es überwacht wird. Mindeststandard sind SA-Status und Paketzähler, ergänzt um Syslog/NTP für korrelierbare Ereignisse.
- Syslog und Zeitstempel (NTP) aktiv
- VPN-Checks: IKEv2 SA, IPsec SA, Session-Details
- Alarme: Tunnel down, Rekey-Schleifen, keine Pakete trotz SA
Beispiel: NTP + Syslog Baseline
service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging host 192.0.2.20
logging trap informationalVPN-Runbook-Checks (Pflicht)
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show logging | include IKEV2|IPSEC|CRYPTOTemplate-Muster: Filial-VPN „Golden Config“ (Auszug)
Dieses Muster zeigt die Bausteine, die in vielen Filialprojekten stabil funktionieren. IPs/Netze und Keys sind Platzhalter und müssen pro Standort über Variablen gesetzt werden.
hostname R1-SITE-12
no ip domain-lookup
service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging host 192.0.2.20
logging trap informational
crypto ikev2 proposal IKEV2-PROP
encryption aes-cbc-256
integrity sha256
group 14
crypto ikev2 policy IKEV2-POL
proposal IKEV2-PROP
ip access-list extended ACL-NONAT-VPN
permit ip 10.12.20.0 0.0.0.255 10.20.0.0 0.0.255.255
permit ip 10.12.30.0 0.0.0.63 10.20.0.0 0.0.255.255
route-map RM-NONAT permit 10
match ip address ACL-NONAT-VPNAbnahme im Rollout: Standard-Tests pro Filiale
Jede Filiale sollte mit der gleichen Abnahmeliste geprüft werden. So sind Ergebnisse vergleichbar und Support kann Muster schnell erkennen.
- IKEv2 SA steht stabil, IPsec SA zählt Pakete
- Erreichbarkeit zentraler Testziele (Ping/Traceroute)
- No-NAT wirkt (kein NAT für VPN-Traffic)
- Logs enthalten keine Rekey-/DPD-Schleifen
Post-Checks (SOP)
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
show ip route
show ip nat translations
show logging | last 50Typische Fehlerbilder und Standard-Gegenmaßnahmen
Standardparameter helfen auch beim Troubleshooting: Wenn jeder Standort gleich ist, lassen sich Ursachen schneller finden. Diese Fehlerbilder sind in Filial-VPNs am häufigsten.
- Tunnel up, kein Traffic: No-NAT/Routing/Selektoren prüfen
- VPN instabil: DPD/Rekey, WAN-Loss, MTU/MSS prüfen
- Nur manche Apps: MTU/PMTUD/DNS, TCP-MSS-Clamp prüfen
- Nach Failover kein Recovery: Tracking/Peer-Prioritäten und Sessions prüfen
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.
