Policy-basierte vs. routenbasierte VPN: Was 2026 wählen und wo man aufpasst

Einleitung: Warum die Wahl des Routings bei VPN den halben Erfolg ausmacht

Worüber wir diskutieren: policy-basierte gegen routenbasierte Ansätze

Seien wir ehrlich: Beim Aufbau eines Unternehmens-VPNs ist die wichtigste Entscheidung nicht nur die Wahl der Verschlüsselung oder des Vendors. Der Schlüssel liegt woanders. Wie steuern wir den Datenverkehr? Über Policies oder Routen? Policy-basierte und routenbasierte VPNs sind zwei Stile, zwei Philosophien. Der erste beruht auf Regeln, die festlegen, welcher Traffic verschlüsselt wird und wohin er geht. Der zweite baut virtuelle Interfaces auf und vertraut dem Router. Klingt simpel? Auf dem Papier ja, im Produktiveinsatz hängt es vom Glück ab.

2026 steht viel auf dem Spiel: Hybride Clouds, SASE und SD-WAN, reine IPv6-Segmente und hohe Anforderungen an Observability. Traffic springt zwischen Niederlassungen, Clouds, Partnern und entfernten Mitarbeitern hin und her. Wir brauchen eine Lösung, die Wachstum, Compliance und nächtliche Upgrades ohne SLA-Verluste meistert. Und ja, bitte ohne hektische Flickschusterei, bei der Mechaniker das Flugzeug während des Flugs zusammenbauen müssen.

In diesem Artikel klären wir ehrlich und mit Beispielen die verschiedenen Routingtypen in VPN, erläutern die Unterschiede zwischen policy-basiertem und routenbasiertem Ansatz, zeigen, wo was besser funktioniert und wo es wehtut. Wir liefern praktische Konfigurationsrezepte für gängige Plattformen und Checklisten, damit Sie von Anfang an richtig loslegen.

Warum das gerade jetzt so wichtig ist

Der Trend 2026 heißt Vereinheitlichung der Netzwerkfabric. Unternehmen bringen WAN, Cloud-VPCs/VNets und Campus-Netzwerke unter eine einheitliche Routing-, Observability- und Automatisierungs-Policy. In diesem Puzzle kommt policy-basiertes IPsec dynamisch nicht immer mit: Ende-zu-Ende Telemetrie, ECMP, BFD, Traffic-Interception zur Inspektion, Multicloud mit BGP über IPsec – all das ist in einer routenbasierten Architektur einfacher. Doch! Bei per-App-Tunneln, wo Sicherheit vor Flexibilität steht, ist policy-basiert nach wie vor König. Wir sind nicht für eine Religion, sondern für einen pragmatischen Mix.

Andererseits drängt das Wachstum von WireGuard und QUIC-Tunneln die Anbieter zu Interface-orientierten Modellen. Selbst alte Schwergewichte aus der klassischen IPsec-Welt weichen nicht länger: VTI, routenbasiert, SD-WAN Fabric sind der neue Normalzustand. Ein guter Engineer muss beide Seiten kennen und sie ästhetisch gemäß der Aufgabenstellung kombinieren können.

Drei häufige Fehler, die Kopfweh bereiten

Erstens: „Unpassendes aufdrängen“ – man versucht, policy-basiertes Routing in Designs zu zwängen, die klar dynamisches Routing verlangen. Zweitens der „Tunnel-Dreieck“ – dutzende statische Verbindungen bauen, wo BGP viele Probleme an einem Abend lösen würde. Drittens: MTU und MSS unterschätzen. VPN lebt von der Endlast: Eine falsche DF-Einstellung, und die Videokonferenz des CEOs wird zur Diashow. Kleinigkeiten entscheiden. Immer.

Grundlagen: Wie IPsec und Routing zusammenspielen

IKE, SA und Traffic-Selector

IPsec besteht aus zwei großen Modulen: IKE (Schlüsselaustauschphase) und SA (Security Associations), die den Traffic schützen. Bei IKEv2 verhandeln wir Verschlüsselung, Authentifizierung und Lebensdauer. Dann bilden wir SA-Paare für beide Seiten. In policy-basierten Setups ist der SA-Selector ein Triade aus Quelle, Ziel und Protokoll/Port. Je mehr einzigartige Paare und Apps, desto mehr SA, desto komplexer das Leben.

Routenbasiert verteilt die Karten anders: Der Selector wird oft auf „any-to-any“ innerhalb des Tunnels gesetzt, Traffic wird über Firewall Policies an den Interfaces gefiltert und geroutet. Das erlaubt Flexibilität, besonders bei dynamischer Route und Multipath. Selector werden zur Nebensache, und Sie müssen nicht mehr Dutzende von ACL für jeden neuen Service im Kopf haben.

SPD, SAD und Verschlüsselungspolicies

Das Gerät überprüft das SPD (Security Policy Database), um zu entscheiden, welcher Traffic in VPN muss und welcher offen bleibt. Dort liegen Regeln, die Traffic Matching und Aktionen definieren, z.B. mit welchen Parametern verschlüsseln oder ungefiltert lassen. Die SAD (Security Association Database) hält die aktuellen SA – aktive Tunnel mit deren SPI, Keys und Lebensdauer. Im policy-basierten Modell ist SPD der Klebstoff, der alles zusammenhält, bei routenbasiertem ist SPD sehr einfach, denn jeglicher Traffic am Tunnelinterface wird standardmäßig verschlüsselt.

Klingt routenbasiert als klarer Sieger? Fast. Wenn strenge Isolierung gefordert ist und nur genau definierte Subnetze in den Tunnel dürfen, setzt policy-basiert das deutlicher um. Routenbasiert erreicht das über Filter und ACL an Interfaces plus bei Bedarf über VRF.

VTI, GRE über IPsec und warum Interfaces regieren

2026 unterstützen die meisten Vendors VTI – virtuelle Tunnelinterfaces, die logische Punkt-zu-Punkt-Links bereitstellen. IP vergeben, OSPF oder BGP drauf, fertig. GRE über IPsec kapselt GRE in die Verschlüsselung ein für Multiprotokoll-Unterstützung und vereinfachte Fälle (z.B. Multicast), verursacht aber mehr Overhead und MTU-Management. Meist reicht VTI. Der Stack wird einfacher, Monitoring klarer, Automatisierung direkter.

Policy-basierte VPN: Kern, Stärken und Schwächen

Wie die Policy gebildet wird: ACLs, Crypto Maps und Selector

Policy-basierte VPNs basieren auf „Wenn Traffic auf Regel passt – dann verschlüsseln“. Praktisch heißt das: ACLs oder ähnliche definieren Source- und Zielsubnetze, manchmal auch Ports und Protokolle. Diese Regeln werden über Crypto Maps mit Krypto-Profilen verbunden. Jedes Regelset kann einen eigenen Satz SA erzeugen.

Vorteil: klare und transparente Isolation. Man muss kein Interface hochziehen, keine Tunnel-IP vergeben, weniger Komplexität auf der Oberfläche. Nachteil: Skalierung. Sobald dutzende Apps, verschiedene Zonen oder asymmetrische Routen zu Clouds ins Spiel kommen, entstehen Abstimmungsprobleme. Regeln multiplizieren sich, jeder Change wird zum „No-Error-Modus“.

Wo policy-basiert glänzt

Es gibt Anwendungsfälle, wo diese Routing-Art sehr praktisch ist. Punktuelle Datenverbindung mit Partnern: ein bis zwei Subnetze, klare Grenzen, kaum Dynamik. Oder bei Perimeter-Firewalls, die primär Apps inspizieren, Tunnel nur als Nebenfunktion. Hochsichere Zonen mit minimaler Angrifffläche – keine zusätzlichen Interfaces, alles streng kontrolliert per Selector.

Bei manchen älteren Cloud-Gateways bleibt policy-basiert bevorzugt, vor allem wenn der Anbieter nur Selector-basierte Szenarien unterstützt. Nicht häufig, aber bei einigen MPLS/VPN Providern ist policy-basiert in ihrer Infrastruktur zuverlässiger.

Fallstricke und Grenzen

Größter Nachteil ist mangelnde Flexibilität. Dynamisches Routing, ECMP, BFD und schnelles Umschalten je nach SLA blockiert policy-basiert. Einige Anbieter unterstützen pseudo-dynamische Kombinationen, aber das sind Kompromisse, keine klare Route.

Ein weiteres Problem sind NAT und asymmetrischer Traffic. NAT vor IPsec kann Selector-Desynchronisation auslösen. Unterschiedliche MTUs auf verschiedenen Leitungen führen zu merkwürdigen „Hängern“ bei Anwendungen. Telemetrie ist aufwändiger: Einen Tunnel als Interface zu monitoren ist leichter als indirekte SA- oder ACL-Metriken zu sammeln. Das fällt in großen Umgebungen deutlich ins Gewicht.

Routenbasierte VPN: Interfaces, Dynamik und Skalierung

Virtuelle Tunnelinterface und ihre Magie

Routenbasierte VPNs beruhen auf Tunnelinterfaces: Jede Seite erhält IP, danach läuft klassisches Routing. OSPF gefällig? Kein Problem. BGP? Leicht. Mehrere Pfade, Lastverteilung? ECMP, Policy Routing, PBR am Interface. Einfach gesagt: Traffic, der am Tunnelinterface ankommt, wird verschlüsselt. Selector verlieren ihren Fokus.

Ein großer Vorteil sind Standard-Diagnosetools. Ping, Traceroute, SNMP, Streaming-Telemetrie, realistisches SLA-Tracking. Man hört auf, im Blindflug zu reparieren, und kann wie ein echter Netzwerkingenieur arbeiten: Wenn das Interface spinnt, sucht man den Grund, Alarme gehen an NOC und SIEM.

Routing: statisch, OSPF, BGP

Statische Routen sind für kleine Netze noch üblich. Doch 2026 ist BGP über IPsec bei mehr als fünf bis zehn Standorten und Cloud fast Standard. Warum nicht OSPF? Funktioniert auch, besonders bei einfachen Hub-and-Spoke-Patterns. Aber BGP ist flexibler an autonomer Segmentgrenze, einfacher in Pfad- und Ankündigungskontrolle, stabiler bei häufigen Änderungen. Zudem lieben große Public Clouds BGP auf ihren VPN-Gateways.

Dynamik ist kein Selbstzweck. Sie liefert schnelle Konvergenz bei Ausfällen, nahtlose Subnetz-Erweiterung ohne manuelles Rumfummeln und transparente Pfadpräferenz-Policies. Keine Luxuslösung, sondern Basis für SLO/SLA – was das Business braucht.

Performance und Blick in die Zukunft

2026 können Router und NGFWs AES-GCM hardwarebeschleunigt, manche bringen ChaCha20-Poly1305 für Plattformen ohne AES-NI – super Sache. Routenbasiert lässt sich einfach ein weiterer Tunnel für Migrationen hinzufügen, QoS per Interface realisieren, per-Tunnel SLA Checks implementieren. SD-WAN baut meist routenbasiert auf: zentralisierte Steuerung, Segmentierung, Policy-basiertes Steering. In policy-basiertem Szenario auch machbar, aber mit viel mehr Aufwand und Nerven, speziell in heterogenen Umgebungen.

Vergleich policy-basiert vs. routenbasiert: Auswahlkriterien

Komplexität und Skalierbarkeit

Für zwei Büros und drei Server wirkt policy-basiert meist einfacher in Konfiguration und Wartung. Sobald die Größe wächst, gewinnt routenbasiert. Man jongliert nicht mehr Hunderte von Selector-Paaren, sondern arbeitet mit Interfaces, Routen und Policies. Menschliche Fehler minimieren sich, Automatisierung wird leichter erreichbar. Also: weniger nächtliche Eskalationen.

Daumenregel: Mit Cloud, mehreren Providern, Telemetrie- und Schnellkonvergenzanforderungen: routenbasiert. Punktuelle Partnerverbindungen mit strikten Restriktionen: policy-basiert.

Sicherheit und Transparenz

Policy-basiert ist von Haus aus geschlossen. Verschlüsselt nur, was explizit definiert ist. Auditoren lieben das, manche Standards erklären sich leichter so. Routenbasiert ist nicht weniger sicher, jedoch anders: Filter an Interfaces, Zonen, VRF, ACL. Wenn Ihr Team Firewall-Policies und Segmentierung sicher beherrscht, liefert routenbasiert vergleichbares Sicherheitsniveau mit Skalierungsvorteil.

Kompatibilität und Multivendor

In heterogenen Netzwerken mit verschiedenen Herstellern ist routenbasiert oft vorhersehbarer. Selector-Interpretationen und IKE Extensions können unterschiedlich sein. Interface-basierte Modelle glätten diese Unterschiede, gerade bei IPv6-only- und BGP-over-IPsec-Migrationen. Dennoch gibt es Legacy- und Provider-Szenarien, in denen policy-basierte das einzige funktionierende Modell bleibt. Hier zählt gesunder Menschenverstand und Pilotierung.

Anwendungsfälle und Architekturen 2026

Standort-zu-Standort: vom Einfachen zum Reifen

Einsteiger-Level: policy-basiert zwischen zwei Standorten mit ein bis zwei Subnetzen. Günstig, robust, übersichtlich. Mittelstufe: Hub-and-Spoke, wobei Depots Tunnel zum Zentrum aufbauen. Routenbasiert gewinnt hier: Neue Standorte, dynamische Protokolle, Ankündigungen laufen, Policies am Hub sitzen. Reife Stufe: Zwei Hubs in verschiedenen Regionen, ECMP, BFD, SLA auf Tunnel, Traffic-Interception für Inspektion, QoS. Fast SD-WAN, routenbasiert ist unschlagbar.

Hybride Cloud: AWS, Azure, GCP

Public Clouds favorisieren routenbasiert. AWS VGW und Accelerated GW, Azure VPN Gateway, GCP Cloud VPN verstehen BGP bestens. VTI hochgezogen, ASN konfiguriert, Präfixe angekündigt, fertig. Policy-basiert gibt es, vor allem bei alten SKUs oder plattformübergreifenden Einschränkungen, doch flexibler, für DR und Multicloud lebt es sich leichter routenbasiert. 2026 setzen viele auf IPv6 in Cloud-VPC/VNet, BGP rettet verwaltete Präfixanbahnungen.

SD-WAN, SASE und ZTNA

SD-WAN Controller bauen Overlays meist auf routenbasierten Tunnels auf, egal ob eigene Protokolle oder IPsec darunter. SASE, wenn es mit Ihrem Perimeter integriert wird, setzt ebenfalls auf Interface-basierte Tunnel: Metriken ausspielen, Traffic balancieren, Business Policies durchsetzen sind einfacher mit VTI. ZTNA ist eine andere Welt, benötigt aber in hybriden Settings Backhaul zu Ihren Netzwerken; Interfaces sind auch da angenehmer. Rezept: Mixen Sie. Für sensiblen, riskanten Traffic policy-basiert, für den Rest routenbasiert.

Multivendor-Verbindungen und M&A

Bei Fusionen und Übernahmen müssen Netzwerke meist schnell zusammengeführt werden. Wenn verschiedene Vendoren und Policies im Spiel sind, beschleunigt routenbasiert die Integration. VTI aufbauen, BGP initiieren, Filter anlegen, dann schrittweise erweitern. Falls Sicherheit „Skalpell statt Schere“ verlangt, nutzen Sie erstmal policy-basiert für kritisch limitierte Kanäle, später migrativ interface-basiert, wenn der Staub sich gelegt hat.

Praxis: Konfiguration auf beliebten Plattformen

Cisco: ASA/FTD und IOS-XE

Auf ASA/FTD war policy-basiert historisch der Standard via Crypto Maps und ACLs. Neuere Versionen unterstützen VTI und machen routenbasiert möglich, obwohl ASA bei Diagnose und Management Eigenheiten hat. Für viele Standorte und BGP ist IOS-XE (ISR/ASR/Catalyst) besser: VTI, IPsec Profiles, DMVPN oder FlexVPN sind hier Heimat. Praxis-Tipp: ASA für kleine partnerbezogene Punkt-zu-Punkt-Verbindungen, das Hauptnetz auf IOS-XE mit VTI und dynamischem Routing.

Grundschritte: IKEv2-Policy und Chiffren festlegen, IPsec Transform-Set/Profile konfigurieren, VTI mit IP-Adressen hinzufügen, IGP oder BGP aktivieren, ACL/Zone-based Firewall am Tunnelinterface anwenden. Nicht vergessen: MSS Clamp und PMTUD.

Juniper SRX und Fortinet FortiGate

SRX glänzt traditionell bei routenbasiertem Ansatz: st0 Interfaces, gefestigte OSPF/BGP-Integration, reichhaltiges Policy-Toolkit. FortiGate ist stark bei VTI und BGP over IPsec, plus benutzerfreundliche GUI Wizards, die an müden Abenden Rettung bringen. Policy-basiert wird auf beiden unterstützt, aber nur dort empfohlen, wo es sinnvoll ist – begrenzte Selector, Partnerverbindungen, kleine Projekte. Für Enterprise Fabrics: eindeutig Interfaces und Dynamik.

Praktische Tipps: Auf FortiGate bei routenbasiert Phase2-Selector 0.0.0.0/0 setzen, um Traffic-Beschränkungen zu entfernen und mittels Policies filtern. Auf SRX Security Zones und Policies zu und von st0 genau prüfen, um keine Löcher zu öffnen. DPD einschalten.

MikroTik, pfSense/OPNsense, StrongSwan

MikroTik RouterOS v7 hat IPsec und BGP stark verbessert: Routenbasiert ist realistisch, auch wenn es noch Ecken bei Interfaces und Monitoring gibt. pfSense/OPNsense mit StrongSwan bieten beide Modelle: Policy-basiert über Phase2 mit bestimmten Netzwerken, routenbasiert über VTI. Tipp: Wer Cloud oder Wachstum plant, sollte VTI einsetzen – sonst wird die Migration sandig.

Bei StrongSwan unter Linux ist routenbasiert fast Standard: Tunnelinterface (z.B. xfrm oder vti) anlegen, statische Routen oder BGP (FRRouting) konfigurieren, iptables/nftables filtern. Für per-App Schutz und minimalen Fußabdruck separate Config-Instanzen und Selektoren in policy-basiert halten, aber das ist gezieltes Werkzeug.

Cloud: AWS, Azure, GCP

— AWS: Für Dynamik AWS Site-to-Site VPN mit BGP nutzen. Hohe Performance mit Accelerated VPN oder Transit Gateway, das routenbasiert und auf BGP aufbaut. Policy-basiert möglich, aber meist für alte Fälle.
— Azure: VPN Gateway (RouteBased) mit Unterstützung für IKEv2, BGP und Active-Active-Modus. PolicyBased SKU ist spezialisiert und limitiert.
— GCP: HA VPN mit BGP Standard, Classic VPN inzwischen Legacy. Überall wichtig: MTU End-to-End prüfen, Präfixe filtern, Uptime über Dual Tunnels und ECMP sichern.

Performance, MTU und QoS

MTU, MSS und PMTUD: Kleinigkeiten, die kritisch sind

IPsec erhöht den Overhead. VTI, GRE über IPsec noch mehr. Praktisch heißt das: effektive MTU reduziert sich. Fehler im DF-Bit-Setzen oder ICMP Fragmentation Blockade töten große Pakete. Rezept: PMTUD aktivieren, nötige ICMP-Typen zulassen, MSS Clamp auf 1360–1380 für TCP mit Tunneleinschlag einstellen, sichere MTU praktisch messen – auf beiden Seiten prüfen wegen Asymmetrie.

Bewährte Praxis: MTU/MSS Werte direkt neben Tunnel-Konfig im Dokument notieren, damit nicht in sechs Monaten wieder die gleichen Fehler passieren. Testskripte für große Pakete bereitstellen.

Kryptographie und Beschleunigung

2026 unterstützen fast alle AES-GCM hardwaremäßig. ChaCha20-Poly1305 ist großartige Alternative auf Plattformen ohne AES-NI. Chiffrenwahl beeinflusst Latenz und Durchsatz. Messungen zeigen oft 20–40 % Gewinn vom Wechsel von AES-CBC+SHA1 zu AES-GCM. Weniger CPU, geringerer Jitter, bessere Qualität bei Telefonie und Video.

Vergessen Sie PFS (Perfect Forward Secrecy) nicht: keine bloße Einstellung, sondern essenzielle Sicherheit. IKEv2 gilt als klarer Favorit gegenüber IKEv1. SA-Lifetimes vernünftig setzen: kürzer heißt sicherer, aber nicht zu kurz wegen CPU-Belastung.

QoS und Priorisierung

Routenbasiert erlaubt QoS direkt am Tunnelinterface mit DSCP Beibehaltung/Modifikation und Klassen-Shaping. Policy-basiert ist komplizierter und Vendor-abhängig. Bei Sprach- und Videotransport über VPN ist QoS Pflicht. Nutzen Sie per-Tunnel Policies mit SLA-Checks: Packet Loss steigt über Grenzwert – dann Link wechseln. Kluges Engineering, kein Übervorsicht.

Ausfallsicherheit und Monitoring

DPD, SLA und BFD: schnelle Augen und Hände

Dead Peer Detection informiert darüber, ob der Peer erreichbar ist. Für echte Geschwindigkeit integrieren Sie BFD über den Tunnel ins IGP/BGP. Dann ist die Konvergenz binnen Hunderten Millisekunden, nicht Sekunden. IP SLA oder vergleichbare Messungen zeigen Verzögerung, Jitter, Paketverluste. Routing arbeitet mit echten Daten, nicht mit Mutmaßungen.

Tipp: Standardisierte Timing-Profile und Schwellen für gängige Verbindungen anlegen und Reaktionen automatisieren. Mensch ist für Analyse, nicht für nächtliche Hetzjagden da.

Active-Active, ECMP und Multipathing

Wenn Provider es zulassen, richten Sie zwei Tunnel zu unterschiedlichen Entry-Punkten ein. ECMP auf SLA-Basis ist State-of-the-Art. Für kritische Services eliminiert das Single Point of Failure. Bei policy-basiert sind solche Konstrukte möglich, aber selten elegant. Bei routingbasiert gerät das zum natürlichen Umgang: mehrere Interfaces, Gewichtung, Probes und Load-Profiles.

Observability: Logs, Flows, Telemetrie

Wir leben 2026 im Zeitalter des observablen Netzwerks. IKE/IPsec Logs in SIEM, NetFlow/IPFIX vom Tunnel zu Analyse, Interface-Metriken ins Monitoring – kein Nice-to-have, sondern Pflicht. Alarme bei SLA-Degeneration und Tunnelflapping gehören dazu. Und bitte hübsche Dashboards malen: schnelle visuelle Erklärungen fürs Management sparen Nerven.

Sicherheit und Compliance

Moderne Chiffren und Crypto-Agilität

Setzen Sie auf IKEv2, PFS, AES-GCM oder ChaCha20-Poly1305. Verabschieden Sie sich von veralteten Algorithmen. Vendorempfehlungen beachten und Chiffrenprofile aktuell halten. Crypto-Agilität – schnelle Migration auf neue Krypto-Sätze – ist heute echtes Compliance-Kriterium. Dokumentieren, früh testen und Umstellungsplan bereithalten.

Zertifikate statt Pre-Shared Keys sind fast Pflicht in mittleren und großen Netzwerken. PKI lässt sich über ACME oder Integration in Firmen-CA vereinfachen. Disziplin für Engineers und Prozesse.

Segmentierung, VRF und Mikro-Isolation

Bei routingbasiert sind VRFs Gold wert. Tunnel können unterschiedlichen VRFs, Policies und eingeschränkten Routen zugeordnet werden. Ein Angriff in einem Segment läuft so nicht in ein anderes über. Policy-basiert erreicht Ähnliches über Regelsätze, aber VRFs sind leichter zu pflegen und zu erklären. Kombinieren Sie NGFW Mikrosegmentierung für das Prinzip „Minimaler Zugang“.

Audit und Retrospektiven

Führen Sie regelmäßige Reviews durch: Welche Selector werden noch gebraucht? Wo sind Routen redundant? Wo sind Policies zu breit gefasst? Verknüpfen Sie Logs von IKE, IPsec, Firewall und BGP, um das umfassende Bild zu sehen. Incidents mögen keine Stille – verhindern Sie das. Nach großen Changes immer eine Retrospektive und Ergebnisse ins Playbook schreiben.

Test, Diagnose und typische Fehler

Checkpoints beim Tunnelaufbau

Prüfablauf klar: IKE SA vorhanden? Super. IPsec SA? Sind Selector/SPD korrekt? Ping übers Tunnelinterface? Trace und Routenübersicht? Bei policy-basiert prüfen wir ACLs auf Präzision und NAT-Verträglichkeit. Bei routingbasiert ACLs inbound/outbound am Interface und IGP/BGP Nachbarschaft checken.

Danach: Anwendungstests. Layer7 kann Überraschungen bringen: MTU, Timeouts, Reconnects. Erstellen Sie Testskripte mit pings, curl, iperf, verschiedenen Paketgrößen. Weniger Improvisation bedeutet geringere Chance, kleine aber fiese Probleme zu übersehen.

MTU, Fragmentierung und DF-Bit

Klassiker: ICMP blockiert oder DF-Bit falsch, und große Pakete gehen stumm verloren. Lösung: PMTUD aktivieren, ICMP Type 3 Code 4 zulassen, MSS Clamp setzen. Beide Seiten prüfen. Achten Sie auf Asymmetrie: 1476 rein, 1454 raus – abweichendes App-Verhalten ist Physik, kein Zauber.

NAT-Traversal und asymmetrisches Routing

NAT-T hilft, wenn ein Peer hinter NAT ist. Komplexitäten entstehen durch gleiche Ports, Session-Drift, seltene FW Bugs. Firmware aktuell halten, IKE/IPsec-Diagnose einschalten. Asymmetrisches Routing ist eine weitere Herausforderung: Hälfte des Flows geht über einen Tunnel rein, die Antwort kommt über einen anderen und ein Stateful Firewall lehnt ab. Lösung: Symmetrie planen, per-Tunnel Policies oder Session-Synchronisation in Clustern verwenden.

Automatisierung und IaC für VPN

Terraform, Ansible und GitOps

Terraform für Cloud und manche Vendors, Ansible für Netzwerkkonfigurationen, Git als Single Source of Truth. Bei routenbasiert ist Automatisierung natürlicher: Tunnelinterfaces, ASN, Ankündigungen, SLA parametrisieren. Policy-basiert geht auch, aber viele Selector und ACL verlangen mehr Sorgfalt und Templates.

GitOps-Prinzip: Alle Änderungen per Pull-Request, Policy-Checks mit Lintern, automatisierte Tests im Lab, Deployment zeitlich gesteuert in Wartungsfenstern. Nicht „zu kompliziert“, sondern günstiger als die nächste große Panne.

Tests und Verifikation

Validieren-vor-merge: Vor Produktiv-Änderung Tests starten. Temporären Tunnel im Lab hochfahren, BGP-Sessions prüfen, pingen, MTU, QoS Tags. Bei policy-basiert: Selector-Konformität, Konfliktefreiheit, NAT korrekte Handhabung. Bei routing-basiert: Routen korrekt, keine VRF-Leaks, Policy konsistent.

Secrets und Sicherheit der Automatisierung

PSKs und Zertifikate in Secret Stores (Vault, KMS, Kubernetes Secrets bei CNI-Umgebungen) sichern. Keine Schlüssel unverschlüsselt ins Repository packen. Dokumentieren, wer wann welche Kryptopolitik änderte. Und vor allem: Keys regelmäßig rotieren planen, nicht nur „irgendwann mal“.

Ökonomie und Auswahl

Lizenzen, Performance und Hardware

Ehrlich rechnen: Manche Vendors lizenzieren VPN-Tunnel, Bandbreite oder Crypto-Beschleunigung. Routenbasiert belastet Interfaces mehr, aber nicht zwangsläufig teurer – Plattformabhängig. Hardwarebeschleunigung für AES-GCM spart CPU und Kosten: Weniger Hardware für gleiche SLA. Policy-basiert bei vielen SA nutzt preiswerte Plattformen schneller aus.

Betriebskosten

Leben ist Wartung. Routingbasiert günstiger im Betrieb, wenn Topologie oft wächst und verändert wird, Netze expandieren, Clouds wachsen. Monitoring, Automatisierung, Template-Uniformität sind Freunde. Policy-basiert punktet bei kleinen, festen Szenarien. Entscheidung ist kein Glaube, sondern Excel mit Risiken und Anforderungen.

Die Rechnung für eine falsche Wahl

Typischer Fall: Firma wächst dreifach, hat hunderte policy-basierte Tunnel mit jeweiligen ACLs. Jeder Change ein Minenfeld. Migration zu routenbasiert passiert nachts unter Druck. Monate an Aufwand wären überflüssig gewesen, wenn von Anfang an VTI und Dynamik geplant gewesen wären. Natürlich gibt es auch Gegenbeispiele: Interface-basiert überall aktiviert, aber dann darf ein Partner nur bestimmte Subnetze nutzen – lokale ACL-Komplexität wächst. Goldene Regel: Hybrid planen.

Checklisten und bewährte Vorgehen

Architekturwahl

• Cloud vorhanden und Wachstum geplant? Route-basiert, VTI, BGP wählen.
• Punktueller Partnerdatenaustausch? Policy-basiert mit klaren Selector-Regeln.
• Tunnel-SLA benötigt? Route-basiert mit IP SLA/BFD.
• Strikte Segmentierungsanforderungen? VRF + Interface-Firewall oder gezielte Selector.

Implementierung

• Kryptopolitik bestimmen: IKEv2, PFS, AES-GCM/ChaCha20.
• MTU End-to-End prüfen, PMTUD und MSS Clamp aktivieren.
• Routenbasiert: ASN, Präfixfilterung, BGP-Attribute planen.
• Policy-basiert: Selector minimal halten, keine unnötigen Port-spezifischen Regeln.

Betrieb

• IKE/IPsec Logs in SIEM, Interface-Metriken im Monitoring, SLA-Degradationsalarme.
• Regelmäßige Rotation von Keys und Zertifikaten, Firmware Updates.
• Automatisierte Tests nach Änderungen, Retrospektiven, Playbook Updates.
• Quartalsweise Audit von Routen und Zugriffspolicies.

Echte Anwendungsfälle und Lösungsmuster

Fall 1: Von 20 zu 60 Standorten in einem Jahr

Das Unternehmen startete mit policy-basiert: Zwei Provider, drei Partner, simpel. Innerhalb eines Jahres kamen 40 neue Standorte und zwei Cloudregionen hinzu. Migration zu routenbasiert erfolgte. Für jeden Standort zwei VTI aufgebaut, BGP mit Communities aktiviert, ECMP und VoIP-Priorisierung implementiert. Ergebnis: Konvergenz unter einer Sekunde, flexible Subnetzerweiterung, 30 % weniger NOC-Incidents.

Fall 2: Partner mit regulatorischen Restriktionen

Partner bestand auf policy-basiert mit strikten Selector und IKE-Params. Lösung: Für diesen Partner policy-basiert belassen, für anderes interoffice Traffic routenbasiert fahren. Perimeter ergänzt mit DSCP-Translation und doppelter NGFW-Inspection. Gemeinsames SLA-Monitoring eingeführt, Lasttests durchgeführt. Alle zufrieden, keine Änderung der Standardvorgaben nötig.

Fall 3: Migration von IPv4-only zu hybrid mit IPv6

Clouds und Standorte schalteten langsam IPv6 ein. Auf routenbasiertem VTI BGP mit dualen Addressfamilien gestartet, Präfixe fein gesteuert angekündigt, QoS und Telemetrie erhalten. Für Legacy-Services mit Problemen bei großen Paketen MSS optimiert. Migration lief ohne Downtime, weil das Interface-Modell nativ „zwei Epochen“ parallel erlaubt.

Häufige Fallen und wie man sie umgeht

Zuviele Selector

Wenn die policy-basierte Regel-Liste schneller wächst als Ihr Playbook, sind Sie in Gefahr. Lösung: Subnetze gruppieren, Interface-basierte Tunnel einführen, Filter auf Firewall-Policies verlagern. Stufenweise Migration: Erst parallelen routenbasierten Kanal schaffen, dann sukzessive Routen umstellen.

Blinde Monitoring-Zone

Policy-basiert ohne Interface bedeutet keine direkten Metriken. Ignorieren Sie das nicht. Separat Telemetrie je SA freistellen, IKE/IPsec Logs nutzen, NetFlow vor und nach Tunnel sammeln. Oder wechseln Sie zu routenbasiert: Interface wird Ihr bester Freund für Observability.

„Funktionierte – und plötzlich nicht mehr“

Häufigst Fehler: Neu-Key-Generierung auf nur einer Seite, Firmware-Bugs oder ermüdeter NAT-T. Firmware updaten, Diagnose aktivieren, Crypto-Profile und Lifetimes vergleichen. Vendor-Kompatibilitätsmatrix pflegen. Langweilig, aber schont Ihre Nächte.

Migrationsplan: schmerzfreier Übergang von policy- zu routenbasiert

Schrittweise Migration

Parallel VTI etablieren, statische Routen mit höherer Administrative Distance hochziehen. Tests durchlaufen, Telemetrie einschalten. Teilweise Präfixe mit BGP low-risk übertragen. ACLs an Interfaces sicherstellen, Policy-basiertes Selector-Leben reduzieren, nicht abrupt abschalten.

Qualitätskontrolle

SLOs definieren: Latenz, Verlust, Jitter. Monitoring auf Degradation einstellen. BFD aktivieren, wenn verfügbar. Failover gezielt testen: Einen Link abschalten, Konvergenz beobachten, Alarm-Schwellen prüfen, Anwendungsreaktionen testen. Dieser Crash-Test erspart viele Stunden Stress.

Kommunikation und Dokumentation

Schema, Präfixe, ASN, Kryptopolitik, MTU/MSS, Kontrollbefehle dokumentieren. Diagramme und Checklisten mit Support-Team teilen. Zeitfenster für Änderungen und Fallback-Plan definieren – oft unterscheidet das kontrollierte Migrationsprojekt von Chaos.

FAQ

Schnelle Antworten, Teil 1

• Frage: Was für ein kleines Büro ohne Cloud? Antwort: Policy-basiert, wenn wenig Subnetze und wenige Änderungen. Einfacher und günstiger im Setup.
• Frage: Was für hybride Cloud mit Wachstum? Antwort: Routenbasiert mit VTI und BGP. Mehr Flexibilität, Telemetrie und einfachere Automatisierung.
• Frage: Können Ansätze gemischt werden? Antwort: Ja, und das ist normal. Partner und punktuelle Integration policy-basiert, Hauptperimeter routenbasiert.

Schnelle Antworten, Teil 2

• Frage: Wie mit QoS innerhalb von IPsec umgehen? Antwort: DSCP-Erhaltung und Interface-basierte Policies arbeiten besser im routenbasierten Modell. Policy-basiert ist Vendor-abhängig und schwieriger.
• Frage: Wie „Hänger“ bei großen Paketen vermeiden? Antwort: PMTUD aktivieren, ICMP Frag Needed erlauben, MSS Clamp konfigurieren. MTU beidseitig prüfen.
• Frage: Ist IKEv2 notwendig? Antwort: Ja, es ist robuster, flexibler und sicherer als IKEv1. Zudem in Clouds besser unterstützt.

Schnelle Antworten, Teil 3

• Frage: Dynamisch oder statisch routen? Antwort: Für bis zu fünf Standorte statisch okay. Für zehn und mehr plus Cloud: BGP als Standard.
• Frage: Wieviele Tunnel aufbauen? Antwort: Mindestens zwei pro Standort zu unterschiedlichen Peers/Regionen für Ausfallsicherheit und Wartbarkeit.
• Frage: Wie Auditor überzeugen? Antwort: Kryptopolitik, Segmentierung, Logs und Rotation dokumentieren. Bei routenbasiert Zugriffskontrolle an Interfaces zeigen.