9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking

Bei asymmetrischem Routing verwenden Hin- und Rückverkehr einer Kommunikation unterschiedliche Netzwerkpfade. Für gewöhnliche Router ist das nicht grundsätzlich fehlerhaft: Jeder Router entscheidet für jedes Paket anhand seiner eigenen Routingtabelle. Zustandsbehaftete Firewalls, NAT-Gateways, Load Balancer und andere Stateful-Systeme müssen jedoch zusammengehörige Pakete einer gespeicherten Sitzung zuordnen können.

Erreicht der Verbindungsaufbau eine Firewall, der Rückverkehr aber eine andere Firewall ohne synchronisierten Sitzungszustand, kann das Antwortpaket als unbekannt oder ungültig verworfen werden. Eine vorhandene Freigaberegel löst dieses Problem nicht, weil nicht die Regel, sondern der fehlende Sitzungszustand die Ursache ist.

Ziele

Nach der Bearbeitung dieser Seite soll nachvollziehbar geprüft werden können:

Sicherheits- und Änderungsgrundsätze

Sessiontabellen und Connection Tracking enthalten den aktuellen Zustand produktiver Verbindungen. Unkontrollierte Eingriffe können gleichzeitig unterbrechen:

Nicht als erste Diagnosemaßnahme geeignet sind:

Vor einer Änderung sind mindestens zu dokumentieren:

Symmetrischen und asymmetrischen Pfad unterscheiden

Symmetrischer Pfad:

Hinweg:
Client -> Router A -> Firewall A -> Router B -> Server

Rückweg:
Server -> Router B -> Firewall A -> Router A -> Client

Asymmetrischer Pfad:

Hinweg:
Client -> Router A -> Firewall A -> Router B -> Server

Rückweg:
Server -> Router C -> Firewall B -> Router D -> Client

Entscheidend ist nicht, ob jeder einzelne Router identisch ist. Entscheidend ist, ob zustandsabhängige Komponenten in beiden Richtungen den benötigten Sitzungszustand besitzen.

Situation Mögliche Wirkung
Hin- und Rückweg nutzen dieselbe Stateful Firewall Sitzung kann normalerweise korrekt zugeordnet werden
unterschiedliche Router, aber dieselbe Firewall kann funktionieren
unterschiedliche Clusterknoten mit funktionierender State-Synchronisation kann funktionieren
unterschiedliche nicht synchronisierte Firewalls Rückverkehr kann verworfen werden
rein zustandslose ACLs in beiden Richtungen kann mit passenden Gegenregeln funktionieren
NAT nur auf dem Hinweggerät Rückverkehr kann falsches Ziel oder falschen Pfad verwenden
asymmetrischer Pfad durch Sicherheitsprofil vollständige Inhaltsprüfung kann unmöglich sein
Rückweg umgeht die Firewall vollständig Firewall sieht nur eine Richtung und Protokolle bleiben unvollständig

Asymmetrie ist nicht automatisch ein Routingfehler

IP-Routing verlangt nicht grundsätzlich, dass Hin- und Rückweg identisch sind. Asymmetrie wird problematisch, wenn eine beteiligte Komponente Informationen aus beiden Richtungen benötigt.

Typische zustandsabhängige Komponenten:

Die Diagnosefrage lautet deshalb nicht nur:

Existiert ein Rückweg?

Sondern:

Verwendet der Rückweg alle zustandsabhängigen Komponenten,
die den Hinweg verarbeitet haben?

Einen Datenfluss eindeutig identifizieren

Für TCP und UDP wird ein Datenfluss üblicherweise über das Fünf-Tupel beschrieben:

Quelladresse
Quellport
Zieladresse
Zielport
IP-Protokoll

Beispiel:

Originalrichtung:
192.0.2.100:53124 -> 198.51.100.25:443/TCP

Antwortrichtung:
198.51.100.25:443 -> 192.0.2.100:53124/TCP

Zusätzlich zu dokumentieren sind:

Nur die Zieladresse und den Zielport zu dokumentieren reicht nicht. Mehrere gleichzeitige Sitzungen können dasselbe Ziel verwenden und sich nur durch Quelladresse oder Quellport unterscheiden.

Sessiontabelle und Connection Tracking

Eine Sessiontabelle speichert Informationen über aktuell bekannte Datenflüsse. Linux Netfilter bezeichnet diese Funktion als Connection Tracking oder kurz Conntrack.

Ein Eintrag kann unter anderem enthalten:

IP-Protokoll
Original-Quelladresse
Original-Quellport
Original-Zieladresse
Original-Zielport
Antwort-Quelladresse
Antwort-Quellport
Antwort-Zieladresse
Antwort-Zielport
TCP-Zustand
NAT-Status
Sitzungsmarkierung
Timeout
Pakete je Richtung
Bytes je Richtung
erkannte Anwendung
passende Richtlinie
Eingangs- und Ausgangsschnittstelle
Clusterbesitzer

Die Sessiontabelle ermöglicht unter anderem:

Conntrack-Zustände

Bei Netfilter und vergleichbaren Systemen werden häufig folgende generische Zustände unterschieden:

Zustand Bedeutung
NEW gültiger Beginn oder frühes Paket eines noch nicht in beide Richtungen bestätigten Datenflusses
ESTABLISHED gültige Pakete wurden in beiden Richtungen gesehen
RELATED neuer Datenfluss steht in erwarteter Beziehung zu einer vorhandenen Verbindung
INVALID Paket kann keiner gültigen Verbindung zugeordnet werden oder verletzt Erwartungen
UNTRACKED Paket wurde ausdrücklich von Connection Tracking ausgenommen

Die Zustände sind nicht mit dem gleichnamigen TCP-Zustand ESTABLISHED gleichzusetzen. Ein Firewall- oder Conntrack-Zustand beschreibt die Sicht des Tracking-Systems.

Beispiel eines üblichen nftables-Prinzips:

ct state established,related accept
ct state invalid drop

Das ist nur ein vereinfachtes Beispiel. Das vollständige Regelwerk, die Richtung und der Sicherheitsbedarf müssen separat geprüft werden.

TCP-Zustände innerhalb der Sitzung

TCP besitzt zusätzlich protokollspezifische Zustände.

Zustand Einordnung
SYN_SENT Verbindungsanfrage wurde in Originalrichtung gesehen
SYN_RECV passende Antwort mit SYN und ACK wurde gesehen
ESTABLISHED TCP-Verbindungsaufbau wurde bestätigt
FIN_WAIT eine Seite hat die reguläre Beendigung begonnen
CLOSE_WAIT Gegenstelle hat die Beendigung begonnen
LAST_ACK letztes Bestätigungspaket für Verbindungsabbau wird erwartet
TIME_WAIT Schutzphase nach regulärem Verbindungsende
CLOSE Verbindung gilt als geschlossen
RETRANS oder vergleichbarer Zustand Wiederholungen oder fehlende Bestätigungen wurden erkannt
UNACK Daten oder Steuerinformationen wurden noch nicht bestätigt

Die genaue Benennung und Zustandslogik hängen vom verwendeten Produkt ab.

Typischen Conntrack-Eintrag lesen

Beispiel:

tcp 6 431982 ESTABLISHED
src=192.0.2.100 dst=198.51.100.25 sport=53124 dport=443
src=198.51.100.25 dst=192.0.2.100 sport=443 dport=53124
packets=169 bytes=14322
packets=113 bytes=34787
[ASSURED]

Einordnung:

Feld Bedeutung
tcp Transportprotokoll
6 IP-Protokollnummer für TCP
431982 verbleibender Timeout in Sekunden
ESTABLISHED protokollspezifischer Tracking-Zustand
erster Adressblock Originalrichtung
zweiter Adressblock Antwortrichtung
packets gezählte Pakete der jeweiligen Richtung
bytes gezählte Bytes der jeweiligen Richtung
[ASSURED] Antwortverkehr und ausreichend bestätigter Zustand wurden erkannt

Die genaue Darstellung hängt von Kernel-, Conntrack- und Distributionsversion ab.

Wichtige Conntrack-Markierungen

Markierung Bedeutung
[UNREPLIED] bisher wurde keine passende Antwortrichtung gesehen
[ASSURED] der Datenfluss wurde in beiden Richtungen ausreichend bestätigt
src-nat Quellübersetzung ist beteiligt
dst-nat Zielübersetzung ist beteiligt
expected Datenfluss wurde durch eine Erwartung einer anderen Verbindung angekündigt
seen-reply Antwortverkehr wurde erkannt
offload Sitzung wurde in einen beschleunigten Datenpfad ausgelagert
hw-offload Verarbeitung erfolgt zumindest teilweise in Hardware

[UNREPLIED] bedeutet nicht automatisch, dass der Server nicht geantwortet hat. Die Antwort könnte:

Einige Protokolle verwenden zusätzliche Datenverbindungen, die zu einer bestehenden Steuerverbindung gehören.

Mögliche Beispiele:

Ein Connection-Tracking-Helper kann für den zusätzlichen Datenfluss eine Erwartung anlegen. Dieser Datenfluss kann anschließend als RELATED eingeordnet werden.

Zu prüfen sind:

Helpers dürfen nicht pauschal aktiviert werden. Sie greifen in die Protokollverarbeitung ein und können zusätzliche Sicherheits- und Kompatibilitätsauswirkungen besitzen.

Warum asymmetrischer Rückverkehr verworfen wird

Beispiel:

  1. Client sendet ein TCP-SYN.
  2. Firewall A prüft die Sicherheitsregel.
  3. Firewall A legt eine Sitzung an.
  4. Server sendet SYN, ACK.
  5. Routing leitet die Antwort über Firewall B.
  6. Firewall B besitzt keine passende Sitzung.
  7. Firewall B sieht ein Antwortpaket ohne bekannten Verbindungsaufbau.
  8. Firewall B verwirft es als unbekannt oder ungültig.

Vereinfachte Sicht:

Firewall A:
SYN gesehen
Sitzung vorhanden
SYN-ACK nicht gesehen

Firewall B:
SYN nicht gesehen
Sitzung nicht vorhanden
SYN-ACK gesehen

Mögliche Symptome:

Asymmetrie innerhalb derselben Firewall

Auch wenn beide Richtungen dieselbe physische Firewall verwenden, können unterschiedliche Kontexte die Zuordnung verhindern:

Deshalb muss nicht nur der Gerätename, sondern auch der vollständige Verarbeitungskontext übereinstimmen.

Häufige Ursachen asymmetrischer Pfade

Längstes Präfix und Routenauswahl

Router bevorzugen grundsätzlich die spezifischste passende Route.

Beispiel:

10.0.0.0/8      über Firewall A
10.20.30.0/24   über Firewall B

Für das Ziel:

10.20.30.40

wird die spezifischere Route /24 verwendet.

Eine allgemeine Standardroute über die erwartete Firewall garantiert deshalb nicht, dass ein bestimmtes Ziel tatsächlich diese Firewall verwendet.

Zu prüfen sind:

ECMP

Equal-Cost Multi-Path ermöglicht die Nutzung mehrerer gleichwertiger Routen.

Mögliche Verteilungsverfahren:

Per-Flow-ECMP hält normalerweise alle Pakete eines Datenflusses auf demselben Hinweg. Es garantiert jedoch nicht automatisch, dass die Gegenstelle für den Rückweg denselben Firewallknoten auswählt.

Zu prüfen sind:

Ein Problem, das nur bei einem Teil der Verbindungen auftritt, kann auf ECMP oder eine fehlerhafte Teilstrecke hinweisen.

Policy-Based Routing

Policy-Based Routing kann die normale Zielroutenauswahl überschreiben.

Mögliche Kriterien:

Zu prüfen sind:

Typischer Fehler:

Hinweg:
PBR erzwingt Firewall A

Rückweg:
normale Route verwendet Firewall B

Die korrekte Sicherheitsregel auf beiden Firewalls löst den fehlenden gemeinsamen Sitzungszustand nicht.

Dynamisches Routing

Bei OSPF, IS-IS, BGP oder anderen dynamischen Routingprotokollen können sich Hin- und Rückwege unabhängig ändern.

Zu prüfen sind:

Ein Pfad kann im stabilen Zustand symmetrisch und während einer Routingkonvergenz vorübergehend asymmetrisch sein.

Mehrere Netzwerkkarten am Server

Ein Server mit mehreren Netzwerkkarten kann den Rückverkehr über eine andere Schnittstelle senden.

Zu prüfen sind:

Beispiel:

Anfrage erreicht:
eth1 / 10.20.30.40

Serverantwort verlässt:
eth0 / Standardgateway über anderes Netz

Der Serverdienst kann korrekt antworten, während die Antwort einen unzulässigen oder nicht zustandsbehafteten Rückweg verwendet.

Reverse Path Filtering

Reverse Path Filtering prüft, ob die Quelladresse eines eingehenden Pakets aus Sicht der Routingtabelle über einen plausiblen Pfad erreichbar ist.

Unter Linux sind typischerweise folgende Betriebsarten relevant:

Lesende Prüfung:

sysctl net.ipv4.conf.all.rp_filter

sysctl net.ipv4.conf.default.rp_filter

Schnittstellenspezifisch:

sysctl net.ipv4.conf.eth0.rp_filter

Eine strikte Prüfung kann legitimen asymmetrischen Verkehr verwerfen. Sie darf jedoch nicht ohne Sicherheitsbewertung deaktiviert werden. Zuerst sind Route, Quelladresse und tatsächlicher Datenpfad nachzuweisen.

NAT und asymmetrische Pfade

NAT benötigt normalerweise einen konsistenten Zustand für Original- und Antwortrichtung.

Beispiel mit Source NAT:

Originalrichtung:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Der Server antwortet an:

203.0.113.80:443 -> 198.51.100.5:61001

Nur die NAT-Komponente mit der passenden Übersetzung weiß, dass die Antwort zurückübersetzt werden muss zu:

203.0.113.80:443 -> 10.10.20.25:53124

Erreicht die Antwort ein anderes NAT-Gateway ohne synchronisierten Zustand, fehlt die Zuordnung.

Zu prüfen sind:

Source NAT kann bewusst verwendet werden, um den Rückverkehr zu einer bestimmten Komponente zurückzuführen. Diese Maßnahme verändert jedoch Quelladressen und kann Protokollierung, Zugriffskontrolle und Nachvollziehbarkeit beeinflussen.

Load Balancer und Direct Server Return

Bei einem normalen Proxy- oder Full-NAT-Load-Balancer verlaufen Hin- und Rückverkehr häufig über den Load Balancer.

Bei Direct Server Return kann der Server direkt zum Client antworten, ohne den Load Balancer erneut zu durchlaufen.

Das kann beabsichtigt sein, erfordert aber ein passendes Design.

Zu prüfen sind:

Eine Firewall darf nicht fälschlich erwarten, beide Richtungen zu sehen, wenn das freigegebene Architekturdesign bewusst Direct Server Return verwendet.

Firewallcluster und State-Synchronisation

Ein HA-Cluster kann unter anderem synchronisieren:

Nicht jede Sitzungsart und nicht jede Funktion wird zwangsläufig synchronisiert.

Zu prüfen sind:

Eine erfolgreiche Konfigurationssynchronisation beweist keine erfolgreiche Sitzungssynchronisation.

Active/Passive

Bei Active/Passive verarbeitet normalerweise nur der aktive Knoten den produktiven Verkehr. Der passive Knoten erhält je nach Produkt Sitzungsinformationen.

Nach einem Failover sind folgende Ergebnisse möglich:

Zu prüfen sind:

Active/Active

Bei Active/Active können mehrere Knoten gleichzeitig produktiven Verkehr verarbeiten.

Das erfordert je nach Architektur:

Besonders kritisch ist:

SYN:
Knoten A

SYN-ACK:
Knoten B

Folgepakete:
abwechselnd A und B

Wenn die Plattform diesen Datenpfad nicht ausdrücklich unterstützt, können Sitzungen verworfen oder Sicherheitsprüfungen umgangen werden.

Synchronisationsverzögerung

State-Synchronisation erfolgt nicht immer vollständig synchron vor der Paketweiterleitung. Bei kurzen Datenflüssen oder einem schnellen Pfadwechsel kann das Antwortpaket den zweiten Knoten erreichen, bevor der Zustand übertragen wurde.

Mögliche Symptome:

Die Lösung ist nicht automatisch ein längerer Timeout. Zu prüfen sind Synchronisationslink, unterstützte Betriebsart, Flow-Pinning und Routingdesign.

Connection-Tracking-Kapazität

Eine Sessiontabelle besitzt eine begrenzte Kapazität.

Bei Linux sind insbesondere relevant:

nf_conntrack_count
nf_conntrack_max
nf_conntrack_buckets

Lesende Prüfung:

sysctl net.netfilter.nf_conntrack_count

sysctl net.netfilter.nf_conntrack_max

sysctl net.netfilter.nf_conntrack_buckets

Alternative direkte Anzeige:

cat /proc/sys/net/netfilter/nf_conntrack_count

cat /proc/sys/net/netfilter/nf_conntrack_max

Auslastung berechnen:

Auslastung in Prozent =
nf_conntrack_count / nf_conntrack_max × 100

Beispiel:

nf_conntrack_count = 245760
nf_conntrack_max   = 262144

Auslastung =
245760 / 262144 × 100
= 93,75 %

Ein hoher Tabellenfüllstand kann zu folgenden Symptomen führen:

Eine Vergrößerung von nf_conntrack_max benötigt eine Speicher- und Lastbewertung. Sie beseitigt keine Ursache wie Portscan, DDoS, fehlerhafte Anwendung oder ungeeignete Timeouts.

Conntrack-Statistiken

Sofern conntrack-tools installiert ist:

sudo conntrack -S

Mögliche Statistikfelder sind:

Ein einzelner Gesamtzähler ohne Zeitbezug ist wenig aussagekräftig.

Belastbarer Ablauf:

  1. Zähler und Uhrzeit erfassen.
  2. definierten Testzeitraum starten.
  3. genau einen reproduzierbaren Test durchführen.
  4. Zähler erneut erfassen.
  5. Differenz mit Paketaufzeichnung und Protokollen korrelieren.

Timeouts

Sessiontabellen entfernen inaktive Einträge nach protokoll- und zustandsabhängigen Zeiträumen.

Unter Linux können unter anderem relevant sein:

sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_sent

sysctl net.netfilter.nf_conntrack_tcp_timeout_syn_recv

sysctl net.netfilter.nf_conntrack_tcp_timeout_established

sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait

sysctl net.netfilter.nf_conntrack_udp_timeout

sysctl net.netfilter.nf_conntrack_udp_timeout_stream

sysctl net.netfilter.nf_conntrack_icmp_timeout

Die konkreten Werte sind Systemzustand und Konfiguration und dürfen nicht aus einer allgemeinen Dokumentation als garantierte lokale Werte übernommen werden.

Typische Timeoutbefunde:

Befund Mögliche Einordnung
Verbindung bricht nach fester Leerlaufzeit ab Idle-Timeout
neue Verbindung funktioniert sofort vorherige Sitzung ist abgelaufen oder wurde verworfen
UDP-Antwort kommt verspätet und wird verworfen UDP-Tracking-Eintrag bereits entfernt
Langzeitverbindungen scheitern unter Last vorzeitiges Aging oder Tabellenknappheit
nach Failover fehlen nur ältere Sitzungen unvollständige Zustandssynchronisation

Offloading berücksichtigen

Firewalls und Linux-Netfilter können etablierte Datenflüsse in einen beschleunigten Pfad oder in Hardware auslagern.

Mögliche Auswirkungen:

Zu prüfen sind:

Offloading darf nicht pauschal deaktiviert werden, da dies die Leistungsfähigkeit der Firewall erheblich beeinflussen kann.

Hin- und Rückweg getrennt prüfen

Eine Traceroute nur vom Client zum Server zeigt nicht den Rückweg.

Erforderlich sind nach Möglichkeit:

Test A:
Client -> Server

Test B:
Server -> Client

Windows:

tracert 198.51.100.25

Test-NetConnection `
  -ComputerName "198.51.100.25" `
  -Port 443 `
  -InformationLevel Detailed

Linux:

traceroute 198.51.100.25

tracepath 198.51.100.25

macOS:

traceroute 198.51.100.25

Traceroute-Ergebnisse sind nur ein Teilnachweis. Firewalls können:

Für anwendungsnahes Tracing kann abhängig von Plattform und Freigabe ein TCP-basierter Traceroute zum tatsächlichen Zielport verwendet werden.

Lokale Routingentscheidung prüfen

Windows:

Get-NetRoute `
  -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric

Bestimmte Zielroute:

Find-NetRoute `
  -RemoteIPAddress "198.51.100.25"

Klassische Anzeige:

route print

Linux:

ip route get 198.51.100.25

Mit angenommener Quelladresse:

ip route get 198.51.100.25 from 192.0.2.100

Policy-Regeln:

ip rule show

Alle Routingtabellen:

ip route show table all

IPv6:

ip -6 route get 2001:db8::25

macOS:

route -n get 198.51.100.25

Die lokale Routenausgabe zeigt nur die Entscheidung des untersuchten Systems. Sie beweist nicht den vollständigen End-to-End-Pfad.

Linux-Conntrack lesend prüfen

Alle Einträge anzeigen:

sudo conntrack -L

Nur TCP:

sudo conntrack -L -p tcp

Nach Originalquelle und Originalziel filtern:

sudo conntrack -L \
  -p tcp \
  -s 192.0.2.100 \
  -d 198.51.100.25 \
  --dport 443

Nach UDP filtern:

sudo conntrack -L \
  -p udp \
  -s 192.0.2.100 \
  -d 198.51.100.53 \
  --dport 53

Anzahl anzeigen:

sudo conntrack -C

Statistiken anzeigen:

sudo conntrack -S

Conntrack-Ereignisse beobachten:

sudo conntrack -E

Gezielt TCP-Ereignisse beobachten:

sudo conntrack -E -p tcp

Mögliche Ereignisse:

[NEW]
[UPDATE]
[DESTROY]

Die Ereignisbeobachtung sollte auf einen kurzen Testzeitraum begrenzt werden. Auf stark ausgelasteten Systemen kann eine ungefilterte Ausgabe sehr groß werden und interne Kommunikationsdaten enthalten.

Direkte Kernelansicht

Falls conntrack nicht installiert ist, kann abhängig vom System eine Kernelansicht existieren:

sudo cat /proc/net/nf_conntrack

Gezielte Textfilterung:

sudo grep 'dst=198.51.100.25' /proc/net/nf_conntrack

Diese Schnittstelle kann fehlen oder durch Namespace- und Berechtigungseinstellungen eingeschränkt sein. Das conntrack-Werkzeug bietet normalerweise bessere Filter- und Ereignisfunktionen.

Netzwerk-Namespaces und Container

Container, Kubernetes und Linux-Netzwerk-Namespaces können eigene Routing-, Firewall- und Conntrack-Kontexte besitzen.

Zu prüfen sind:

Namespaces anzeigen:

ip netns list

Routing in einem Namespace:

sudo ip netns exec <Namespace> ip route show

Schnittstellen:

sudo ip netns exec <Namespace> ip address show

Ein Conntrack-Eintrag auf dem Host muss anhand der vor und nach NAT sichtbaren Adressen geprüft werden. Die Anwendung kann innerhalb des Containers andere Adressen sehen als die Host-Firewall.

Cisco Secure Firewall ASA prüfen

Verbindungen anzeigen:

show conn

Nach Adresse filtern:

show conn address 192.0.2.100

Anzahl und Kapazität:

show conn count

NAT-Zustände:

show xlate

HA-Zustand:

show failover

Routing:

show route

Drop-Zähler:

show asp drop

Datenfluss simulieren:

packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed

Zu vergleichen sind:

Cisco ASA bietet für bestimmte ausdrücklich geplante asymmetrische Szenarien einen TCP State Bypass. Dieser deaktiviert jedoch wesentliche zustandsabhängige Prüfungen und unterstützt nicht alle Funktionen. Er ist keine allgemeine Reparaturmaßnahme für fehlerhaftes Routing.

Juniper SRX prüfen

Aktive Sitzungen:

show security flow session

Nach Quelle:

show security flow session source-prefix 192.0.2.100

Nach Ziel:

show security flow session destination-prefix 198.51.100.25

Route:

show route 198.51.100.25

Flow-Statistiken:

show security flow statistics

Clusterzustand:

show chassis cluster status

Zu prüfen sind:

Die verfügbaren Filter unterscheiden sich nach Junos-Version und Plattform. Die lokale CLI-Hilfe ist deshalb zusätzlich zu verwenden.

Palo Alto Networks prüfen

Sitzung nach Datenfluss suchen:

show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443

Filtermöglichkeiten prüfen:

show session all filter ?

Routingentscheidung:

test routing fib-lookup virtual-router <Routername> ip 198.51.100.25

HA-Zustand:

show high-availability state

Zu prüfen sind:

Die genaue Syntax und Feldbezeichnung hängt von PAN-OS-Version, Plattform und Betriebsart ab.

AWS Network Firewall

AWS Network Firewall benötigt für zustandsbehaftete Verarbeitung, dass Anfrage und Antwort denselben Firewallendpunkt durchlaufen.

Zu prüfen sind:

AWS Network Firewall unterstützt keine asymmetrische Weiterleitung zu unterschiedlichen Firewallendpunkten. Anfrage und Antwort müssen demselben Endpunkt zugeführt werden.

Ein Reachability-Analyzer-Ergebnis kann die modellierte Erreichbarkeit prüfen, ersetzt aber nicht die Auswertung realer Flow- und Alert-Logs.

AWS Security Group Connection Tracking

AWS Security Groups sind zustandsbehaftet und verfolgen Verbindungen. Zu prüfen sind:

Asymmetrisches Routing über verschiedene Netzwerkschnittstellen kann bei verfolgten Datenflüssen die erreichbare Leistung beeinträchtigen. AWS empfiehlt nach Möglichkeit symmetrische Topologien.

Azure Firewall und Network Virtual Appliances

Bei Azure sind unter anderem zu prüfen:

Effektive Routen per PowerShell:

Get-AzEffectiveRouteTable `
  -NetworkInterfaceName "<NIC-Name>" `
  -ResourceGroupName "<Ressourcengruppe>"

Ein öffentlicher Load Balancer und eine private Firewallroute können einen asymmetrischen Pfad erzeugen, wenn der Hinverkehr über die öffentliche Load-Balancer-Adresse eintrifft und der Rückverkehr über die private Firewalladresse geführt wird.

Bei Active/Active-NVAs muss geprüft werden, ob:

Paketaufzeichnung systematisch planen

Für einen vollständigen Pfadvergleich sind möglichst vier Beobachtungspunkte hilfreich:

Punkt Beobachtung
A Paket verlässt den Client
B Paket erreicht und verlässt die zustandsbehaftete Komponente
C Paket erreicht den Server und Antwort verlässt ihn
D Antwort erreicht oder verfehlt die zustandsbehaftete Komponente

Empfohlener Filter:

host 192.0.2.100 and host 198.51.100.25 and tcp port 443

Mit tcpdump:

sudo tcpdump \
  -ni any \
  'host 192.0.2.100 and host 198.51.100.25 and tcp port 443'

Nur TCP-Flags und Zeitverhalten prüfen:

sudo tcpdump \
  -ni any \
  -tttt \
  'host 192.0.2.100 and host 198.51.100.25 and tcp port 443'

Für NAT müssen gegebenenfalls zwei Filter verwendet werden:

vor NAT:
10.10.20.25:53124 -> 203.0.113.80:443

nach NAT:
198.51.100.5:61001 -> 203.0.113.80:443

Paketaufzeichnungen dürfen nur autorisiert, zielgerichtet und zeitlich begrenzt durchgeführt werden.

Zeitstempel korrelieren

Alle beteiligten Systeme sollten eine ausreichend genaue Zeitbasis verwenden:

Zu dokumentieren sind:

Datum
Uhrzeit
Zeitzone
Zeitquelle
ungefähre Zeitabweichung

Schon wenige Sekunden Unterschied können bei kurzen Verbindungsversuchen zu einer falschen Zuordnung führen.

Pakete und Bytes je Richtung auswerten

Befund Mögliche Einordnung
nur Originalpakete, keine Antwortpakete Serverantwort fehlt oder verwendet anderen Rückweg
Antwortpakete am Server, nicht an Firewall Route zwischen Server und Firewall prüfen
Antwortpakete an anderer Firewall asymmetrischer Rückweg
beide Richtungen in Sitzung, Client empfängt nichts nachgelagerter Pfad zum Client prüfen
wenige Pakete, Sitzung bleibt SYN_SENT SYN-ACK fehlt
Pakete in beide Richtungen, aber kaum Bytes Handshake ohne Anwendungsdaten
hohe Bytes nur in einer Richtung Anwendung, ACK-Pfad oder Filterproblem
Sitzung verschwindet sofort RST, Policy-Drop, Timeout oder Tabellenproblem
Sitzung bleibt lange [UNREPLIED] keine zugeordnete Antwort

Zähler müssen während genau eines reproduzierbaren Tests verglichen werden.

NetFlow, IPFIX und Flow Logs

Flow-Daten können Hinweise liefern auf:

Einschränkungen:

Flow-Daten sind besonders hilfreich, wenn Hin- und Rückrichtung auf unterschiedlichen Geräten sichtbar werden.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der TCP-Verbindungsaufbau läuft über Firewall A, der Rückverkehr
aufgrund einer spezifischeren Serverroute jedoch über Firewall B.
Firewall B besitzt keinen synchronisierten Sitzungszustand und
verwirft das SYN-ACK.

Erwarteter Befund:
Firewall A zeigt eine Sitzung im Zustand SYN_SENT oder UNREPLIED.
Firewall B zeigt keinen passenden Sitzungseintrag, aber einen
Invalid-State-Drop für das SYN-ACK.
Eine serverseitige Paketaufzeichnung zeigt, dass das SYN-ACK den
Server verlässt.

Gegenbeweis:
Hin- und Rückverkehr durchlaufen nachweislich Firewall A, und
Firewall A sieht das SYN-ACK in derselben Sitzung.

Testmethode:
Routingtabellen, Sessiontabellen und zeitgleiche Paketaufzeichnungen
auf Client-, Server- und Firewallseite vergleichen.

Risiko:
Nur lesende Diagnose und begrenzte Paketaufzeichnung.

Erfolgskriterium:
Abweichender Rückweg und verwerfendes Gerät sind mit Zeitstempel,
Sitzungsdaten und Routingentscheidung eindeutig belegt.

Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko Rückweg
spezifische Rückroute korrigieren falscher Rückweg nachgewiesen weitere Ziele können betroffen sein alte Route wiederherstellen
Routingmetrik korrigieren falsche Pfadauswahl bestätigt Konvergenz und Lastverteilung ändern sich alte Metrik wiederherstellen
PBR-Regel korrigieren asymmetrische PBR-Entscheidung bestätigt andere markierte Flows betroffen vorherige PBR-Regel aktivieren
ECMP-Hash oder Flow-Pinning korrigieren Verteilung auf unterschiedliche Stateful-Knoten bestätigt Lastverteilung verändert sich vorherige Einstellung wiederherstellen
Cluster-State-Synchronisation reparieren fehlende Synchronisation nachgewiesen HA-Verhalten betroffen herstellerspezifischer Rückfallplan
SNAT gezielt einsetzen Rückweg muss technisch gebunden werden Originalquelle wird verdeckt SNAT-Regel entfernen
NAT-Regel korrigieren falscher NAT-Besitzer oder falsche Übersetzung bestätigt Erreichbarkeit vieler Verbindungen alte NAT-Regel wiederherstellen
einzelne Sitzung löschen veralteter Eintrag nachgewiesen genau diese Verbindung wird unterbrochen Anwendung baut Sitzung neu auf
Timeout korrigieren nachweislicher Timeoutkonflikt höhere Tabellenbelegung alten Wert wiederherstellen
Conntrack-Kapazität erhöhen Tabellenlimit und ausreichender Speicher nachgewiesen höherer Speicherbedarf alten Grenzwert wiederherstellen
fehlerhafte Quelle begrenzen ungewöhnlich viele Sessions einer Quelle bestätigt legitime Kommunikation kann betroffen sein Begrenzung entfernen
Active/Active-Design anpassen Plattform unterstützt Asymmetrie nicht Verfügbarkeit und Verteilung ändern sich vorheriges Routingdesign wiederherstellen

Eine Änderung an Routing, NAT oder HA muss als zusammenhängende Ende-zu-Ende-Änderung bewertet werden.

Vollständiger Diagnoseablauf

  1. Exakte Fehlermeldung dokumentieren.
  2. Datum, Uhrzeit und Zeitzone erfassen.
  3. Betroffene Anwendung bestimmen.
  4. Quell- und Zielsystem bestimmen.
  5. Quelladresse und Quellport erfassen.
  6. Zieladresse und Zielport erfassen.
  7. Protokoll bestimmen.
  8. IPv4 und IPv6 unterscheiden.
  9. Originalrichtung dokumentieren.
  10. Antwortrichtung dokumentieren.
  11. NAT vor und nach Übersetzung dokumentieren.
  12. Fehlerumfang bestimmen.
  13. Erwarteten Hinweg dokumentieren.
  14. Erwarteten Rückweg dokumentieren.
  15. Lokale Clientroute prüfen.
  16. Lokale Serverroute prüfen.
  17. Policy Routing auf beiden Endsystemen prüfen.
  18. Routinginstanzen und VRFs berücksichtigen.
  19. Tatsächlichen Hinweg nachweisen.
  20. Tatsächlichen Rückweg unabhängig nachweisen.
  21. Alle zustandsbehafteten Komponenten erfassen.
  22. Aktive Firewall- und Clusterknoten bestimmen.
  23. Sessiontabellen auf allen möglichen Knoten prüfen.
  24. Sitzungs-ID dokumentieren.
  25. Original- und Antwort-Tupel vergleichen.
  26. TCP-, UDP- oder ICMP-Zustand auswerten.
  27. [UNREPLIED], [ASSURED] oder vergleichbare Markierung prüfen.
  28. Pakete und Bytes je Richtung vergleichen.
  29. NAT-Sitzung und NAT-Besitzer prüfen.
  30. Regel- und Drop-Protokolle korrelieren.
  31. Cluster- und State-Synchronisation prüfen.
  32. Zeitpunkt des letzten Failovers prüfen.
  33. ECMP und Hash-Verfahren prüfen.
  34. PBR und Source Routing prüfen.
  35. dynamische Routen und spezifischere Präfixe prüfen.
  36. Load Balancer und Direct Server Return berücksichtigen.
  37. Cloud-Routingtabellen und Firewallendpunkte prüfen.
  38. Conntrack-Auslastung erfassen.
  39. Conntrack-Fehlerzähler erfassen.
  40. Timeouts dokumentieren.
  41. Hardware-Offloading berücksichtigen.
  42. kontrollierten Verbindungstest durchführen.
  43. bei Bedarf Conntrack-Ereignisse beobachten.
  44. bei Bedarf Paketaufzeichnung an mehreren Punkten durchführen.
  45. Hypothese und Gegenbeweis formulieren.
  46. genau eine kontrollierte Maßnahme vorbereiten.
  47. Risiko, Rückweg und Erfolgskriterium dokumentieren.
  48. Maßnahme freigeben und umsetzen.
  49. vollständig neue Sitzung aufbauen.
  50. Hin- und Rückweg erneut prüfen.
  51. Session- und NAT-Zustand erneut prüfen.
  52. ursprüngliche Anwendung verifizieren.
  53. weitere repräsentative Datenflüsse prüfen.
  54. temporäre Aufzeichnungen und Diagnoseregeln zurücknehmen.
  55. Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
Sitzung nur auf Firewall A Firewall B besitzt keinen Zustand Rückweg und State-Synchronisation prüfen
Firewall A zeigt [UNREPLIED] keine zugeordnete Antwort serverseitige Aufzeichnung und Rückroute
Server sendet SYN-ACK, Client empfängt nichts Rückweg wird verworfen Firewalls des Rückwegs erfassen
Firewall B meldet INVALID unbekannter oder fehlerhafter Zustand ursprünglichen SYN-Pfad bestimmen
Verbindung funktioniert nur manchmal ECMP oder einzelner fehlerhafter Pfad mehrere Tests mit Quellports vergleichen
Verbindung funktioniert nach Wiederholung Synchronisationsverzögerung oder Routingkonvergenz Cluster- und Routingzeitpunkte prüfen
nur neue Verbindungen scheitern Conntrack-Tabelle voll oder neue Policy Kapazität und Insert-Failed-Zähler
bestehende Verbindungen funktionieren Zustand vorhanden, neue Einträge scheitern Sessionlimit und Ressourcenauslastung
nach Failover brechen Sitzungen ab State- oder NAT-Synchronisation unvollständig HA-Protokoll und Tabellen vergleichen
nur lange Leerlaufverbindungen brechen ab Idle-Timeout Timeout und Keepalive vergleichen
UDP bleibt [UNREPLIED] Antwort fehlt oder anderer Rückweg Antwortaufzeichnung und UDP-Timeout
unterschiedliche NAT-Abbildung je Knoten NAT-Synchronisation fehlerhaft Übersetzungstabellen vergleichen
gleicher Firewallname, Sitzung fehlt anderer VSYS, VRF oder Kontext vollständigen Verarbeitungskontext prüfen
Hinweg über VPN, Rückweg über Internet Präfixankündigung oder PBR Routen auf Server- und Gatewayseite
nur ein Zielpräfix betroffen spezifischere Route Longest-Prefix-Match prüfen
nur ein Teil der Clients betroffen Quellrouting, Hash oder PBR Quellen und Quellports vergleichen
Conntrack-Auslastung nahe Grenzwert Tabellenknappheit Neu-, Drop- und Early-Drop-Rate
insert_failed steigt neue Einträge können nicht angelegt werden Tabellenlimit und Speicher prüfen
viele UNREPLIED-Einträge Scans, nicht erreichbare Ziele oder Rückwegproblem Quellen, Ziele und Rate analysieren
Flow ist hardware-offloaded Softwarecapture eventuell unvollständig Hardwarezähler oder externen TAP verwenden
AWS Firewall sieht nur eine Richtung unterschiedliche Firewallendpunkte Routingtabellen je Availability Zone
Azure NVA-Instanzen sehen je eine Richtung Active/Active ohne Flow-Symmetrie ECMP und Session Sharing prüfen
Traceroute wirkt symmetrisch, Sitzung fehlt Traceroute nutzt anderen Datenfluss Capture mit echtem Protokoll und Port
Sitzung vorhanden, keine Anwendung Netzwerkpfad möglicherweise korrekt TLS, Protokoll und Serverdienst prüfen

Typische Diagnosefehler

Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Eine einzelne erfolgreiche Verbindung nach einer Routingänderung ist keine ausreichende Verifikation. Bei ECMP- oder Clusterproblemen müssen mehrere neue Verbindungen mit unterschiedlichen Quellports geprüft werden.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Originalrichtung:
<Quell-IP:Port -> Ziel-IP:Port/Protokoll>

Antwortrichtung:
<Ziel-IP:Port -> Quell-IP:Port/Protokoll>

NAT vor Übersetzung:
<Adressen und Ports>

NAT nach Übersetzung:
<Adressen und Ports>

Erwarteter Hinweg:
<Netzwerkpfad>

Tatsächlicher Hinweg:
<nachgewiesener Netzwerkpfad>

Erwarteter Rückweg:
<Netzwerkpfad>

Tatsächlicher Rückweg:
<nachgewiesener Netzwerkpfad>

Zustandsbehaftete Komponenten:
<Firewalls, NAT, Load Balancer und Gateways>

Firewall- oder Clusterknoten:
<Name und Rolle>

Virtueller Kontext:
<VSYS, VRF, Mandant oder Routinginstanz>

Sitzungs-ID:
<ID>

Sitzungszustand:
<NEW, ESTABLISHED, UNREPLIED oder produktspezifischer Zustand>

Session Owner:
<Knoten oder Instanz>

Pakete und Bytes:
<je Richtung>

Timeout:
<aktueller Wert und Restzeit>

NAT-Sitzung:
<Übersetzung und Besitzer>

Conntrack-Auslastung:
<Count, Max und Prozent>

Fehlerzähler:
<Drop, Early Drop, Insert Failed oder produktspezifischer Zähler>

Cluster-Synchronisation:
<Status und Befund>

Paketaufzeichnung:
<Befund je Beobachtungspunkt>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<widerlegender Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko:
<mögliche Nebenwirkungen>

Rückweg:
<Rollback>

Verifikation:
<neue Sitzung, Pfad, Zustand und Anwendung>

Prävention:
<Monitoring, Routingdesign oder Prozessverbesserung>

Checkliste

Schnellreferenz

Aufgabe Befehl
Windows-Routingtabelle route print
Windows-Routen Get-NetRoute
Windows-Zielroute Find-NetRoute -RemoteIPAddress "198.51.100.25"
Windows-Traceroute tracert 198.51.100.25
Linux-Zielroute ip route get 198.51.100.25
Linux-Zielroute mit Quelle ip route get 198.51.100.25 from 192.0.2.100
Linux-Policy-Routing ip rule show
Linux-alle Routingtabellen ip route show table all
Linux-IPv6-Route ip -6 route get 2001:db8::25
Linux-Traceroute traceroute 198.51.100.25
Linux-Path-MTU/Pfad tracepath 198.51.100.25
macOS-Zielroute route -n get 198.51.100.25
macOS-Traceroute traceroute 198.51.100.25
Conntrack-Einträge sudo conntrack -L
Conntrack-Anzahl sudo conntrack -C
Conntrack-Statistiken sudo conntrack -S
Conntrack-Ereignisse sudo conntrack -E
aktueller Conntrack-Füllstand sysctl net.netfilter.nf_conntrack_count
maximales Conntrack-Limit sysctl net.netfilter.nf_conntrack_max
Conntrack-Hash-Buckets sysctl net.netfilter.nf_conntrack_buckets
Reverse Path Filtering sysctl net.ipv4.conf.all.rp_filter
Cisco ASA Sitzungen show conn
Cisco ASA Sitzungsanzahl show conn count
Cisco ASA NAT show xlate
Cisco ASA HA show failover
Cisco ASA Drops show asp drop
Juniper Sitzungen show security flow session
Juniper Flow-Statistik show security flow statistics
Juniper Cluster show chassis cluster status
Palo Alto Sitzungssuche show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443
Palo Alto HA show high-availability state

Verändernde Befehle und Maßnahmen, die nicht als erste Diagnose verwendet werden dürfen:

conntrack -F
conntrack -D
clear conn
clear xlate
clear session all
clear security flow session
Firewall-State-Bypass aktivieren
TCP State Bypass aktivieren
Stateful Inspection deaktivieren
Conntrack-Limit ungeprüft erhöhen
Sessiontimeout ungeprüft erhöhen
Routingprotokoll neu starten
Cluster-Failover erzwingen
Firewallcluster neu starten
ECMP global deaktivieren
produktive Route ungeprüft entfernen
SNAT pauschal aktivieren
Hardware-Offloading global deaktivieren

Quellen

Standards und Grundlagen

Linux Kernel und Netfilter

Cisco

Juniper Networks

Amazon Web Services

Microsoft Azure

Für diese Seite wurden keine Community-Beiträge oder Hersteller-Social-Media-Aussagen als fachlicher Nachweis verwendet.

Revision #1
Created 2 August 2026 20:36:54 by Admin
Updated 2 August 2026 20:40:30 by Admin