Skip to main content

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:

  • ob Hin- und Rückverkehr denselben zustandsbehafteten Datenpfad verwenden;
  • welche Firewall oder welcher Clusterknoten eine Sitzung angelegt hat;
  • ob eine passende Sitzungstabelle vorhanden ist;
  • welchen Zustand eine TCP-, UDP- oder ICMP-Kommunikation besitzt;
  • ob Connection Tracking ausgelastet oder fehlerhaft ist;
  • ob ECMP, Policy-Based Routing, dynamisches Routing oder NAT eine Asymmetrie erzeugt;
  • ob Sitzungszustände zwischen HA-Knoten synchronisiert werden;
  • ob bestehende Sitzungen einen Test verfälschen;
  • an welcher Stelle der Hin- oder Rückweg abweicht;
  • wie eine Routing- oder Sitzungsänderung kontrolliert verifiziert wird.

Sicherheits- und Änderungsgrundsätze

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

  • Benutzerverbindungen;
  • Datenbankverbindungen;
  • VPN-Tunnel;
  • Dateiübertragungen;
  • VoIP-Sitzungen;
  • Streamingverbindungen;
  • Backups;
  • Replikation;
  • Clusterkommunikation;
  • Verwaltungszugriffe.

Nicht als erste Diagnosemaßnahme geeignet sind:

  • vollständige Sessiontabelle löschen;
  • Conntrack-Tabelle leeren;
  • Firewallcluster neu starten;
  • Failover erzwingen;
  • Routingprotokoll neu starten;
  • ECMP vollständig deaktivieren;
  • produktive Routen ungeprüft entfernen;
  • Source NAT pauschal aktivieren;
  • Stateful Inspection deaktivieren;
  • TCP State Bypass einschalten;
  • Timeouts ohne Nachweis erhöhen;
  • Conntrack-Maximalwert ohne Kapazitätsprüfung verändern;
  • Hardware-Offloading global abschalten;
  • allgemeine Stateless-Regeln erstellen;
  • Paketprüfungen global lockern.

Vor einer Änderung sind mindestens zu dokumentieren:

  • Ausgangszustand;
  • betroffene Datenflüsse;
  • aktuelle Route in beiden Richtungen;
  • aktive Sitzung;
  • zuständiger Firewallknoten;
  • NAT-Zustand;
  • Clusterzustand;
  • Risiko;
  • Rückweg;
  • Erfolgskriterium;
  • Wartungsfenster;
  • verantwortliche Freigabe.

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:

  • Stateful Firewall;
  • NAT-Gateway;
  • Intrusion Prevention System;
  • Application Delivery Controller;
  • Load Balancer;
  • Reverse Proxy;
  • VPN-Gateway;
  • WAN-Optimierer;
  • DDoS-Schutzsystem;
  • Carrier-Grade NAT;
  • Cloud Network Firewall;
  • Linux-Router mit Netfilter Connection Tracking.

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:

  • Datum und Uhrzeit;
  • Zeitzone;
  • Eingangs- und Ausgangsschnittstelle;
  • Quell- und Zielzone;
  • VRF oder Routinginstanz;
  • ursprüngliche Adressen;
  • übersetzte Adressen;
  • ursprüngliche Ports;
  • übersetzte Ports;
  • Firewallknoten;
  • Sitzungs-ID;
  • Routingentscheidung;
  • Anwendung;
  • Tunnel oder VPN;
  • Mandant oder virtueller Kontext.

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:

  • Rückverkehr einer erlaubten Verbindung zuordnen;
  • ungültige TCP-Pakete erkennen;
  • UDP-Antworten einer Pseudositzung zuordnen;
  • ICMP-Fehler einer ursprünglichen Kommunikation zuordnen;
  • NAT in beiden Richtungen konsistent anwenden;
  • zusammengehörige Anwendungsdatenflüsse erkennen;
  • Sitzungen zwischen HA-Knoten synchronisieren.

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:

  • einen anderen Rückweg genommen haben;
  • vor dem Tracking-System verworfen worden sein;
  • nach dem Timeout eingetroffen sein;
  • eine abweichende Adresse oder einen abweichenden Port verwenden;
  • von einer anderen Firewall verarbeitet worden sein.

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

Mögliche Beispiele:

  • FTP;
  • bestimmte RPC-Verfahren;
  • SIP und dynamische Medienströme;
  • TFTP;
  • ältere oder herstellerspezifische Protokolle.

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:

  • wird ein Helper verwendet?
  • ist der Helper ausdrücklich zugewiesen?
  • ist die Protokollerkennung verschlüsselt oder unverschlüsselt?
  • stimmen dynamisch ausgehandelte Adressen und Ports?
  • verändert NAT die Nutzdaten?
  • nimmt der zusätzliche Datenfluss denselben zustandsbehafteten Pfad?
  • ist der Helper auf der verwendeten Version noch vorgesehen und sicher?

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:

  • Client sendet wiederholt SYN;
  • Server sendet wiederholt SYN, ACK;
  • Client empfängt keine Antwort;
  • eine Firewall zeigt SYN_SENT oder [UNREPLIED];
  • andere Firewall zeigt Invalid-State-Drops;
  • Regelprotokolle zeigen nur eine Richtung;
  • Verbindung funktioniert nach manchen Routingänderungen zufällig;
  • Verbindung funktioniert nur über einen bestimmten Clusterknoten.

Asymmetrie innerhalb derselben Firewall

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

  • unterschiedliche virtuelle Systeme;
  • unterschiedliche VRFs;
  • unterschiedliche Sicherheitszonen;
  • unterschiedliche Routinginstanzen;
  • unterschiedliche Mandanten;
  • unterschiedliche Tunnel;
  • unterschiedliche logische Systeme;
  • unterschiedliche virtuelle Router;
  • getrennte Sessiontabellen.

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

Häufige Ursachen asymmetrischer Pfade

  • unterschiedliche Standardrouten;
  • unterschiedlich gelernte dynamische Routen;
  • ECMP;
  • per-Packet Load Balancing;
  • Policy-Based Routing;
  • Source-Based Routing;
  • mehrere Internetanschlüsse;
  • SD-WAN-Pfadauswahl;
  • BGP-Multihoming;
  • unterschiedliche OSPF-Kosten;
  • längeres oder kürzeres Präfix;
  • statische Route nur auf einer Seite;
  • VRF-Leak;
  • fehlende Rückroute;
  • Load Balancer;
  • Direct Server Return;
  • NAT Gateway;
  • unterschiedliche VPN-Tunnel;
  • mehrere Transit-Gateways;
  • Cloud User Defined Routes;
  • Kubernetes- oder Overlay-Netz;
  • Cluster mit unvollständiger State-Synchronisation;
  • Failover während einer aktiven Sitzung;
  • fehlerhafte Route Redistribution;
  • serverseitige zweite Netzwerkkarte;
  • falsches Standardgateway des Servers;
  • Proxy- oder Reverse-Proxy-Pfad;
  • Container- oder Host-NAT.

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:

  • Zielpräfix;
  • Präfixlänge;
  • Routingprotokoll;
  • administrative Distanz oder Preference;
  • Metrik;
  • nächster Hop;
  • Ausgangsschnittstelle;
  • Routinginstanz;
  • Route Policy;
  • aktive und alternative Route.

ECMP

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

Mögliche Verteilungsverfahren:

  • pro Paket;
  • pro Datenfluss;
  • Hash über Quell- und Zieladresse;
  • Hash über Fünf-Tupel;
  • gewichtete Verteilung;
  • resilienter Hash;
  • dynamische Auslastungsverteilung.

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:

  • welche Felder in den Hash einfließen;
  • ob Hin- und Rückrichtung denselben Hash ergeben;
  • ob beide Seiten dieselben Pfade kennen;
  • ob Link- oder Routingänderungen den Hash neu verteilen;
  • ob Clusterknoten Sitzungen synchronisieren;
  • ob der nächste Hop ein Stateful-Gerät ist;
  • ob Fragmentierung die Hash-Auswahl verändert;
  • ob NAT vor oder nach der ECMP-Auswahl erfolgt.

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:

  • Quelladresse;
  • Zieladresse;
  • Protokoll;
  • Quellport;
  • Zielport;
  • Eingangsschnittstelle;
  • DSCP;
  • Benutzer;
  • Anwendung;
  • Sicherheitszone;
  • Routingmarkierung.

Zu prüfen sind:

  • passende PBR-Regel;
  • Regelreihenfolge;
  • nächster Hop;
  • Zustand des nächsten Hops;
  • Fallbackverhalten;
  • Rückrichtung;
  • Routingmarkierungen;
  • NAT-Abhängigkeit;
  • Verfügbarkeitstracking;
  • lokale Ausnahmen.

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:

  • empfangene Präfixe;
  • angekündigte Präfixe;
  • Route Policies;
  • Filterlisten;
  • lokale Preference;
  • MED;
  • AS-PATH;
  • OSPF-Kosten;
  • administrative Distanz;
  • Route Redistribution;
  • zusammengefasste Routen;
  • spezifischere Präfixe;
  • ECMP;
  • Konvergenzzeit;
  • Flapping;
  • Graceful Restart;
  • aktiver nächster Hop;
  • Zeitpunkt der letzten Änderung.

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:

  • IP-Adresse je Schnittstelle;
  • Standardgateway;
  • spezifische Routen;
  • Routingmetrik;
  • Source Address Selection;
  • Policy Routing;
  • Bonding oder Teaming;
  • VRF;
  • Container- oder Namespace-Routen;
  • virtuelle Switches;
  • Hypervisor-Routing;
  • Reverse Path Filtering.

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:

  • deaktiviert;
  • strikte Prüfung;
  • lose Prüfung.

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:

  • welches Gerät SNAT oder DNAT durchführt;
  • Original- und Übersetzungsadressen;
  • Original- und Übersetzungsports;
  • NAT-Sitzungs-ID;
  • NAT-Pool;
  • Port Address Translation;
  • Rückroute zur übersetzten Adresse;
  • HA-Synchronisation;
  • Porterschöpfung;
  • NAT-Regelreihenfolge;
  • Hairpin- oder U-Turn-NAT;
  • doppelte NAT-Verarbeitung.

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:

  • Betriebsart des Load Balancers;
  • Full Proxy, NAT oder Direct Server Return;
  • virtuelle IP-Adresse;
  • Backendadresse;
  • Source NAT;
  • Rückroute des Backends;
  • Firewallzustand;
  • Health Probes;
  • Client-IP-Erhaltung;
  • Server-Loopschnittstelle;
  • ARP-Verhalten;
  • Sicherheitsprofile;
  • Protokollierung in beiden Richtungen.

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:

  • TCP-Sitzungen;
  • UDP-Pseudositzungen;
  • NAT-Übersetzungen;
  • VPN-Zustände;
  • Authentifizierungsinformationen;
  • Sequenznummern;
  • Zeitstempel;
  • Anwendungszustände;
  • Persistenzinformationen.

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

Zu prüfen sind:

  • Clusterbetriebsart;
  • Active/Passive oder Active/Active;
  • Zustandssynchronisationsschnittstelle;
  • Paketverlust auf dem Synchronisationslink;
  • Latenz;
  • Synchronisationswarteschlangen;
  • unterstützte Sitzungsarten;
  • NAT-Synchronisation;
  • Anwendungssynchronisation;
  • Softwareversionsgleichheit;
  • Konfigurationsgleichheit;
  • aktiver Sitzungseigentümer;
  • letzter Failoverzeitpunkt;
  • Split-Brain-Zustand;
  • Neustart eines Knotens;
  • Initialsynchronisation;
  • Tabellenfüllstand.

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:

  • bestehende Sitzungen laufen weiter;
  • nur bestimmte Sitzungsarten laufen weiter;
  • NAT bleibt erhalten, Anwendungszustand jedoch nicht;
  • Verbindungen müssen neu aufgebaut werden;
  • Sitzungen gehen wegen unvollständiger Synchronisation verloren;
  • der neue aktive Knoten besitzt veraltete Zustände.

Zu prüfen sind:

  • war die Sitzung vor dem Failover synchronisiert?
  • war die Synchronisationsschnittstelle fehlerfrei?
  • besitzt der neue aktive Knoten die passende Sitzung?
  • blieb die NAT-Zuordnung erhalten?
  • wurde die Route zusammen mit der Firewallrolle umgeschaltet?
  • erreichen beide Richtungen den neuen aktiven Knoten?

Active/Active

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

Das erfordert je nach Architektur:

  • Flow-Pinning;
  • konsistentes Hashing;
  • State Sharing;
  • Session Ownership;
  • Cluster-Forwarding;
  • symmetrische Next-Hop-Auswahl;
  • funktionierende NAT-Synchronisation.

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:

  • nur erste Verbindung nach Failover scheitert;
  • Wiederholung funktioniert;
  • sehr kurze UDP-Anfragen sind besonders betroffen;
  • Probleme treten nur unter hoher Last auf;
  • Clusterprotokolle zeigen verlorene oder verspätete Updates;
  • Sitzung ist auf dem aktiven, aber nicht auf dem anderen Knoten sichtbar.

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:

  • neue Verbindungen schlagen fehl;
  • bestehende Sitzungen funktionieren weiterhin;
  • Kernel meldet volle Conntrack-Tabelle;
  • Einträge werden vorzeitig entfernt;
  • Drop- oder Insert-Failed-Zähler steigen;
  • UDP- oder Kurzzeitsitzungen erhöhen die Last stark;
  • NAT-Verbindungen können nicht mehr angelegt werden.

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:

  • gefundene Einträge;
  • Suchvorgänge;
  • eingefügte Einträge;
  • fehlgeschlagene Einfügungen;
  • Drops;
  • Early Drops;
  • Fehler;
  • Hash-Kollisionen;
  • zu lange Suchketten.

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:

  • allgemeine Softwarezähler steigen nicht bei jedem Paket;
  • Paketaufzeichnung auf der Steuer- oder Softwareebene sieht nicht alle Pakete;
  • Sitzungsdaten werden verzögert aktualisiert;
  • ein Flow erscheint als offload oder hw-offload;
  • Fehlerzähler befinden sich auf einer anderen Datenebene;
  • eine Änderung wirkt erst nach Rückkehr aus dem Offloadpfad oder nach Sitzungsende.

Zu prüfen sind:

  • ist der Datenfluss ausgelagert?
  • wo werden Hardwarezähler angezeigt?
  • kann das Produkt gezielt einen Flow erfassen?
  • verändert die Diagnosefunktion den Offloadstatus?
  • besitzt jeder Clusterknoten eigene Hardwaretabellen?

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:

  • TTL-Fehlermeldungen unterdrücken;
  • transparent arbeiten;
  • auf Traceroute-Protokolle anders reagieren;
  • mehrere Pfade verwenden;
  • ICMP, UDP und TCP unterschiedlich routen;
  • im Rückweg nicht sichtbar sein.

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:

  • Host-Namespace;
  • Container-Namespace;
  • Pod-Namespace;
  • Bridge;
  • veth-Schnittstellen;
  • Overlay-Netz;
  • Service-NAT;
  • kube-proxy-Betriebsart;
  • CNI-Plugin;
  • Node-Firewall;
  • Cloud-Firewall;
  • eBPF-Datenpfad;
  • Host- und Podroute;
  • Rückweg zum ursprünglichen Node.

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:

  • existiert die Sitzung?
  • welcher Knoten besitzt sie?
  • stimmen Original- und Übersetzungsadressen?
  • steigen Bytes in beiden Richtungen?
  • welcher TCP-Zustand oder welche Flags werden angezeigt?
  • sind Failover und State-Synchronisation fehlerfrei?
  • steigt ein Drop-Zähler beim kontrollierten Test?

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:

  • Ingress- und Egress-Interface;
  • Quell- und Zielzone;
  • Sitzungsstatus;
  • NAT;
  • Timeout;
  • Pakete und Bytes;
  • Session Owner;
  • HA- oder Clusterknoten;
  • Drop-Statistiken;
  • verwendete Routinginstanz.

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:

  • Session-ID;
  • Session Owner;
  • Quell- und Zielzone;
  • Original- und NAT-Tupel;
  • Anwendung;
  • Sicherheitsregel;
  • Pakete und Bytes beider Richtungen;
  • Sitzungsendgrund;
  • Hardware-Offload;
  • HA-Synchronisation;
  • virtueller Router.

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:

  • Firewallendpunkt je Availability Zone;
  • VPC-Routingtabellen;
  • Transit Gateway;
  • Appliance Mode;
  • Ingress- und Egress-Routen;
  • NAT Gateway;
  • Internet Gateway;
  • Gateway Load Balancer;
  • zentrale Inspection VPC;
  • Flow Logs;
  • Alert Logs;
  • Stateful Rule Groups;
  • Availability-Zone-Affinität.

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:

  • tatsächlich zugeordnete Security Groups;
  • eingehende und ausgehende Regeln;
  • Netzwerkschnittstellen;
  • Connection-Tracking-Kapazität;
  • Idle-Timeouts;
  • asymmetrische Pfade über mehrere Netzwerkschnittstellen;
  • Network ACLs;
  • Gateway- und Transitpfade.

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:

  • User Defined Routes;
  • effektive Routen der Netzwerkschnittstelle;
  • Azure Firewall;
  • Network Virtual Appliance;
  • Load Balancer;
  • Virtual WAN;
  • ExpressRoute;
  • VPN Gateway;
  • VNet Peering;
  • NAT Gateway;
  • Hub-and-Spoke-Routing;
  • aktive und aktive NVA-Instanzen;
  • Zustandssynchronisation;
  • SNAT-Verhalten.

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:

  • beide Richtungen dieselbe Instanz verwenden;
  • Flow-Pinning existiert;
  • Session Sharing unterstützt wird;
  • ECMP zu unterschiedlichen Instanzen führt.

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:

  • Client;
  • Server;
  • Router;
  • Firewallknoten;
  • Load Balancer;
  • Cloud-Logs;
  • SIEM;
  • Paketaufzeichnungssystem.

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:

  • Quelle;
  • Ziel;
  • Ports;
  • Protokoll;
  • Eingangs- und Ausgangsschnittstelle;
  • Pakete;
  • Bytes;
  • Start- und Endzeit;
  • TCP-Flags;
  • nächste Hops;
  • zulassende oder verweigernde Aktion.

Einschränkungen:

  • Sampling kann einzelne Datenflüsse übersehen;
  • Export erfolgt möglicherweise verzögert;
  • NAT kann unterschiedliche Datensätze erzeugen;
  • Flow Logs zeigen nicht immer den vollständigen Paketinhalt;
  • mehrere Geräte können denselben Datenfluss unterschiedlich darstellen;
  • fehlender Flow-Datensatz beweist nicht zwingend fehlenden Verkehr.

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

  • Hin- und Rückweg als automatisch identisch betrachten.
  • Nur eine Traceroute vom Client ausführen.
  • Traceroute-Ergebnis als vollständigen Pfadnachweis bewerten.
  • Nur die Routingtabelle der Firewall prüfen.
  • Lokale Serverroute und Standardgateway ignorieren.
  • Längstes Präfix übersehen.
  • Policy-Based Routing nicht prüfen.
  • ECMP nur auf dem Hinweg betrachten.
  • Per-Flow-ECMP mit garantierter Ende-zu-Ende-Symmetrie gleichsetzen.
  • Mehrere virtuelle Kontexte einer Firewall übersehen.
  • Sessiontabelle nur auf einem Clusterknoten prüfen.
  • Konfigurations- und Zustandssynchronisation verwechseln.
  • [UNREPLIED] automatisch als Serverausfall interpretieren.
  • ESTABLISHED als erfolgreichen Anwendungsnachweis bewerten.
  • Generischen Conntrack-Zustand und TCP-Zustand verwechseln.
  • Original- und Antwort-Tupel nicht vergleichen.
  • Vor-NAT- und Nach-NAT-Adressen verwechseln.
  • NAT-Besitzer nicht bestimmen.
  • Bestehende und neue Sitzungen nicht unterscheiden.
  • Alle Sessions vorsorglich löschen.
  • Conntrack-Tabelle vollständig leeren.
  • Timeouts ohne zeitlichen Nachweis verändern.
  • Conntrack-Maximalwert ohne Speicherprüfung erhöhen.
  • INVALID pauschal erlauben.
  • Stateful Inspection deaktivieren.
  • TCP State Bypass als Standardlösung einsetzen.
  • Sicherheitsauswirkungen von Stateless-Betrieb ignorieren.
  • Direct Server Return als Fehler behandeln, obwohl es Teil des Designs ist.
  • Hardware-Offloading bei Capture und Zählern ignorieren.
  • Nur eine Richtung der Paket- und Bytezähler auswerten.
  • Flow Logs ohne Berücksichtigung von Sampling bewerten.
  • Uhren und Zeitzonen nicht synchronisieren.
  • Mehrere Variablen gleichzeitig verändern.
  • Nur den Porttest und nicht die ursprüngliche Anwendung verifizieren.
  • Temporäre Captures und Diagnoseprotokollierung aktiv lassen.

Verifikation

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

  • Client verwendet die erwartete Quelladresse;
  • Server verwendet die erwartete Antwortadresse;
  • Quell- und Zielports entsprechen dem Sollzustand;
  • Hinweg entspricht dem freigegebenen Design;
  • Rückweg entspricht dem freigegebenen Design;
  • alle zustandsabhängigen Komponenten sehen beide Richtungen;
  • richtige Firewall- und Clusterknoten verarbeiten die Sitzung;
  • Sitzung wird im richtigen virtuellen Kontext angelegt;
  • NAT-Übersetzung ist in beiden Richtungen konsistent;
  • TCP-Handshake wird vollständig abgeschlossen;
  • UDP-Antwort wird der Pseudositzung zugeordnet;
  • ICMP-Fehler werden korrekt zugeordnet;
  • Sessiontabelle zeigt Pakete und Bytes in beiden Richtungen;
  • Sitzung erreicht den erwarteten Zustand;
  • kein Invalid-State-Drop entsteht;
  • Conntrack-Auslastung bleibt innerhalb der Baseline;
  • Insert-Failed- und Drop-Zähler steigen nicht;
  • State-Synchronisation ist fehlerfrei;
  • bestehende und neue Sitzungen verhalten sich erwartungsgemäß;
  • Failoververhalten entspricht dem Sollzustand;
  • IPv4 und IPv6 funktionieren, sofern erforderlich;
  • ursprüngliche Anwendung funktioniert;
  • weitere repräsentative Quellen funktionieren;
  • weitere repräsentative Ziele funktionieren;
  • kein unbeabsichtigter Bypass der Sicherheitskontrolle entstand;
  • temporäre Diagnosen wurden zurückgenommen;
  • Ursache, Maßnahme und Prävention wurden dokumentiert.

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

  • exakte Fehlermeldung dokumentiert
  • Datum, Uhrzeit und Zeitzone erfasst
  • betroffene Anwendung bestimmt
  • Quelladresse erfasst
  • Quellport erfasst
  • Zieladresse erfasst
  • Zielport erfasst
  • Protokoll bestimmt
  • IPv4 und IPv6 unterschieden
  • Originalrichtung dokumentiert
  • Antwortrichtung dokumentiert
  • Vor-NAT-Tupel dokumentiert
  • Nach-NAT-Tupel dokumentiert
  • Fehlerumfang bestimmt
  • erwarteten Hinweg dokumentiert
  • tatsächlichen Hinweg nachgewiesen
  • erwarteten Rückweg dokumentiert
  • tatsächlichen Rückweg nachgewiesen
  • lokale Clientroute geprüft
  • lokale Serverroute geprüft
  • Standardgateways geprüft
  • längstes passendes Präfix geprüft
  • Policy Routing geprüft
  • VRFs und Routinginstanzen geprüft
  • dynamische Routen geprüft
  • ECMP geprüft
  • ECMP-Hash-Verfahren berücksichtigt
  • SD-WAN-Pfadauswahl geprüft
  • VPN- und Tunnelpfade geprüft
  • Load Balancer berücksichtigt
  • Direct Server Return berücksichtigt
  • zustandsabhängige Komponenten erfasst
  • richtige Firewall bestimmt
  • aktiven Clusterknoten bestimmt
  • virtuellen Firewallkontext bestimmt
  • Sessiontabellen aller möglichen Knoten geprüft
  • Sitzungs-ID dokumentiert
  • Session Owner bestimmt
  • generischen Tracking-Zustand geprüft
  • TCP-Zustand geprüft
  • UDP-Pseudositzung berücksichtigt
  • ICMP-Zuordnung berücksichtigt
  • [UNREPLIED] oder vergleichbaren Zustand geprüft
  • [ASSURED] oder vergleichbaren Zustand geprüft
  • Pakete je Richtung verglichen
  • Bytes je Richtung verglichen
  • Timeout geprüft
  • Sitzungsendgrund geprüft
  • NAT-Sitzung geprüft
  • NAT-Besitzer bestimmt
  • Cluster-State-Synchronisation geprüft
  • Konfigurationssynchronisation getrennt geprüft
  • letzten Failoverzeitpunkt geprüft
  • Conntrack-Anzahl erfasst
  • Conntrack-Maximalwert erfasst
  • Conntrack-Auslastung berechnet
  • Conntrack-Statistiken geprüft
  • Insert-Failed-Zähler geprüft
  • Drop- und Early-Drop-Zähler geprüft
  • Hardware-Offloading berücksichtigt
  • Flow Logs geprüft
  • Paketaufzeichnung am Client durchgeführt, sofern erforderlich
  • Paketaufzeichnung an der Firewall durchgeführt, sofern erforderlich
  • Paketaufzeichnung am Server durchgeführt, sofern erforderlich
  • Zeitstempel korreliert
  • Hypothese formuliert
  • Gegenbeweis definiert
  • Risiko dokumentiert
  • Rückweg dokumentiert
  • nur eine kontrollierte Maßnahme durchgeführt
  • vollständig neue Sitzung getestet
  • mehrere Verbindungen bei ECMP geprüft
  • ursprüngliche Anwendung verifiziert
  • repräsentative weitere Datenflüsse geprüft
  • temporäre Diagnosen zurückgenommen
  • Ursache und Prävention dokumentiert

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.

Back to top