Firewall-HA (High Availability): Active/Passive vs. Active/Active

Red Snapper

1 month ago

Firewall-HA (High Availability) ist für Unternehmen heute kein „Nice to have“, sondern eine zentrale Voraussetzung für stabile, sichere Netzwerke. Firewalls stehen oft im kritischen Pfad: Internet-Uplink, VPN-Remote-Access, Standortvernetzung, Zonenübergänge, DMZ, Cloud-Anbindungen. Fällt eine Firewall aus – sei es durch Hardwaredefekt, Softwarebug, Stromproblem, falsches Update oder Überlast – können ganze Geschäftsprozesse stillstehen. High Availability reduziert dieses Risiko, indem mindestens zwei Firewalls als Verbund betrieben werden, sodass bei Störungen ein Failover stattfindet oder die Last auf mehrere Geräte verteilt wird. In der Praxis begegnen Ihnen dabei vor allem zwei Modelle: Active/Passive und Active/Active. Beide verfolgen das gleiche Ziel (Ausfallresistenz), unterscheiden sich aber deutlich in Komplexität, Verhalten bei Fehlern, Performance, Session-Handling und Anforderungen an das umliegende Netzwerk. Dieser Artikel erklärt die Grundlagen von Firewall-HA, stellt Active/Passive und Active/Active verständlich gegenüber und zeigt, welche Fragen Sie vor der Entscheidung klären sollten, damit HA nicht nur „auf dem Papier“ existiert, sondern im Ernstfall wirklich funktioniert.

Was bedeutet Firewall-HA in der Praxis?

Firewall-HA beschreibt einen Betriebsmodus, bei dem zwei oder mehr Firewalls gemeinsam arbeiten, um Verfügbarkeit und Betriebssicherheit zu erhöhen. Typische Ziele sind:

Minimierung von Downtime: Bei Ausfall eines Geräts übernimmt ein Partnergerät automatisch.
Reduzierung von Wartungsrisiken: Updates können geplant und mit geringeren Unterbrechungen durchgeführt werden.
Schutz vor Single Point of Failure: Nicht nur die Hardware, sondern auch Software- und Prozessfehler werden abgefedert.
Stabilere Security Controls: Sicherheitsregeln und Policies bleiben verfügbar (z. B. Remote Work, VPN).

Wichtig ist: HA ersetzt keine gute Netzwerkarchitektur. Wenn Switches, Router, Stromversorgung oder Uplinks weiterhin Single Points of Failure sind, kann eine HA-Firewall nur einen Teil des Risikos reduzieren.

Die Bausteine von Firewall-High-Availability

Unabhängig vom Hersteller haben HA-Setups meist ähnliche technische Bausteine. Wer diese versteht, kann Designs besser planen und Failover-Verhalten realistischer einschätzen.

HA-Peer: Zweites Firewall-Gerät (oder mehrere), das im Verbund arbeitet.
HA-Link/Heartbeat: Kommunikationspfad zwischen den Firewalls zur Gesundheitsprüfung und Koordination.
State/Session Sync: Synchronisation von Zuständen (Sessions, NAT-States, ggf. VPN-States), damit Failover nicht zu Verbindungsabbrüchen führt.
Config Sync: Abgleich der Konfiguration, damit Regeln, Objekte und Policies konsistent bleiben.
Failover-Mechanismus: Entscheidung, wann gewechselt wird (z. B. Link down, Device health, Service health, manuelles Switchover).
Redundante Datenpfade: Doppelte Switches, redundante Interfaces, ggf. Link Aggregation, um „HA nur auf dem Gerät“ zu vermeiden.

Active/Passive: Prinzip, Vorteile und typische Einsatzfelder

Beim Active/Passive-Design verarbeitet eine Firewall den produktiven Traffic (Active), während die zweite Firewall bereitsteht (Passive). Die passive Einheit übernimmt im Fehlerfall, idealerweise mit synchronisierten States, sodass bestehende Verbindungen möglichst erhalten bleiben.

Wie Active/Passive technisch funktioniert

Ein Gerät ist führend: Die aktive Firewall hält virtuelle IPs/MACs (je nach Herstellerkonzept) und ist Datenpfad-Anker.
Der Passive Peer ist „hot standby“: Er ist betriebsbereit, synchronisiert Konfiguration und – wenn aktiviert – Session-/State-Informationen.
Failover bei Ereignis: Bei Device-/Link-/Service-Failure übernimmt der Passive, nimmt die relevanten Identitäten an (z. B. virtuelle MAC) und führt Sessions fort, soweit State Sync reicht.

Vorteile von Active/Passive

Einfacheres Design: Weniger komplexe Traffic-Verteilung, klarer Datenpfad.
Vorhersehbares Verhalten: Eine Einheit entscheidet, Policies sind konsistent angewendet.
Geringeres Risiko von Asymmetrie: Asymmetrische Routingpfade sind leichter zu vermeiden.
Einfacheres Troubleshooting: Fehleranalyse konzentriert sich auf den aktiven Datenpfad.

Nachteile und typische Stolpersteine

Ressourcen „ungenutzt“: Die passive Einheit trägt im Normalbetrieb kaum zur Performance bei.
Failover ist nie „magisch“: Ohne sauberen State Sync brechen Sessions ab (besonders bei langen TCP-Sessions).
Update-Risiko bleibt relevant: Wenn beide Geräte identisch sind und das Update einen Bug hat, kann auch der Peer betroffen sein.
Single Points außerhalb der Firewall: Ein einzelner Switch oder ein einzelner Uplink kann trotzdem alles lahmlegen.

Active/Active: Prinzip, Vorteile und typische Einsatzfelder

Beim Active/Active-Design sind mehrere Firewalls gleichzeitig aktiv und verarbeiten produktiven Traffic. Ziel ist häufig, sowohl Verfügbarkeit als auch bessere Ressourcenauslastung oder Skalierung zu erreichen. Active/Active ist jedoch deutlich anspruchsvoller, weil Traffic verteilt, Sessions konsistent gehalten und Asymmetrien vermieden werden müssen.

Wie Active/Active technisch funktioniert

Beide Geräte forwarden: Traffic wird nach bestimmten Kriterien verteilt (z. B. per ECMP, Cluster-Mechanismen, Load Balancing oder Hersteller-spezifischem Clustering).
Session Ownership: Eine Session „gehört“ meist einem Knoten; bei manchen Designs wird State zwischen Knoten geteilt, bei anderen nicht vollständig.
Failover pro Flow oder pro Knoten: Bei Ausfall übernimmt der verbleibende Knoten entweder alle Sessions oder nur bestimmte Traffic-Anteile – abhängig vom Cluster-Design.

Vorteile von Active/Active

Bessere Auslastung: Rechenleistung beider Geräte wird genutzt, was bei hohen Durchsätzen attraktiv ist.
Potenzial für Skalierung: Je nach Lösung können mehr als zwei Knoten betrieben werden (Cluster).
Redundanz auch bei Lastspitzen: Wenn ein Knoten ausfällt, bleibt zumindest ein Teil der Kapazität erhalten.

Nachteile und typische Stolpersteine

Höhere Komplexität: Traffic-Verteilung, Routing-Design und Session-Handling sind anspruchsvoller.
Asymmetrisches Routing: Wenn Hin- und Rückweg über unterschiedliche Knoten laufen, können Stateful Policies Probleme verursachen.
State Sync ist kritischer: Nicht jede Plattform kann alle Zustände in Active/Active gleich gut synchronisieren.
Fehlerdiagnose schwieriger: Ein Problem zeigt sich möglicherweise nur auf einem Knoten oder nur bei bestimmten Flows.

Active/Passive vs. Active/Active: Die wichtigsten Unterschiede auf einen Blick

Komplexität: Active/Passive meist einfacher, Active/Active erfordert mehr Design-Disziplin.
Auslastung: Active/Passive nutzt primär ein Gerät, Active/Active nutzt mehrere gleichzeitig.
Failover-Charakter: Active/Passive hat klaren Rollenwechsel; Active/Active kann Flow- oder Knoten-spezifisch umschalten.
Session-Verhalten: Active/Passive mit State Sync häufig stabiler; Active/Active hängt stark von Cluster-Mechanik ab.
Routing-Anforderungen: Active/Active ist empfindlicher gegenüber asymmetrischen Pfaden.
Betrieb/Fehlersuche: Active/Passive meist leichter; Active/Active erfordert mehr Monitoring und klare Baselines.

Session Sync: Warum HA ohne State-Übernahme oft enttäuscht

Viele erwarten, dass HA „keine Unterbrechung“ bedeutet. In der Realität hängt das stark davon ab, welche Zustände synchronisiert werden. Für typische Unternehmensanwendungen sind vor allem TCP-Sessions und NAT-States relevant. Fehlt diese Synchronisation oder ist sie unvollständig, passieren bei Failover oft:

TCP-Resets oder Timeouts: Clients müssen neu verbinden, was Anwendungen spürbar unterbricht.
NAT-Probleme: Ohne NAT-State kennt der neue Knoten die Übersetzung nicht, Rückverkehr passt nicht.
VPN-Unterbrechungen: Je nach VPN-Technologie und Hersteller kann Failover entweder transparent sein oder einen Reconnect erzwingen.

Praxisregel: Für geschäftskritische Pfade sollte „Stateful Failover“ explizit geplant, getestet und beobachtet werden – nicht nur „auf dem Datenblatt“ stehen.

Asymmetrisches Routing: Der häufigste Designfehler bei Active/Active

Stateful Firewalls erwarten typischerweise, dass Hin- und Rückverkehr einer Session über denselben Knoten laufen. In Active/Active-Designs kann das brechen, wenn das Netzwerk den Rückweg anders routet (ECMP, dynamische Routingänderungen, unterschiedliche Default-Gateways). Das führt zu Problemen wie:

Session Drops: Ein Knoten sieht nur die Hälfte der Session und verwirft Pakete.
Unklare Fehlerbilder: Manche Verbindungen funktionieren, andere nicht – abhängig vom Hashing/Path.
Schwierige Fehlersuche: Logs verteilen sich, und Fehler wirken sporadisch.

Wenn Sie Active/Active planen, ist ein konsistentes Routing- und Hashing-Design entscheidend: Symmetrie erzwingen oder ein Cluster-Verfahren nutzen, das asymmetrische Pfade abfangen kann.

NAT, VIPs und ARP: Was beim Failover wirklich passiert

Viele HA-Probleme sind nicht „Firewall-intern“, sondern entstehen durch Layer-2/Layer-3-Mechanismen: ARP-Cache, MAC-Learning, virtuelle IPs, Routing-Neighbor-States. Damit Failover schnell ist, müssen diese Aspekte sauber geplant sein.

Gratuitous ARP: Der neue aktive Knoten muss oft aktiv ARP-Updates senden, damit Switches/Hosts schnell umlernen.
MAC Move Events: Switches brauchen korrekte Einstellungen, damit MAC-Wechsel nicht als „Flapping“ blockiert werden.
Virtuelle IPs: Häufig wird mit VIP/Virtual MAC gearbeitet, damit sich für Nachbarsysteme „die Firewall“ nicht ändert.
NAT-Determinismus: In Active/Active kann NAT-Verhalten komplexer sein, wenn Sessions nicht eindeutig einem Knoten zugeordnet bleiben.

HA-Healthchecks: Link Down reicht nicht

Ein klassischer Fehler ist, Failover nur an „Link Down“ zu koppeln. Viele reale Probleme sind aber „Soft Failures“: CPU hängt, Control Plane spinnt, IPS-Prozess hängt, VPN-Dienst ist tot, aber Interfaces bleiben up. Gute HA-Setups nutzen deshalb zusätzliche Healthchecks.

Device Health: CPU/Memory, Prozesszustände, Plattform-Selftests.
Service Health: VPN-Daemon, Routing-Services, Content-Inspection/IPS, Auth-Integration.
Path Monitoring: Erreichbarkeit wichtiger Next-Hops (Upstream Router, Core, DNS, IdP).
Preemption-Strategie: Definieren, ob nach Recovery automatisch zurückgeschwenkt wird oder nicht.

Wartung und Updates: HA als Enabler für sichere Changes

Ein großer Vorteil von HA ist die Möglichkeit, Wartung kontrollierter durchzuführen. Allerdings nur, wenn Prozesse und Tests stimmen.

Geplanter Switchover: Vor Updates Failover bewusst auslösen, um Verhalten zu testen.
Rolling Upgrade: In Active/Passive erst Passive aktualisieren, dann switchover, dann den zweiten Knoten.
Validierung nach jedem Schritt: VPN-Login, kritische Applikationsflüsse, DNS, Routing, Logging.
Rollback-Plan: Image/Config-Backup und klare Kriterien, wann zurückgerollt wird.

Für praxisnahe Hinweise zu HA-Design und Failover-Tests sind Hersteller-Guides hilfreich, weil sie konkrete Implementierungsdetails enthalten, z. B. Palo Alto Networks Dokumentation, Fortinet Dokumentation oder Cisco Security Support/Docs.

Welche Architektur passt wann? Entscheidungskriterien aus der Praxis

Die Entscheidung Active/Passive vs. Active/Active hängt weniger von „gut oder schlecht“ ab, sondern von Anforderungen, Team-Reife und Umfeld.

Wann Active/Passive oft die bessere Wahl ist

Stabilität vor Maximalauslastung: Geschäftsprozesse sind kritisch, Änderungen sollen risikoarm bleiben.
Überschaubare Durchsatzanforderung: Ein Gerät kann den Normalbetrieb tragen, Failover ist der Hauptzweck.
Einfachere Netzwerktopologie: Weniger ECMP/Asymmetrie, klarer Datenpfad, weniger „moving parts“.
Kleineres Team oder weniger Betriebskapazität: Troubleshooting soll schnell und eindeutig sein.

Wann Active/Active sinnvoll sein kann

Sehr hoher Durchsatz: Ein einzelnes Gerät wäre zu teuer oder zu knapp dimensioniert.
Viele parallele Sessions: Große Umgebungen mit vielen Usern, IoT oder massivem Ost-West-Verkehr.
Reife in Betrieb und Monitoring: Team kann Komplexität managen, Baselines und Tools sind vorhanden.
Passende Cluster-Technik: Hersteller/Plattform bietet robuste Active/Active-Mechanismen, die zum Routingdesign passen.

Typische HA-Fallen und wie Sie sie vermeiden

HA nur auf der Firewall, nicht im Netz: Redundante Switches, Uplinks und Strom fehlen – Failover bringt wenig.
State Sync nicht getestet: Failover erfolgt, aber Sessions brechen – Business merkt es sofort.
Asymmetrisches Routing ignoriert: Besonders bei Active/Active entstehen sporadische Drops.
Healthchecks zu simpel: Link ist up, Dienst ist down – Failover passiert nicht.
Preemption falsch gesetzt: Ständiges Hin- und Herschwenken („flapping“) erzeugt Instabilität.
Logging/Monitoring nicht zentral: Im Incident fehlen die relevanten Daten (wer war aktiv? welche Sessions? welche Regeln?).
Kein Failover-Drill: HA wird nie real geübt, bis es „wirklich brennt“.

Failover-Tests: Das Minimum, das Sie regelmäßig üben sollten

HA muss im Betrieb verifiziert werden, sonst bleibt es eine Annahme. Sinnvoll ist ein wiederkehrender Testplan (z. B. quartalsweise), der technisch und fachlich relevante Pfade prüft.

Geplanter Switchover: Manuell umschalten und prüfen, ob kritische Applikationen stabil bleiben.
Stateful Session Test: Lang laufende TCP-Verbindungen (z. B. Downloads, VPN, Datenbank-Connections) beobachten.
VPN-Continuity: Bleiben VPN-Sessions bestehen oder erfolgt Reconnect? Wie lange dauert es?
NAT/Inbound Services: DMZ-Dienste, Port-Forwarding, Reverse Proxy – funktionieren sie nach Failover?
Logging und Alarmierung: Wird Failover geloggt? Gibt es Alarme? Sind Zeitstempel korrekt?

Checkliste: So entscheiden und implementieren Sie Firewall-HA sauber

Sie haben definiert, was „hochverfügbar“ heißt: maximale Unterbrechungszeit, erlaubte Session-Drops, Wartungsziele.
Die Umgebung ist wirklich redundant: Switches, Uplinks, Strom, Routingpfade, nicht nur die Firewall-Hardware.
State/Session Sync ist aktiv geplant, passend dimensioniert und regelmäßig getestet.
Active/Active wird nur eingesetzt, wenn Routing-Symmetrie und Cluster-Mechanik sauber beherrscht werden.
Healthchecks prüfen nicht nur Link-Status, sondern auch relevante Dienste und Pfade.
Preemption/Failback-Verhalten ist bewusst gewählt, um Flapping zu vermeiden.
Updates laufen über standardisierte Rolling-Prozesse mit Smoke Tests und Rollback-Plan.
Monitoring/Logging ist zentral, damit Failover-Ereignisse und Nebenwirkungen sichtbar sind.

Weiterführende Informationsquellen

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.