VPN-Konfigurationsvorlage: Welche Parameter in jede Doku gehören

Eine saubere VPN-Konfigurationsvorlage ist eines der wirkungsvollsten „Low-Tech“-Werkzeuge im Netzwerkbetrieb: Sie verhindert Ausfälle durch vergessene Parameter, beschleunigt Troubleshooting, erleichtert Audits und sorgt dafür, dass Tunnel-Setups reproduzierbar bleiben – auch wenn Teammitglieder wechseln oder externe Partner beteiligt sind. In der Praxis scheitern VPN-Projekte selten an der Kryptografie selbst, sondern an Dokumentationslücken: Niemand weiß, welche IKE/ESP-Proposals wirklich aktiv sind, welche Routen gepusht werden, ob NAT-T genutzt wird, welche Zertifikatskette gilt, wann Rekeying stattfindet oder welche Firewall-Regeln den Datenpfad begrenzen. Besonders kritisch wird das bei Standortvernetzungen mit mehreren Hubs, bei HA-Clustern, bei Remote Access mit mehreren Rollenprofilen oder wenn ein Incident auftritt und man nachweisen muss, wer wann auf welche Ressourcen zugreifen konnte. Eine gute VPN-Dokumentation ist deshalb nicht „Papierkram“, sondern Betriebs- und Sicherheitskontrolle. Dieser Artikel liefert eine praxiserprobte Struktur und erklärt, welche Parameter in jede VPN-Doku gehören – unabhängig davon, ob Sie IPsec/IKEv2, SSL/TLS-VPN, WireGuard oder OpenVPN einsetzen. Sie bekommen außerdem eine konkrete, kopierfähige Vorlage als Inhaltsliste, die Sie direkt als Standard in Ihrem Unternehmen verwenden können.

Warum eine VPN-Konfigurationsvorlage mehr bringt als „ein Wiki-Artikel“

Viele Teams dokumentieren VPNs „frei Hand“: ein paar Screenshots, ein paar Notizen. Das reicht, bis es ernst wird. Eine Vorlage zwingt zur Vollständigkeit und macht Dokumente vergleichbar. Dadurch gewinnen Sie:

• Schnelleres Troubleshooting: Sie sehen sofort, ob Routing, NAT, MTU, Proposals oder Zertifikate betroffen sein könnten.
• Weniger Ausfälle: Ablaufdaten, Rekey-Lifetimes und Abhängigkeiten sind sichtbar und werden überwacht.
• Bessere Sicherheit: „Least Privilege“ ist dokumentiert, Policy-Ausnahmen sind begründet, Legacy-Ciphers fallen auf.
• Auditierbarkeit: Rollen, Zugriffspfade und Logging sind nachvollziehbar.
• Reproduzierbarkeit: Neue Standorte oder neue Partner lassen sich konsistent anbinden.

Der zentrale Gedanke lautet: Dokumentation ist Teil der Konfiguration. Wenn ein Parameter nicht dokumentiert ist, gilt er im Betrieb praktisch als „unbekannt“ – und unbekannte Parameter sind ein Risiko.

Grundprinzip: Dokumentieren Sie immer vier Ebenen

Eine vollständige VPN-Doku deckt vier Ebenen ab. Das ist unabhängig vom Protokoll:

• Identität & Authentifizierung: Wer ist die Gegenstelle und wie wird sie verifiziert?
• Kryptografie & Aushandlung: Welche Algorithmen, Gruppen, Lifetimes und Modi werden genutzt?
• Datenpfad: Routing, NAT, DNS, MTU/MSS, Policies – also „wie fließt Traffic wirklich“?
• Betrieb: Logging, Monitoring, HA, Change- und Incident-Prozesse.

Wenn eine Doku eine dieser Ebenen nicht abbildet, ist sie im Ernstfall unvollständig.

Die VPN-Konfigurationsvorlage: Abschnitt für Abschnitt

Im Folgenden finden Sie die Vorlage als strukturierte Liste. Sie können sie 1:1 in Ihr Wiki übernehmen. Wichtig ist, dass Sie die Felder nicht „optional“ lassen, sondern bewusst markieren: nicht zutreffend oder nicht verwendet. Das verhindert Interpretationsfehler.

Abschnitt A: Metadaten und Verantwortlichkeiten

• VPN-Name / Tunnel-ID: eindeutige Bezeichnung (z. B. HQ-BR01-IPSEC).
• Typ: Site-to-Site, Remote Access, Hub-and-Spoke, Partnerzugang.
• Protokoll: IPsec/IKEv2, TLS/SSL-VPN, WireGuard, OpenVPN.
• Umgebung: Produktion, Staging, Test.
• Owner (fachlich) und Owner (technisch): wer entscheidet, wer betreibt?
• Kontakt & Eskalation: On-Call, Hersteller-Support, Partnerkontakt.
• Letzte Änderung: Datum, Change-ID/Ticket, verantwortliche Person.
• Abhängigkeiten: IdP/SSO, PKI, DNS, Upstream-Provider, Cloud-Security-Groups.

Abschnitt B: Topologie und Netzdesign

• Topologie: Punkt-zu-Punkt, Hub-and-Spoke, Mesh.
• Standorte/Peers: Namen, Rollen (Hub/Spoke), Region.
• Lokale Netze (CIDR): z. B. 10.10.0.0/16.
• Remote Netze (CIDR): z. B. 10.20.0.0/16.
• VPN-Transfernetz (bei route-based/VTI): Tunnel-IP(s) und Präfix (z. B. 169.254.100.0/30).
• Adresspools (Remote Access): Client-IP-Pool, Reservierungen, Konfliktvermeidung.
• Segmentierung: Zonenmodell (User, App, Data, Mgmt), erlaubte Pfade.
• Overlapping Networks: ja/nein; falls ja: NAT-/Translation-Konzept und Begründung.

Abschnitt C: Endpunkte und Erreichbarkeit

• Gateway/Peer-Endpoints: Public IP, FQDN, ggf. DDNS.
• Ports/Protokolle: z. B. UDP/500, UDP/4500, ESP (Proto 50) für IPsec; TCP/443 für TLS-VPN; UDP/51820 für WireGuard.
• NAT im Pfad: ja/nein; falls ja: NAT-T/Keepalive-Konzept.
• Firewall-Freigaben: auf beiden Seiten plus Cloud/Provider-Firewalls.
• QoS/Traffic-Klassen: falls VoIP/Video betroffen (DSCP, Priorisierung).

Abschnitt D: Authentifizierung und Identität

Dieser Teil ist bei Remote Access besonders wichtig, aber auch Site-to-Site braucht saubere Identitäten.

• Auth-Methode: PSK, Zertifikate (X.509), EAP, SSO (SAML/OIDC), MFA.
• Identity (ID/Peer ID): welche Identifier werden genutzt (FQDN, IP, DN, Key ID)?
• Zertifikatsdetails (falls genutzt): CA/Intermediate, Subject/SAN, EKU, Key Usage.
• PSK-Policy (falls genutzt): Länge/Komplexität, Rotation, Aufbewahrung, wer hat Zugriff.
• MFA: Pflicht ja/nein; Methode; Ausnahmen; Step-up für Admins.
• Gerätebindung: Gerätezertifikat, MDM-Compliance, EDR-Status.
• Offboarding-Prozess: wie wird ein Gerät/User gesperrt (CRL/OCSP, User Disable, Profil entziehen)?

Abschnitt E: Kryptografie und Aushandlung

Dieser Abschnitt ist häufig unvollständig dokumentiert – und genau das verursacht bei Interop und Security Reviews die meisten Probleme.

Für IPsec/IKEv2

• IKE-Version: IKEv2 (oder IKEv1, falls Legacy – begründen).
• IKE Proposal(s): Verschlüsselung, Integrität/PRF, DH/ECDH-Gruppe(n).
• ESP Proposal(s): Cipher/Mode (z. B. AES-GCM), Integrität (falls nötig), PFS-Gruppe.
• Lifetimes: IKE-SA, CHILD-SA (ESP) + Rekey-Strategie.
• DPD/Keepalive: Intervalle, Timeout, Action (restart/clear).
• NAT-T: aktiviert ja/nein; Verhalten bei NAT-Erkennung.
• MOBIKE: ja/nein (bei Remote Access relevant).
• Crypto-Policy: erlaubte/verbietete Ciphers, Legacy-Fallbacks.

Für TLS/SSL-VPN (OpenVPN & Co.)

• TLS-Versionen: Mindestversion, verbotene Legacy-Versionen.
• Cipher Suites: AEAD bevorzugt (z. B. AES-GCM/ChaCha20-Poly1305).
• Client Auth: Zertifikate, Username/Passwort, MFA, SSO.
• Key Rotation: Session Keys, Rekey-Intervalle.
• Härtung: tls-crypt/tls-auth (falls genutzt), Port/Proto-Strategie.

Für WireGuard

• Listen-Port, Endpoint, Keepalive (PersistentKeepalive).
• Peers: Public Keys, AllowedIPs (als Routing und Policy!), IP-Zuordnung.
• Key Rotation: Prozess, Offboarding, Dokumentation der Key-Owners.

Abschnitt F: Routing, Policies und Datenpfad

Hier entscheidet sich, ob ein VPN „wirklich“ funktioniert. Dieser Abschnitt ist Pflicht.

• Routing-Modus: Split Tunnel vs. Full Tunnel; Route-based vs. Policy-based.
• Routen: welche Prefixes werden geroutet/pusht; statisch oder dynamisch (BGP/OSPF).
• DNS: interne Resolver, Suchdomänen, Split-DNS-Konzept, DoH/DoT-Policy.
• NAT-Regeln: NAT-Exemptions, SNAT/DNAT, Reihenfolge, Begründung.
• Firewall-Regeln: erlaubte Ports/Services, explizite Denies, Zonenpfade.
• MTU/MSS: Tunnel-MTU, MSS-Clamping, PMTUD-Erwartung, Testszenarien.
• Asymmetrisches Routing: Risiken, Maßnahmen (PBR, ECMP-Handling, HA-Stickiness).

Abschnitt G: Betrieb, Monitoring und SIEM

Ein VPN ohne Betriebskapitel ist nicht produktionsreif.

• Logs: Auth-Events, Tunnel up/down, Rekey, DPD, Policy-Denies, Admin-Aktionen.
• KPIs: Login-Zeit P95, Reconnect-Rate, Abbruchgründe, Throughput, Drops, CPU (Crypto).
• Alerting: Schwellenwerte, Eskalationswege, Runbooks.
• SIEM-Felder: user, source.ip, assigned_ip, profile/group, gateway/node, failure.reason.
• Retention: Aufbewahrungsfristen, Zugriffsschutz, Datenschutz.
• Health Checks: synthetische Tests (Ping/HTTP), Tunnel-Checks, Failover-Checks.

Abschnitt H: Hochverfügbarkeit, Redundanz und Failover

• HA-Modus: Active/Passive, Active/Active; State Sync ja/nein.
• Redundante Uplinks: ISP1/ISP2, LTE/5G-Fallback, Prioritäten.
• Failover-Verhalten: wie schnell reconnectet der Tunnel, was passiert mit Sessions?
• Asymmetrie-Schutz: Session-Stickiness, Routing-Symmetrie, PBR.
• Testprotokoll: wann wurde Failover zuletzt real getestet (nicht nur „Status grün“)?

Abschnitt I: Security Hardening und Compliance

Dieser Teil sorgt dafür, dass ein Tunnel nicht nur funktioniert, sondern auch „vertretbar“ ist.

• Least Privilege: Begründung der Freigaben, keine „any-any“ Default-Regeln.
• Admin-Zugriff: separater Zugriffspfad, Bastion/Jump Host, Step-up MFA.
• Zertifikatsmanagement: Ablaufdaten, Rotation, Widerruf, CRL/OCSP-Erreichbarkeit.
• Patch- und Firmware-Policy: Wartungsfenster, Kritikalität, Notfall-Patches.
• Threat Model: wichtigste Angriffsvektoren (Brute Force, Exploits, Credential Stuffing) + Abwehrmaßnahmen.
• Dokumentierte Ausnahmen: jede Ausnahme mit Risiko, Owner, Ablaufdatum.

Für praktische Härtungsempfehlungen zu Remote-Access-VPNs eignet sich das NSA/CISA-Dokument: Selecting and Hardening Remote Access VPN Solutions (PDF).

Abschnitt J: Troubleshooting-Runbook

Eine gute Doku enthält nicht nur Parameter, sondern auch das „Was tun wenn?“. Das Runbook sollte mindestens enthalten:

• Symptom → Hypothese: „Tunnel up/no traffic“ → Routing/NAT/Policies prüfen.
• Standardchecks: Ports, NAT-T, SA-Status, Route-Table, DNS-Resolver, MTU.
• Logpfade: wo finden sich Auth-Logs, IKE/ESP-Logs, Policy-Denies?
• Rollback: wie kehren Sie zur letzten funktionierenden Konfiguration zurück?
• Kontaktpfade: ISP/Provider, Partner, Hersteller-Support.

Die häufigsten Dokumentationslücken (und wie Sie sie vermeiden)

• Unklare IDs/Peer-IDs: IKE-Identitäten sind nicht dokumentiert → Interop-Probleme.
• Proposals nicht eindeutig: „AES“ steht da, aber nicht Mode/Integrität/Gruppe → Fehlinterpretation.
• Routen fehlen: Tunnel-Parameter sind da, aber nicht, welche Netze wirklich geroutet werden.
• NAT-Exemptions fehlen: späteres NAT bricht Selektoren → plötzlich Traffic-Ausfall.
• DNS-Konzept fehlt: „VPN verbunden, aber Apps gehen nicht“ bleibt ungelöst.
• Ablaufdaten/Rotation fehlen: Zertifikat läuft ab → ungeplanter Ausfall.
• HA/Fallback ungetestet: Failover existiert auf Papier, bricht aber in der Realität.

Minimalvorlage für kleine Umgebungen (wenn es wirklich schlank sein muss)

Wenn Sie nur eine sehr kleine VPN-Landschaft haben, können Sie die Vorlage reduzieren – aber nicht unter diese Mindestfelder:

• VPN-Name, Typ, Owner, Umgebung
• Endpoints (FQDN/IP), Ports/Protokolle, NAT-T
• Lokale/Remote Netze, Routing-Modus, DNS
• Auth-Methode (PSK/Zertifikate), Proposals (IKE/ESP oder TLS/WireGuard-Keys)
• Firewall-Policies (erlaubte Services), NAT-Exemptions
• Logging-Standort, Monitoring-KPIs, Ablaufdaten/Rotation

Outbound-Links zur Vertiefung

• RFC 4301: IPsec Architecture
• RFC 7296: IKEv2
• RFC 5280: X.509 Certificates and CRL Profile
• RFC 6960: OCSP
• RFC 3947: NAT-Traversal Negotiation in IKE
• RFC 3948: UDP Encapsulation of IPsec ESP (NAT-T)
• NSA/CISA: Selecting and Hardening Remote Access VPN Solutions (PDF)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.