Asymmetrisches Routing: Warum Sessions abbrechen und wie Sie es lösen

Red Snapper

1 month ago

Asymmetrisches Routing ist eine der häufigsten Ursachen, wenn Verbindungen „irgendwie“ funktionieren, aber Sessions abbrechen, Logins hängen bleiben oder Anwendungen nur sporadisch erreichbar sind. Besonders tückisch: Auf den ersten Blick wirkt das Netzwerk gesund. Ping zum Ziel kann klappen, DNS löst auf, und sogar einzelne Downloads starten – trotzdem brechen TCP-Verbindungen nach wenigen Sekunden ab, TLS-Handshakes hängen, VoIP-Rufe verlieren Audio oder VPN-Tunnel wirken instabil. Der Grund liegt oft nicht in Bandbreite oder Latenz, sondern im Pfad: Hinweg und Rückweg nehmen unterschiedliche Routen. Solange reine, stateless Weiterleitung im Spiel ist, kann asymmetrisches Routing manchmal unbemerkt bleiben. Sobald jedoch zustandsbehaftete Systeme beteiligt sind – Firewalls, NAT-Gateways, Load Balancer, Proxies, IDS/IPS oder SD-WAN-Appliances – wird Asymmetrie zum Problem. Diese Geräte erwarten, dass beide Richtungen einer Session durch dieselbe Instanz laufen (oder dass der Zustand synchronisiert wird). Passiert das nicht, werden Rückpakete als „out of state“ verworfen, NAT-Translations fehlen, und Sessions brechen ab. Dieser Artikel erklärt verständlich, warum Asymmetrie entsteht, wie Sie sie zuverlässig nachweisen und welche Lösungswege in der Praxis funktionieren – vom schnellen Fix bis zur nachhaltigen Design-Verbesserung.

Was ist asymmetrisches Routing und warum ist es so problematisch?

Von asymmetrischem Routing spricht man, wenn Pakete von A nach B über einen anderen Pfad laufen als die Antwortpakete von B nach A. Das kann innerhalb eines Standorts passieren (z. B. zwei Core-Switches, zwei Firewalls), zwischen Standorten (z. B. MPLS + Internet-VPN), oder bei Cloud-Anbindungen (z. B. zwei Interconnects). Grundsätzlich ist Routing richtungsunabhängig: Jeder Router trifft Entscheidungen aus seiner eigenen Sicht anhand seiner Routing-Tabelle. Daher ist Symmetrie nie garantiert – sie ist ein Ergebnis von konsistentem Design, konsistenten Policies und konsistenter Topologie.

Symmetrisch: A → … → Firewall 1 → … → B und B → … → Firewall 1 → … → A
Asymmetrisch: A → … → Firewall 1 → … → B, aber B → … → Firewall 2 → … → A

Problematisch wird das besonders bei TCP, weil eine Sessionzustandsmaschine erwartet, dass SYN/SYN-ACK/ACK und späterer Traffic zusammenpassen. TCP-Grundlagen sind in RFC 9293 (TCP) beschrieben. Auch NAT ist typischerweise zustandsbehaftet; Hintergrund liefert RFC 3022 (Traditional NAT).

Typische Symptome: So erkennen Sie asymmetrisches Routing im Betrieb

Asymmetrisches Routing hat wiederkehrende Symptome, die sich stark von „reiner“ Leitungsstörung unterscheiden. Besonders auffällig ist die Kombination aus scheinbar funktionierender Basis-Konnektivität und instabilen Sessions.

TCP-Verbindungen hängen im Aufbau: SYN geht raus, aber SYN-ACK kommt nicht sauber zurück oder wird verworfen.
„Out of state“ / „Invalid session“ Logs: Firewalls sehen Rückpakete ohne passenden State.
TLS/HTTPS-Probleme: Handshake hängt, Seiten laden teilweise, dann Timeout.
VoIP/Video: Einweg-Audio, abgehackte Medienströme, Sessions brechen nach kurzer Zeit ab (UDP-State/Timeouts).
VPN instabil: Tunnel steht, aber Datenverkehr ist unzuverlässig oder nur in eine Richtung möglich.
Nur einzelne Subnetze betroffen: meist durch Policy-Based Routing, statische Routen oder VRF/Route-Leaks.
„Mal geht’s, mal nicht“: typisch bei ECMP/Load-Balancing, wenn einer der Pfade über ein anderes Security-Gateway läuft.

Warum Sessions abbrechen: State, NAT und Load Balancer als „Asymmetrie-Detektoren“

Viele Netzwerkgeräte sind heute zustandsbehaftet. Das ist sinnvoll: Firewalls können Rückverkehr automatisch erlauben, NAT kann viele Clients über wenige Public IPs übersetzen, Load Balancer können Sessions an denselben Backend-Server binden. Genau diese Zustandslogik macht sie aber empfindlich gegenüber Asymmetrie.

Stateful Firewalls

Eine stateful Firewall merkt sich pro Flow (5-Tuple: Quelle, Ziel, Protokoll, Ports) den Zustand. Kommt ein Paket zurück, das nicht zu einer bekannten Session passt, wird es oft verworfen oder zurückgesetzt. In Logs steht dann je nach Hersteller „out of state“, „invalid“ oder „no session match“.

NAT-Gateways

NAT ist praktisch immer stateful: Für jede Verbindung wird eine Übersetzung (Inside Local → Inside Global, ggf. Port) angelegt. Wenn der Rückweg über ein anderes Gerät läuft, existiert dort keine passende NAT-Tabelle – Rückpakete können nicht korrekt zum Client zurückübersetzt werden.

Load Balancer und Session Persistence

Bei Load Balancern ist Symmetrie häufig notwendig, damit Rückantworten über dieselbe Instanz gehen oder damit Persistenz (Cookie/IP Hash) konsistent bleibt. Andernfalls landet der Rückweg an einem anderen Knoten, der die Session nicht kennt oder andere Backend-Zuordnungen trifft.

Hauptursachen: Wie asymmetrisches Routing typischerweise entsteht

Asymmetrie ist selten „Zufall“. Meist steckt ein konkreter Design- oder Konfigurationsgrund dahinter. Diese Ursachenklassen sollten Sie im Troubleshooting priorisieren.

Mehrere Egress-Pfade (Dual-WAN, SD-WAN, Internet + MPLS)

Ausgehender Traffic wird über WAN 1 geschickt, Rückweg kommt über WAN 2 (Provider-Policy, BGP-Attribute, SD-WAN-Policy).
Ein Standort sendet „bevorzugt“ über Internet, der andere antwortet über MPLS (oder umgekehrt).

Redundante Firewalls ohne saubere Kopplung

Active/Active-Setups ohne State-Synchronisierung oder ohne konsistente Hashing-Mechanik.
Active/Passive, aber Rückweg nimmt den „falschen“ Knoten wegen Routing oder ARP-Gateway-Design.

ECMP und ungleich verteilte Security-Gateways

Mehrere gleichwertige Routen (ECMP) verteilen Flows über verschiedene Pfade, die unterschiedliche Firewalls berühren.
Ein Pfad ist „sauber“, ein anderer führt über eine restriktivere Policy oder eine andere NAT-Regel.

Policy-Based Routing (PBR) oder anwendungsbasierte Policies

Nur bestimmter Traffic (z. B. SaaS, VoIP, Port 443) wird umgelenkt, aber Rückverkehr wird normal geroutet.
PBR nur inbound auf einem Interface aktiv – Rückrichtung bleibt unbeeinflusst.

Statische Routen und „Quick Fixes“

Ein Netz wird mit einer statischen Route umgeroutet, aber die Gegenstelle erhält keine passende Rückroute.
Floating Static wird aktiv, aber nur in eine Richtung, weil Tracking/Health Checks fehlen.

VRFs, Route Leaks und Segmentierung

Hinweg ist in VRF A, Rückweg in VRF B (oder Leak nur in eine Richtung).
Firewall-Zonen/VRFs führen zu unterschiedlichen Default Routes.

Der Nachweis: Wie Sie asymmetrisches Routing sicher belegen

Asymmetrie muss man beweisen, nicht vermuten. Das gelingt am zuverlässigsten, wenn Sie Hin- und Rückweg getrennt betrachten und mindestens an zwei Punkten messen: nahe der Quelle und nahe dem Ziel (oder an den Security-Gateways dazwischen).

Traceroute sinnvoll einsetzen

Traceroute ist ein guter Indikator, aber nicht immer identisch mit dem realen Datenpfad, weil ICMP/TTL-Handling und Firewalls die Ausgabe verfälschen können. Trotzdem ist es hilfreich, um zu sehen, wo der Pfad sich unterscheidet.

Traceroute von A nach B ausführen
Traceroute von B nach A ausführen
Pfadunterschiede dokumentieren (welche Hops sind anders?)

Session- und NAT-Tabellen nutzen

Auf Firewall/NAT-Gateway prüfen: Wird eine Session angelegt?
Kommt Rückverkehr dort an (Byte-Counter steigen) oder taucht er auf einem anderen Gerät auf?
Bei NAT: Existiert eine Translation und wird sie genutzt?

Logs mit Reason-Codes auswerten

„out of state“, „no session“, „asymmetric route“ (je nach Hersteller)
TCP RST von der Firewall (statt vom Ziel) als Hinweis auf stateful Block
IPS/Inspection kann asymmetrisch wirken, wenn nur eine Richtung inspeziert wird

Paketmitschnitt als Goldstandard

Wenn die Ursache nicht eindeutig ist, hilft ein Mitschnitt (z. B. SPAN/Mirror oder direkt auf der Firewall). Sie sehen dann, ob SYN rausgeht, wo SYN-ACK zurückkommt, und ob es verworfen wird. Als Einstieg ist die Wireshark-Dokumentation hilfreich.

Fall 1: SYN geht raus, SYN-ACK kommt nie zurück → Rückweg/Provider/Upstream
Fall 2: SYN-ACK kommt an, wird aber gedroppt → State/Policy/Asymmetrie im Security-Gateway
Fall 3: Handshake ok, aber Datenfluss bricht später ab → Idle-Timeout, NAT-Mapping, Inspection, MTU

Warum Ping oft täuscht: ICMP vs. TCP/UDP

Ein häufiger Irrtum: „Ping geht, also ist Routing ok.“ ICMP kann anders behandelt werden als TCP/UDP (separate Policies, Rate Limits, anderes NAT-Verhalten). Außerdem kann Ping zufällig über einen funktionierenden Pfad gehen, während TCP-Session-Hashing über einen anderen Pfad verteilt wird (ECMP). Deshalb sollten Sie immer auch echte Diensttests durchführen (z. B. TCP/443, TCP/22) und auf Session-States schauen.

Lösungsstrategien: So machen Sie den Pfad wieder symmetrisch

Die beste Lösung hängt von der Ursache ab. Ziel ist immer: Entweder Symmetrie erzwingen oder den Zustand so designen, dass Asymmetrie toleriert wird.

Symmetrie durch Routing-Design erzwingen

Konsistente Default Routes: In beiden Richtungen muss klar sein, welches Gateway zuständig ist.
BGP/OSPF-Policy sauber setzen: Local Preference/AS-Path/Costs so gestalten, dass Hin- und Rückweg konsistent bleiben.
ECMP bewusst einsetzen: Nur dann, wenn alle Pfade gleichwertig sind und dieselben Security-Services enthalten.

Traffic durch dasselbe Security-Gateway „pinne“

Stateful Clustering: Firewalls im Cluster/Stack/Chassis, so dass Sessions auf einer logischen Einheit bleiben.
Session Synchronization: Wenn Active/Active, dann State-Sync nutzen (und testen), damit Rückweg auch auf anderem Knoten akzeptiert wird.
Hashing/Persistence: Load Balancer und ECMP-Hash so konfigurieren, dass der gleiche Flow konsistent auf demselben Pfad bleibt.

PBR nur symmetrisch verwenden

PBR-Regeln in beiden Richtungen berücksichtigen (oder Return Traffic durch Design gleich mitführen).
PBR nur für klar definierte Subnetze/Services und mit sauberem Monitoring einsetzen.

Statische Routen sauber ergänzen (inkl. Rückrouten)

Bei statischen Routen immer den Rückweg planen: Route auf der Gegenstelle oder via Routingprotokoll.
Floating Statics mit Tracking kombinieren, damit Failover nicht zu halben Pfaden führt.

NAT- und Firewall-Design vereinheitlichen

NAT zentralisieren (ein Egress) oder NAT-Pools konsistent über Cluster bereitstellen.
Bei mehreren Egress-Gateways: klar trennen, welche Netze welchen Egress nutzen (keine Mischzustände).

Praxisfälle: Häufige Asymmetrie-Szenarien und schnelle Fixes

Dual-WAN mit SD-WAN: Web geht, aber einige Apps brechen ab

Wahrscheinlich: Bestimmte Apps werden per Policy über WAN 2 geroutet, Rückweg kommt über WAN 1 (oder umgekehrt).
Fix: Policy so anpassen, dass auch der Rückweg über denselben Tunnel/PoP läuft, oder stateful Services zentralisieren.

Redundante Firewalls: „Out of state“-Drops nach Failover

Wahrscheinlich: Failover ohne vollständige State-Synchronisierung oder asymmetrische Rückwege nach ARP/MAC-Wechsel.
Fix: State-Sync prüfen, HA-Design testen, Gateway/VRRP/HSRP-Design und ARP-Handling sauber machen.

ECMP im Core: Sporadische Timeouts in nur einem VLAN

Wahrscheinlich: ECMP verteilt Flows über zwei Pfade, aber nur einer führt durch die erwartete Firewall/Policy.
Fix: ECMP für diesen Traffic deaktivieren oder sicherstellen, dass beide Pfade identisch gesichert/übersetzt sind.

Statische Route als Quick Fix: VPN nur in eine Richtung

Wahrscheinlich: Hinweg über statische Route ins VPN, Rückweg über Default Route ins Internet.
Fix: Rückroute ergänzen oder Routingprotokoll/Route-Based VPN verwenden, so dass beide Richtungen konsistent sind.

Monitoring und Prävention: Asymmetrie früh erkennen

Asymmetrie ist oft ein wiederkehrendes Muster nach Changes. Mit gezieltem Monitoring können Sie sie früh sehen, bevor es zum Incident wird.

Firewall-Events: Alarme auf „out of state“, „invalid session“, ungewöhnliche RST-Raten
NAT-Health: Translation-Counts und Drops, Port-Exhaustion, ungewöhnliche Miss-Matches
Routing-Drift: Änderungen in Default Routes, LocalPref, OSPF-Cost, ECMP-Next-Hops
Flow-Monitoring: NetFlow/sFlow/Telemetry, um Hin- und Rückpfade zu korrelieren
Change-Checks: Nach WAN/Firewall/BGP/OSPF-Änderungen standardisierte Pfadtests in beide Richtungen

Outbound-Links zur Vertiefung

Checkliste: Asymmetrisches Routing finden und beheben

Symptom klassifizieren: Sessionaufbau hängt, „out of state“, nur bestimmte Ziele/Ports, sporadisch?
Hin- und Rückweg prüfen: Traceroute in beide Richtungen, Pfadunterschiede dokumentieren.
Security-Gateways prüfen: Session-Table/NAT-Table – wird State auf dem erwarteten Gerät aufgebaut?
Logs auswerten: „out of state“, „invalid session“, RSTs, Drops, Policy-Reasons.
ECMP/PBR/SD-WAN prüfen: Übersteuern Policies die Routing-Tabelle nur in eine Richtung?
Rückrouten prüfen: Existiert eine saubere Route zurück (besonders bei statischen Routen und VPNs)?
Symmetrie herstellen: Routing-Policies konsistent, ECMP nur mit identischen Pfaden, NAT/Firewall zentral oder state-synced.
Fix verifizieren: Identischer Testfall vor/nach Änderung (TCP/443 oder betroffener Dienst), Sessions stabil, keine out-of-state Drops.
Prävention: Monitoring auf out-of-state, Change-Runbooks, regelmäßige Pfadtests in beide Richtungen.

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.