High Availability für VPN: Active/Active vs. Active/Standby richtig planen

High Availability für VPN ist im Enterprise längst kein „Nice-to-have“ mehr, sondern eine Grundvoraussetzung für produktive Standortvernetzung, Hybrid-Cloud-Anbindungen und Remote-Access. Sobald kritische Applikationen, VoIP/Video, Produktionssysteme oder zentrale Security-Services über VPN-Pfade laufen, wirken sich selbst kurze Unterbrechungen direkt auf Umsatz, Betrieb und Sicherheit aus. Genau deshalb ist die Frage „Active/Active vs. Active/Standby“ keine reine Geschmacksfrage, sondern eine Architekturentscheidung mit Konsequenzen für Routing, Session-Stabilität, Kapazität, Monitoring und Change-Management. In der Praxis scheitert VPN-Hochverfügbarkeit selten an der Anzahl der Geräte, sondern an unklaren Failover-Signalen, asymmetrischen Pfaden, fehlender Zustandsübernahme, falschen Timern oder einem Design, das im Labor gut aussieht, aber unter Last oder bei Teilstörungen kippt. Dieser Artikel zeigt, wie Sie Active/Active und Active/Standby für VPN richtig planen, welche Vor- und Nachteile wirklich zählen und wie Sie Ausfälle so beherrschen, dass Nutzer und Anwendungen sie möglichst gar nicht bemerken.

Was bedeutet High Availability bei VPN wirklich?

Im Kontext von VPN (Site-to-Site und Remote-Access) bedeutet High Availability mehr als „zwei Gateways“. Hochverfügbarkeit umfasst die gesamte Kette aus Datenebene (Traffic), Kontroll-/Signalisierungsebene (IKE/TLS, Authentisierung, Rekey), Routing (BGP/OSPF/Static), Namensauflösung (DNS), Policy-Durchsetzung (Firewall/ACL), Telemetrie (Logs/Metriken) und Abhängigkeiten (IdP, MFA, Zertifikatsdienste). Ein VPN kann „up“ sein und trotzdem funktionieren kritische Anwendungen nicht, wenn beispielsweise Routing nicht konsistent umschaltet oder MTU/PMTUD nach dem Failover bricht.

• RTO (Recovery Time Objective): Wie schnell muss der Service wieder verfügbar sein?
• RPO (Recovery Point Objective): Bei VPN oft weniger relevant, aber wichtig für Logs/State (z. B. Audit-Trails).
• Failover-Typen: Device-Failover, Link-Failover, Pfad-Failover, Region-Failover, Control-Plane-Failover.
• Service-Definition: „Tunnel up“ ist kein Service. Service ist z. B. „SAP erreichbar“, „VoIP stabil“, „Admin-Zugriff möglich“.

Active/Standby: Prinzip, Stärken und typische Fallstricke

Active/Standby bedeutet: Ein Gateway (oder Cluster-Knoten) verarbeitet produktiven Traffic, ein zweiter steht bereit und übernimmt bei Störung. Dieses Modell ist beliebt, weil es konzeptionell einfach wirkt und Statefulness (z. B. NAT/Firewall-States, VPN-SAs) oft leichter konsistent gehalten werden kann. In der Praxis hängt der Erfolg davon ab, wie „Standby“ implementiert ist: heißer Standby mit kontinuierlicher Zustandsreplikation oder kalter Standby mit Neustart/Neuaufbau von Sessions.

Wann Active/Standby sinnvoll ist

• Stateful Inspections im Pfad: Wenn Firewall/NAT-Zustände kritisch sind und nicht sauber geteilt werden können.
• Klare Primary/Secondary-Anforderungen: Wenn ein eindeutiger Primärpfad gewünscht ist (z. B. Compliance, forensische Nachvollziehbarkeit).
• Begrenzte Standortgröße: Wenn Skalierung über „mehr Gateways“ nicht notwendig ist, aber schnelle Wiederherstellung gefordert ist.
• Einfaches Betriebsmodell: Weniger Komplexität im Routing und bei Fehlersuche.

Die häufigsten Fehler bei Active/Standby

• Failover nur auf Device-Down: Der Klassiker: Gateway lebt, aber Uplink oder Routing ist kaputt. Ergebnis: „Active“ bleibt aktiv, Traffic blackholed.
• Zu aggressive Timer: DPD/Keepalive/Health-Checks lösen Flapping aus, besonders bei kurzen Paketverlustphasen.
• Kein sauberer State-Transfer: Nach Failover müssen IKE/TLS-Sessions neu aufgebaut werden; das kann Sekunden bis Minuten dauern und Anwendungen brechen.
• Split Brain: Beide Knoten werden aktiv (z. B. bei Cluster-Link-Ausfall). Das führt zu IP-Konflikten, doppelten Routen oder inkonsistenten SAs.

Active/Active: Prinzip, Vorteile und neue Anforderungen

Active/Active bedeutet: Mehrere Gateways sind gleichzeitig produktiv und teilen sich Last oder Zuständigkeit. Das kann über ECMP, Anycast, Load Balancer oder gezielte Policy-Verteilung geschehen. Der große Vorteil ist die bessere Ressourcennutzung und die Möglichkeit, Kapazität horizontal zu skalieren. Gleichzeitig steigt die Komplexität: Routing muss deterministisch sein, Zustände müssen konsistent behandelt werden, und die Observability muss so gut sein, dass Teilfehler schnell erkannt werden.

Wann Active/Active besonders stark ist

• Skalierung von Durchsatz und Sessions: Viele Standorte, viele Remote-User, hohe PPS-Last, mehrere Regionen.
• Geografische Nähe zum Nutzer: Gateways in mehreren Regionen senken Latenz und verbessern Stabilität.
• DDoS-Resilienz: Last kann verteilt werden, Angriffe treffen nicht nur einen Endpunkt.
• Wartungsfenster ohne Downtime: Knoten können nacheinander entlastet und aktualisiert werden.

Die typischen Risiken bei Active/Active

• Asymmetrische Pfade: Hinweg über Gateway A, Rückweg über Gateway B. Das bricht stateful Firewalls/NAT und erschwert Troubleshooting.
• Uneinheitliche Policies: Schon kleine Drift in Kryptoprofilen, MTU/MSS oder ACLs führt zu „nur manchmal“-Fehlern.
• Ungleichmäßige Lastverteilung: ECMP kann bei wenigen Flows schief verteilen; einzelne Knoten werden heiß, andere langweilen sich.
• Session-Pinning fehlt: Besonders bei Remote-Access über Load Balancer: Wenn Sessions nicht „sticky“ sind, reißen Verbindungen.

Die zentrale Designfrage: Welche Verfügbarkeitsziele brauchen Sie wirklich?

Die Wahl zwischen Active/Active und Active/Standby sollte aus den Verfügbarkeits- und Betriebszielen abgeleitet werden. Ein paar Leitfragen helfen, die Entscheidung zu objektivieren:

• Wie kritisch ist die Unterbrechung? VoIP/VDI reagieren anders als Batch-Jobs oder Dateisynchronisation.
• Wie viele gleichzeitige Sessions? Remote-Access skaliert anders als Site-to-Site.
• Wie stateful ist der Pfad? NAT, Stateful-Firewalls, IDS/IPS, DLP-Inspection verändern die HA-Anforderungen.
• Wie stark ist Ihr Routing-Team? Active/Active ist ein Routing- und Observability-Thema, nicht nur ein „VPN-Feature“.
• Welche Fehlermodelle sind realistisch? Link-Degradation, Partial Outage, Control-Plane-Fehler, Cloud-Region-Events.

Failover-Signale richtig wählen: Device, Link, Routing und Service-Health

Ein robustes HA-Design erkennt nicht nur Totalausfälle, sondern auch Teilstörungen. Dafür müssen Health-Checks die richtigen Signale auswerten. Ein Ping auf ein Gateway-Interface reicht selten.

Empfohlene Health-Check-Ebenen

• Interface/Link: Uplink-Status, Carrier, Fehlerzähler, Paketverlust.
• Control Plane: IKE/TLS-Handshake möglich, Rekey erfolgreich, Zertifikatsprüfung ok.
• Routing Plane: BGP/OSPF-Nachbarschaften stabil, Prefix-Counts plausibel, keine Route Leaks.
• Data Plane (Service): Synthetische Tests zu realen Zielen (DNS, Applikationsport, HTTP-Check), nicht nur ICMP.

Gerade im Site-to-Site-Bereich ist dynamisches Routing ein HA-Verstärker: Wenn BGP-Sessions weg sind oder Prefixes zurückgezogen werden, kann der Traffic sauber umschwenken. Hintergrund zu BGP liefert die BGP-Spezifikation RFC 4271.

Routing-Design für HA: ECMP, BGP-Preferenzen und Blackhole-Vermeidung

Routing entscheidet, ob HA in der Praxis funktioniert. Viele VPN-Ausfälle sind Routing-Ausfälle: Der Tunnel steht, aber die Route ist falsch, oder die Route bleibt aktiv, obwohl der Pfad kaputt ist. Deshalb muss Routing-Design bewusst mit HA-Mechanismen gekoppelt werden.

Active/Standby mit Routing

• Primary/Secondary via BGP: Local Preference, MED oder AS-Path-Prepending steuern den bevorzugten Hub.
• Tracking: Route-Advertisement wird an Link- oder Service-Health gekoppelt (wenn Uplink kaputt, dann Prefix withdraw).
• Statische Routen mit Tracking: Nur sinnvoll, wenn Tracking wirklich zuverlässig ist; sonst bleibt Blackholing ein Risiko.

Active/Active mit ECMP

• ECMP bewusst aktivieren: Gleichgewichtete Pfade nur dann, wenn Statefulness gelöst ist (z. B. stateless Inspection oder konsistentes Session-Pinning).
• Symmetrie sicherstellen: Gleiche Pfadwahl hin und zurück, idealerweise durch konsistente Routing-Policies und klare Boundaries.
• Failure Domains definieren: Ein Knoten, ein Uplink, eine Region, ein Provider. ECMP darf nicht ungewollt über gemeinsame Single Points laufen.

Statefulness: VPN-SAs, NAT, Firewall-States und warum sie HA komplizieren

Der Kernunterschied zwischen „Failover klappt“ und „Failover sieht gut aus, aber Nutzer fluchen“ ist häufig Statefulness. VPNs erzeugen Zustände: Security Associations (SAs), Rekey-Timer, Session-Keys. Zusätzlich können im Pfad weitere stateful Komponenten hängen, etwa NAT oder Firewalls. Je mehr State, desto wichtiger ist entweder State-Synchronisation oder ein Design, das State-Probleme minimiert.

Was passiert bei Failover ohne State-Transfer?

• Neuaufbau von Tunnels: IKE/TLS muss neu handeln, Keys werden neu abgeleitet, SAs entstehen neu.
• Kurze Unterbrechung bis länger: Von „kaum merkbar“ bis „VPN ist weg“, abhängig von Timern, Client-Verhalten und Auth-Backends.
• Applikationsabbrüche: TCP-Verbindungen reißen, Echtzeitverkehr leidet, File-Transfers starten neu.

Praktische Strategien gegen State-Probleme

• State-Synchronisation nutzen: Wenn die Plattform es zuverlässig bietet (NAT/Firewall/VPN-States).
• Failover-Fenster verkürzen: Optimierte Health-Checks, aber ohne Flapping zu provozieren.
• State reduzieren: Weniger NAT im Pfad, klare Segmentierung, möglichst stateless Inspection für bestimmte Verkehre.
• Session-Pinning: Für Remote-Access über Load Balancer: gleiche Session bleibt auf dem gleichen Knoten.

Remote-Access vs. Site-to-Site: HA ist nicht identisch

Remote-Access und Site-to-Site haben unterschiedliche HA-Schmerzpunkte. Site-to-Site ist häufig „dauerhaft“ und stark routinggetrieben. Remote-Access ist sessionlastig, identitätsgetrieben (MFA/SSO) und stark von Clientverhalten abhängig.

Site-to-Site HA: Fokus auf Routing und Pfadkontrolle

• Mehrere Tunnels pro Peer: Zwei Hubs oder zwei Gateways pro Hub, idealerweise über getrennte Provider.
• Dynamisches Routing: BGP über den Tunnel, Prefix-Filtern, Withdraw bei Health-Failure.
• MTU/MSS stabil halten: Failover darf nicht plötzlich Fragmentation erzeugen.

Remote-Access HA: Fokus auf Sessions, Auth und User Experience

• Load Balancing: Anycast oder L7/L4-LB mit Stickiness, je nach VPN-Technologie.
• Auth-Abhängigkeiten redundant: Identity Provider, MFA, Zertifikatsvalidierung müssen hochverfügbar sein.
• Graceful Maintenance: Drain von Sessions, bevor ein Knoten gewartet wird, um Abbrüche zu minimieren.

Für Zero-Trust-orientierte Zugriffsmodelle ist es sinnvoll, Remote-Access-Designs an den Prinzipien von NIST SP 800-207 auszurichten, weil dort kontinuierliche Verifikation, minimale Reichweite und Policy-Entscheidungen im Kontext klar beschrieben sind.

Design Patterns für hohe VPN-Verfügbarkeit

Die folgenden Muster haben sich in der Praxis bewährt, weil sie Fehlerdomänen klar halten und Betriebsaufwand planbar machen.

Dual-Hub-Pattern (häufigster Enterprise-Standard)

• Beschreibung: Jeder Standort baut zu zwei Hubs Tunnels auf (z. B. DC1 und DC2 oder Region A und Region B).
• Vorteil: Schutz gegen Hub-Ausfall und gegen Wartungsfenster.
• Wichtig: Routing-Preferenzen, Symmetrie, und eindeutige Failure Signals (Withdraw bei Service-Failure).

Active/Active Gateways mit ECMP (für Skalierung und Wartbarkeit)

• Beschreibung: Mehrere Gateways sind parallel aktiv, Traffic verteilt sich über ECMP oder definierte Hashes.
• Vorteil: Kapazität steigt linear, Wartung ohne Downtime möglich.
• Wichtig: Umgang mit Statefulness, gleichartige Policies, starke Observability.

Active/Standby Cluster mit State Sync (für stateful Pfade)

• Beschreibung: Ein aktiver Knoten, ein Standby, Zustände werden repliziert.
• Vorteil: Sehr konsistente Session-Fortsetzung möglich, wenn der Hersteller das sauber implementiert.
• Wichtig: Split-Brain-Schutz, zuverlässiger Cluster-Link, getestete Failover-Matrix.

MTU, PMTUD und „verdeckte“ HA-Probleme

Failover kann scheinbar erfolgreich sein, aber danach „fühlen sich Anwendungen kaputt an“. Häufig steckt MTU/PMTUD dahinter: Der neue Pfad hat eine andere effektive MTU (z. B. anderer Provider, anderes Underlay, zusätzliche Encapsulation). Wenn ICMP für PMTUD blockiert wird, entstehen fragmentierte oder gedroppte Pakete, die vor allem große Transfers, TLS-Handshakes oder bestimmte Applikationsprotokolle treffen.

• Standard-MTU definieren: Pro Overlay eine Ziel-MTU festlegen und auf allen Gateways konsistent halten.
• MSS-Clamping für TCP: Verhindert oversized Segmente nach Encapsulation.
• ICMP nicht blind blocken: PMTUD benötigt bestimmte ICMP-Meldungen, sonst wird Troubleshooting zur Lotterie.
• Vorher testen: Failover-Tests mit großen Paketen und realen Anwendungen, nicht nur Ping.

Observability und Tests: HA ist nur so gut wie Ihre Nachweise

Hochverfügbarkeit muss messbar sein. Ohne Telemetrie und regelmäßige Failover-Tests bleibt HA ein Hoffnungskonzept. Gute Praxis ist, Failover nicht nur „einmal im Jahr“ zu testen, sondern als wiederkehrenden Prozess zu etablieren.

Messpunkte, die Sie zwingend brauchen

• Tunnel- und Rekey-Metriken: SA-Anzahl, Rekey-Fehler, Handshake-Zeiten, DPD-Timeouts.
• Routing-Metriken: BGP-Session State, Prefix-Counts, Withdraw/Announce Events, Flap-Raten.
• Service-Synthetics: DNS-Resolution, TCP-Connect zu Applikationsports, HTTP-Checks, RDP/SSH-Handshake (wo relevant).
• End-to-End KPIs: Latenz, Jitter, Paketverlust, Applikationsfehlerquoten während Failover.

Failover-Testmatrix (praxisnah)

• Planned Failover: Knoten drainen, Traffic umschalten, Wartung durchführen, zurückschwenken.
• Unplanned Failover: Power-Off eines Gateways, Uplink-Down, Routing-Blackhole-Simulation.
• Partial Failures: Paketverlust, DNS-Ausfall, IdP/MFA-Störung, Zertifikatsvalidierung blockiert.
• Lasttest unter Failover: Gleichzeitige Rekeys, viele Sessions, großer Durchsatz, um Worst-Case abzudecken.

Planungsleitfaden: Active/Active vs. Active/Standby richtig entscheiden

Wenn Sie eine robuste Entscheidung treffen möchten, können Sie beide Modelle gegen die wichtigsten Praxisdimensionen spiegeln:

• Komplexität: Active/Standby ist meist einfacher, Active/Active erfordert sauberes Routing- und State-Design.
• Skalierung: Active/Active skaliert besser horizontal; Active/Standby skaliert oft über „größere Kisten“ oder zusätzliche Cluster.
• Session-Stabilität: Active/Standby mit gutem State Sync kann sehr stabil sein; Active/Active braucht Symmetrie und Session-Pinning.
• Betrieb und Wartung: Active/Active erleichtert Rolling Updates, sofern Observability und Policies konsistent sind.
• Kosten/Nutzung: Active/Standby lässt Ressourcen ungenutzt; Active/Active nutzt Kapazität effektiver, kann aber höhere Betriebsaufwände verursachen.

Checkliste für ein HA-fähiges VPN-Design

• Service klar definiert: Welche Anwendungen müssen im Failover-Fall weiterlaufen, mit welchen RTO-Zielen?
• Failure Domains modelliert: Gateway, Uplink, Provider, Region, Auth-Backends, DNS, Logging.
• Health-Checks mehrschichtig: Link, Control Plane, Routing, Data Plane (echte Service-Checks).
• Routing ist HA-integriert: Preferenzen, ECMP-Regeln, Withdraw bei Failure, Prefix-Filter gegen Leaks.
• Statefulness bewusst gelöst: State Sync oder Design, das Asymmetrie und NAT-Fallen minimiert.
• MTU/MSS standardisiert: Failover darf nicht zu Fragmentation oder PMTUD-Problemen führen.
• Observability vorhanden: Metriken, Logs, synthetische Tests, Alarme mit klaren Runbooks.
• Failover regelmäßig getestet: Geplante und ungeplante Szenarien, inklusive Last und Partial Failures.
• Change- und Wartungsprozesse definiert: Drain/Undrain, Canary-Updates, Rollback-Strategien.

Wer diese Punkte konsequent umsetzt, plant High Availability für VPN nicht als „Feature am Gateway“, sondern als belastbares System aus Routing, Zuständen, Abhängigkeiten und überprüfbaren Betriebsprozessen. Die technischen Grundlagen der Schutzarchitektur finden sich beispielsweise in der IPsec-Architektur (RFC 4301), während Zero-Trust-Prinzipien und kontinuierliche Verifikation durch NIST SP 800-207 gut strukturiert werden.

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.