9. TCP, UDP, Ports, Firewall, NAT und Proxy

9.1 Ports, Sockets, Listener und gebundene Adressen
9.2 TCP-Handshake, Timeouts und TCP Reset
9.3 UDP-Diagnose und ICMP-Fehlermeldungen
9.4 Lokale Host-Firewall prüfen
9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection
9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking
9.7 Ephemeral Ports und Verbindungsgrenzen
9.8 NAT, Portweiterleitung und Hairpin NAT im Datenpfad

9.1 Ports, Sockets, Listener und gebundene Adressen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose von Ports, Sockets, Listenern und gebundenen IP-Adressen unter Windows, Linux, macOS sowie in Container- und Kubernetes-Umgebungen.

Nach der Bearbeitung muss nachvollziehbar geprüft werden können:

welches Transportprotokoll verwendet wird;
auf welchem Port ein Dienst lauschen soll;
an welche lokale Adresse der Socket gebunden ist;
welcher Prozess den Socket besitzt;
ob der Socket im richtigen Netzwerk-Namespace existiert;
ob ein lokaler Listener tatsächlich erreichbar ist;
ob Firewall, NAT, Portweiterleitung oder Proxy beteiligt sind;
ob ein Portkonflikt vorliegt;
ob TCP- und UDP-Verhalten richtig unterschieden werden;
ob die Anwendung auf Protokollebene korrekt antwortet.

Ein sichtbarer Listener beweist nur, dass im untersuchten Netzwerk-Namespace ein Socket gebunden wurde. Er beweist nicht, dass der Dienst von einem entfernten Client erreichbar ist oder auf Anwendungsebene korrekt funktioniert.

Sicherheits- und Wirkungsklassen

Kennzeichnung	Bedeutung
LESEND	Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV	Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV	Kann interne Adressen, Prozesse, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND	Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO	Kann bestehende Verbindungen oder Dienste beeinträchtigen.

Socket- und Prozesslisten können interne Dienstnamen, Benutzerkonten, Zieladressen und aktive Kommunikationsbeziehungen enthalten. Ausgaben und Netzwerkaufzeichnungen müssen entsprechend geschützt werden.

Grundbegriffe

Begriff	Bedeutung
Port	Numerische Kennzeichnung eines Dienstendpunkts innerhalb eines Transportprotokolls.
Socket	Vom Betriebssystem verwalteter Kommunikationsendpunkt.
Listener	TCP-Socket, der auf neue eingehende Verbindungen wartet.
Bind	Zuordnung eines Sockets zu einer lokalen IP-Adresse und einem lokalen Port.
Local Address	Lokale IP-Adresse, an die der Socket gebunden ist.
Local Port	Lokaler TCP- oder UDP-Port des Sockets.
Remote Address	Adresse der Gegenstelle einer bestehenden Verbindung.
Remote Port	Port der Gegenstelle einer bestehenden Verbindung.
Wildcard-Bindung	Bindung an alle geeigneten lokalen Adressen, beispielsweise `0.0.0.0`.
Loopback-Bindung	Bindung ausschließlich an die lokale Rückschleifenschnittstelle.
Netzwerk-Namespace	Isolierte Netzwerksicht eines Systems oder Containers mit eigenen Schnittstellen, Routen und Sockets.

Ein Port ist nicht unabhängig vom Transportprotokoll zu betrachten. TCP-Port 53 und UDP-Port 53 sind unterschiedliche Endpunkte und können von unterschiedlichen Sockets verwendet werden.

Portnummern und Portbereiche

TCP- und UDP-Portnummern besitzen einen Wertebereich von 0 bis 65535.

Bereich	IANA-Bezeichnung	Typische Verwendung
`0–1023`	System Ports	Standardisierte oder systemnahe Dienste
`1024–49151`	User Ports	Registrierte Anwendungsdienste
`49152–65535`	Dynamic and/or Private Ports	Dynamische Clientports und private Verwendung

Port 0 besitzt eine besondere Bedeutung und wird nicht wie ein normaler Dienstport verwendet. Eine Anwendung kann beim Binden an Port 0 das Betriebssystem einen freien lokalen Port auswählen lassen.

Auf Unix-artigen Systemen erfordert das Binden niedriger Ports häufig erhöhte Berechtigungen oder eine Fähigkeit wie CAP_NET_BIND_SERVICE. Das genaue Verhalten ist jedoch vom Betriebssystem und dessen Konfiguration abhängig.

Eine Eintragung im IANA-Verzeichnis bedeutet nicht, dass ein Port ausschließlich von dem dort genannten Dienst verwendet werden darf. Für die Diagnose ist die tatsächlich wirksame Konfiguration entscheidend.

Socket- und Verbindungsmodell

Ein TCP-Listener wird im Wesentlichen durch folgende Angaben beschrieben:

Transportprotokoll + lokale IP-Adresse + lokaler Port

Beispiel:

TCP 192.0.2.25:443

Eine aufgebaute TCP-Verbindung wird durch beide Endpunkte unterschieden:

Transportprotokoll
lokale IP-Adresse
lokaler Port
entfernte IP-Adresse
entfernter Port

Beispiel:

TCP
lokal:   192.0.2.25:443
remote:  198.51.100.40:53124

Ein einzelner TCP-Listener auf Port 443 kann deshalb viele gleichzeitige Verbindungen bedienen. Die einzelnen Verbindungen unterscheiden sich mindestens durch die entfernte Adresse oder den entfernten Port.

UDP besitzt keinen TCP-Verbindungsaufbau und keinen TCP-Zustand LISTEN. Ein UDP-Endpunkt kann dennoch an eine lokale Adresse und einen lokalen Port gebunden sein und Datagramme empfangen.

Gebundene Adressen richtig interpretieren

Bindung	Bedeutung
`127.0.0.1:8080`	Nur über IPv4-Loopback des eigenen Systems erreichbar
`192.0.2.25:8080`	Nur über diese konkrete IPv4-Adresse erreichbar
`0.0.0.0:8080`	IPv4-Wildcard; Bindung an alle geeigneten lokalen IPv4-Adressen
`[::1]:8080`	Nur über IPv6-Loopback erreichbar
`[::]:8080`	IPv6-Wildcard; Bindung an alle geeigneten lokalen IPv6-Adressen
`<Container-IP>:8080`	Innerhalb des betreffenden Container-Netzwerks gebunden
`<Pod-IP>:8080`	Innerhalb des Kubernetes-Pod-Netzwerks gebunden

Eine Bindung an 0.0.0.0 bedeutet nicht, dass ein Client die Zieladresse 0.0.0.0 verwenden soll. Der Client verwendet eine konkrete erreichbare Adresse des Servers.

Bei einer Bindung an [::] darf nicht ungeprüft angenommen werden, dass derselbe Socket auch IPv4-Verbindungen akzeptiert. Das Verhalten hängt unter anderem vom Betriebssystem, der Socketoption IPV6_V6ONLY und der Anwendung ab. IPv4 und IPv6 müssen getrennt geprüft werden.

Loopback-, Wildcard- und spezifische Bindung

Loopback-Bindung

127.0.0.1:8080
[::1]:8080

Der Dienst ist grundsätzlich nur vom eigenen Netzwerk-Namespace erreichbar. Das ist beispielsweise für lokale Backends hinter einem Reverse Proxy sinnvoll.

Ein entfernter Client kann diesen Listener nicht direkt erreichen.

Wildcard-Bindung

0.0.0.0:8080
[::]:8080

Der Dienst lauscht grundsätzlich auf allen dafür geeigneten Adressen der entsprechenden Protokollfamilie. Dazu können gehören:

LAN-Schnittstellen;
WLAN-Schnittstellen;
VPN-Schnittstellen;
öffentliche Schnittstellen;
virtuelle Switches;
Container-Bridges.

Ob der Dienst tatsächlich von jedem Netz erreichbar ist, wird zusätzlich durch Routing, Firewall, NAT, Sicherheitsgruppen und vorgelagerte Systeme bestimmt.

Bindung an eine konkrete Adresse

192.0.2.25:8080

Der Dienst nimmt Verbindungen nur über diese lokale Adresse an.

Die Bindung kann beim Dienststart fehlschlagen, wenn:

die Adresse nicht mehr am System vorhanden ist;
die Schnittstelle noch nicht verfügbar ist;
DHCP eine andere Adresse vergeben hat;
die Adresse erst durch einen später gestarteten VPN-Tunnel entsteht;
die Anwendung vor der Netzwerkkonfiguration gestartet wird;
sich der Dienst in einem anderen Netzwerk-Namespace befindet.

TCP-Zustände

Zustand	Einordnung
`LISTEN`	Lokaler Socket wartet auf neue TCP-Verbindungen.
`SYN-SENT`	Verbindungsaufbau wurde begonnen; Antwort steht noch aus.
`SYN-RECEIVED`	Ein SYN wurde empfangen und der Aufbau ist noch nicht abgeschlossen.
`ESTABLISHED`	TCP-Verbindung ist aufgebaut.
`FIN-WAIT-1`	Lokale Seite hat das Schließen begonnen.
`FIN-WAIT-2`	Lokale Seite wartet nach eigenem FIN auf das FIN der Gegenstelle.
`CLOSE-WAIT`	Gegenstelle hat geschlossen; lokale Anwendung muss noch schließen.
`LAST-ACK`	Lokale Seite wartet auf die Bestätigung ihres abschließenden FIN.
`TIME-WAIT`	Geschlossene Verbindung wird vorübergehend zur sicheren Protokollabwicklung vorgehalten.
`CLOSED`	Keine aktive TCP-Verbindung.

Viele Einträge in TIME-WAIT sind nicht automatisch ein Fehler. Sie können bei kurzlebigen Verbindungen normal sein.

Dauerhaft viele CLOSE-WAIT-Sockets können darauf hindeuten, dass die lokale Anwendung geschlossene Verbindungen nicht ordnungsgemäß freigibt. Dieser Befund muss über Zeitverlauf, Prozesszustand und Anwendungstelemetrie bestätigt werden.

Was ein Listener beweist – und was nicht

Ein Listener beweist:

ein Socket wurde im untersuchten Netzwerk-Namespace angelegt;
der Socket ist an einen lokalen Port gebunden;
das Betriebssystem führt ihn als empfangsbereiten TCP-Socket;
ein Prozess oder Kernelbestandteil besitzt den Socket.

Ein Listener beweist nicht:

dass die Firewall eingehende Verbindungen erlaubt;
dass Routing zum Server funktioniert;
dass NAT oder Portweiterleitung korrekt sind;
dass ein Load Balancer das richtige Ziel verwendet;
dass die Anwendung nach dem Verbindungsaufbau korrekt antwortet;
dass TLS, HTTP, DNS oder ein anderes Anwendungsprotokoll funktioniert;
dass der Dienst unter dem erwarteten Namen erreichbar ist;
dass IPv4 und IPv6 gleichermaßen funktionieren;
dass der Listener im richtigen Container oder Netzwerk-Namespace existiert.

Erwarteten Endpunkt festlegen

Vor der Diagnose müssen mindestens folgende Sollangaben dokumentiert werden:

Dienst:
<Anwendung oder Dienstname>

Transportprotokoll:
<TCP oder UDP>

Erwartete lokale Adresse:
<Loopback, konkrete Adresse oder Wildcard>

Erwarteter lokaler Port:
<Portnummer>

Erwarteter Netzwerk-Namespace:
<Host, Container, Pod oder anderer Namespace>

Erwartete Erreichbarkeit:
<nur lokal, internes Netz, VPN oder öffentlich>

Vorgelagerte Komponenten:
<Firewall, NAT, Reverse Proxy, Load Balancer oder Service>

Ohne diese Sollangaben kann ein sichtbarer Socket nicht zuverlässig als richtig oder falsch bewertet werden.

Windows: TCP-Listener erfassen

LESEND

Alle TCP-Verbindungen und Listener:

Get-NetTCPConnection

Nur TCP-Listener:

Get-NetTCPConnection `
  -State Listen |
  Sort-Object LocalPort, LocalAddress

Bestimmten lokalen Port prüfen:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443

Ausgabe auf wesentliche Felder begrenzen:

Get-NetTCPConnection `
  -State Listen |
  Select-Object `
    LocalAddress,
    LocalPort,
    State,
    OwningProcess |
  Sort-Object LocalPort, LocalAddress

Zu prüfen sind:

LocalAddress;
LocalPort;
State;
OwningProcess;
mehrere Listener auf demselben Port;
getrennte IPv4- und IPv6-Einträge;
unerwartete Loopback-Bindung;
unerwartete Wildcard-Bindung.

Windows: Prozess eines TCP-Listeners bestimmen

LESEND

Beispiel für Port 443:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443 |
  ForEach-Object {
    $connection = $_
    $process = Get-Process `
      -Id $connection.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $connection.LocalAddress
      LocalPort    = $connection.LocalPort
      ProcessId    = $connection.OwningProcess
      ProcessName  = $process.ProcessName
      ProcessPath  = $process.Path
    }
  }

Einen bekannten Prozess prüfen:

Get-Process `
  -Id 1234

Die ausführbare Datei kann abhängig von Prozessschutz und Berechtigungen nicht immer angezeigt werden.

Windows: Prozess einem Dienst zuordnen

LESEND

$processId = 1234

Get-CimInstance `
  -ClassName Win32_Service `
  -Filter "ProcessId = $processId" |
  Select-Object `
    Name,
    DisplayName,
    State,
    StartMode,
    ProcessId,
    PathName

Wenn kein Dienst zurückgegeben wird, kann der Prozess beispielsweise:

interaktiv gestartet worden sein;
durch einen Task gestartet worden sein;
zu einer Desktopanwendung gehören;
Teil einer Container- oder Virtualisierungsumgebung sein;
durch einen anderen Dienstprozess verwaltet werden.

Windows: UDP-Endpunkte erfassen

LESEND

Alle UDP-Endpunkte:

Get-NetUDPEndpoint |
  Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

Get-NetUDPEndpoint `
  -LocalPort 53

UDP-Endpunkt mit Prozessinformationen anzeigen:

Get-NetUDPEndpoint `
  -LocalPort 53 |
  ForEach-Object {
    $endpoint = $_
    $process = Get-Process `
      -Id $endpoint.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $endpoint.LocalAddress
      LocalPort    = $endpoint.LocalPort
      ProcessId    = $endpoint.OwningProcess
      ProcessName  = $process.ProcessName
    }
  }

Das Vorhandensein eines UDP-Endpunkts beweist noch nicht, dass eine gesendete Anfrage verarbeitet oder beantwortet wird.

Windows: netstat als ergänzende Sicht

LESEND

netstat -ano

Nur TCP-Listener:

netstat -ano -p tcp

UDP-Endpunkte:

netstat -ano -p udp

Wiederholte Aktualisierung alle fünf Sekunden:

netstat -ano 5

Beenden mit Strg+C.

Wichtige Optionen:

Option	Bedeutung
`-a`	Zeigt aktive Verbindungen und Listener.
`-n`	Zeigt numerische Adressen und Ports.
`-o`	Zeigt die zugehörige Prozess-ID.
`-p tcp`	Begrenzt die Anzeige auf TCP.
`-p udp`	Begrenzt die Anzeige auf UDP.

Namensauflösung sollte für die erste Diagnose mit -n vermieden werden. Anderenfalls können DNS-Verzögerungen die Ausgabe verlangsamen oder Adressen durch Namen verdecken.

Windows: lokale IP-Adressen bestätigen

LESEND

Get-NetIPConfiguration

Alle verwendbaren IP-Adressen:

Get-NetIPAddress |
  Where-Object AddressState -eq "Preferred" |
  Sort-Object InterfaceIndex, AddressFamily

Eine Bindung an eine konkrete Adresse ist nur sinnvoll, wenn diese Adresse tatsächlich im richtigen Netzwerk-Compartment und auf der vorgesehenen Schnittstelle vorhanden ist.

Windows: Kernel- und HTTP.sys-Zuordnungen prüfen

Ein Port kann durch einen Kernelbestandteil oder eine gemeinsame HTTP-Infrastruktur verwaltet werden. Der sichtbare Besitzer muss daher nicht unmittelbar der erwartete Anwendungsprozess sein.

Bei HTTP- oder HTTPS-Diensten unter Windows:

LESEND

netsh http show servicestate

Registrierte URL-Zuordnungen:

netsh http show urlacl

Registrierte TLS-Zertifikatbindungen:

netsh http show sslcert

Portproxy-Konfiguration:

netsh interface portproxy show all

Zu prüfen sind:

welcher Dienst die URL registriert hat;
welcher Prozess eine HTTP.sys-Anforderungswarteschlange verwendet;
ob eine Portproxy-Regel besteht;
ob der sichtbare Hostport an ein anderes Ziel weiterleitet;
ob der Prozessbesitzer nur als System erscheint.

Eine URL-Reservierung allein beweist keinen aktiven Listener.

Linux: TCP- und UDP-Sockets mit ss prüfen

ss ist unter Linux das bevorzugte Werkzeug zur Anzeige von Socketinformationen.

LESEND

TCP-Listener:

ss -lnt

TCP-Listener einschließlich Prozessinformationen:

sudo ss -lntp

UDP-Endpunkte:

sudo ss -lnup

TCP- und UDP-Endpunkte gemeinsam:

sudo ss -lntup

Bestimmten TCP-Port prüfen:

sudo ss -lntp 'sport = :443'

Bestimmten UDP-Port prüfen:

sudo ss -lnup 'sport = :53'

Alle TCP-Verbindungen und Zustände:

ss -tan

Zusammenfassung:

ss -s

Wichtige Optionen:

Option	Bedeutung
`-l`	Nur lauschende beziehungsweise unverbundene Endpunkte
`-n`	Numerische Adressen und Ports
`-t`	TCP
`-u`	UDP
`-p`	Prozessinformationen
`-a`	Alle Sockets
`-x`	Unix-Domain-Sockets

Prozessinformationen können erhöhte Berechtigungen erfordern.

Linux: Prozess mit lsof bestimmen

LESEND

Alle lauschenden TCP-Sockets:

sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

Bestimmten UDP-Port prüfen:

sudo lsof -nP -iUDP:53

Wichtige Optionen:

Option	Bedeutung
`-n`	Keine Namensauflösung der IP-Adressen
`-P`	Keine Umwandlung von Ports in Dienstnamen
`-iTCP`	TCP-Sockets
`-iUDP`	UDP-Sockets
`-sTCP:LISTEN`	Nur TCP-Listener

Danach können Prozess und Dienst untersucht werden:

ps -fp <PID>

Bei einem systemd-Dienst:

systemctl status <Dienstname>

Prozessbaum:

pstree -p <PID>

Falls pstree nicht installiert ist:

ps -ef --forest

Linux: Netzwerkadressen und Namespace prüfen

LESEND

ip address show

Kompakte Ansicht:

ip -brief address

Netzwerk-Namespaces anzeigen:

ip netns list

Socketansicht eines bekannten Prozess-Namespace:

sudo nsenter \
  -t <PID> \
  -n \
  ss -lntup

Dieser Test ist besonders wichtig, wenn ein Prozess in einem Container oder separaten Netzwerk-Namespace läuft.

Ein Listener innerhalb eines Container-Namespace muss nicht als normaler Listener in der Sockettabelle des Hosts erscheinen.

macOS: TCP- und UDP-Sockets prüfen

Linux-ss ist unter macOS standardmäßig nicht verfügbar. Für die Prozesszuordnung ist lsof besonders geeignet.

LESEND

Alle TCP-Listener:

sudo lsof -nP -iTCP -sTCP:LISTEN

Bestimmten TCP-Port prüfen:

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

UDP-Endpunkte:

sudo lsof -nP -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof -nP -iUDP:53

TCP-Socketzustände mit netstat:

netstat -anv -p tcp

UDP-Sockets:

netstat -anv -p udp

Lokale Netzwerkschnittstellen:

ifconfig

Routing- und Schnittstelleninformationen:

route -n get default

Für die Zuordnung eines Ports zu einem Prozess sollte unter macOS nicht allein auf netstat vertraut werden. lsof liefert dafür normalerweise die geeignetere Sicht.

Unix-Domain-Sockets und andere lokale IPC-Endpunkte

Nicht jede lokale Dienstkommunikation verwendet einen TCP- oder UDP-Port.

Typische Alternativen sind:

Unix-Domain-Sockets;
Windows Named Pipes;
Shared Memory;
lokale Message Queues;
anwendungsspezifische IPC-Mechanismen.

Linux:

sudo ss -lxnp

Linux und macOS:

sudo lsof -U

Ein Reverse Proxy kann beispielsweise über einen Unix-Domain-Socket mit seinem Backend kommunizieren. In diesem Fall ist für die Backendverbindung kein TCP-Listener sichtbar.

Die Diagnose muss dann zusätzlich prüfen:

Pfad des Sockets;
Dateiberechtigungen;
Besitzer und Gruppe;
Existenz nach dem Dienststart;
Namespace oder Container;
SELinux- beziehungsweise AppArmor-Richtlinien;
Konfiguration von Proxy und Backend.

Portkonflikte erkennen

Typische Meldungen eines Bindungsfehlers sind:

Address already in use
EADDRINUSE
WSAEADDRINUSE
Only one usage of each socket address is normally permitted

Mögliche Ursachen:

ein anderer Prozess besitzt bereits denselben Endpunkt;
eine alte Instanz der Anwendung läuft noch;
zwei Dienste verwenden dieselbe konfigurierte Adresse und denselben Port;
ein Wildcard-Listener kollidiert mit einer spezifischen Bindung;
IPv4- und IPv6-Verhalten wurde falsch eingeschätzt;
ein Dienst wird doppelt durch Service Manager und manuellen Start gestartet;
ein Container veröffentlicht bereits denselben Hostport;
eine Portproxy- oder Kernelkomponente ist beteiligt.

Windows:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 8080

Get-NetUDPEndpoint `
  -LocalPort 8080

Linux:

sudo ss -lntup 'sport = :8080'

macOS:

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN

Ein Port kann unter bestimmten Bedingungen absichtlich durch mehrere Prozesse oder Sockets gemeinsam verwendet werden. Beispiele sind Socketaktivierung, SO_REUSEPORT, gemeinsam verwaltete Kernel-Listener oder Clustermechanismen. Deshalb darf ein ungewöhnlicher Mehrfachbefund nicht ohne Prüfung als Fehler bewertet werden.

Weitere typische Bindungsfehler

Meldung oder Fehler	Mögliche Einordnung
`Address already in use`	Endpunkt wird bereits verwendet.
`Permission denied`	Fehlende Berechtigung, Sicherheitsrichtlinie oder geschützter Port.
`EACCES`	Zugriff auf Adresse oder Port verweigert.
`Cannot assign requested address`	Konfigurierte lokale Adresse ist nicht vorhanden.
`EADDRNOTAVAIL`	Lokale Bindungsadresse steht nicht zur Verfügung.
`Connection refused`	Zielsystem lehnt aktiv ab; häufig kein passender Listener.
Timeout	Keine verwertbare Antwort; Paketverlust, Filterung, Routing oder Überlastung möglich.
Verbindung erfolgreich, Protokollfehler	Transport funktioniert; Anwendung oder Protokollkonfiguration fehlerhaft.

Die Zuordnung ist eine erste Einordnung und kein alleiniger Ursachennachweis.

Lokalen TCP-Endpunkt testen

Ein lokaler Test muss zur tatsächlichen Bindung passen.

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 8080 `
  -InformationLevel Detailed

Test gegen die konkrete Schnittstellenadresse:

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 8080 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 127.0.0.1 8080

nc -vz 192.0.2.25 8080

Ein erfolgreicher TCP-Test beweist nur, dass der TCP-Verbindungsaufbau funktioniert hat. Er beweist nicht, dass die Anwendung ein gültiges Ergebnis liefert.

Test-NetConnection -Port prüft TCP. Es ist kein allgemeiner UDP-Test.

Loopback und Schnittstellenadresse getrennt testen

Die folgenden Befunde müssen unterschieden werden:

Loopback-Test	Test gegen Serveradresse	Mögliche Einordnung
erfolgreich	erfolgreich	Listener ist lokal über beide Pfade erreichbar
erfolgreich	fehlgeschlagen	falsche Bindung, lokale Firewall oder Adressproblem
fehlgeschlagen	erfolgreich	Dienst lauscht nur auf konkreter Adresse
fehlgeschlagen	fehlgeschlagen	kein Listener, falscher Port, falsches Protokoll oder Dienstfehler

Ein Test gegen localhost kann je nach Namensauflösung zuerst ::1 oder 127.0.0.1 verwenden. Für eine eindeutige Diagnose müssen IPv4- und IPv6-Adressen ausdrücklich getestet werden.

Windows:

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 8080

Test-NetConnection `
  -ComputerName "::1" `
  -Port 8080

Linux und macOS:

nc -4 -vz 127.0.0.1 8080

nc -6 -vz ::1 8080

Test von einem entfernten Client

Der Test muss von einem System erfolgen, das den realen Zugriffspfad möglichst genau abbildet.

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz app.example.test 443

Getrennte Prüfung einer bekannten IP-Adresse:

nc -vz 192.0.2.25 443

Zu dokumentieren sind:

verwendeter Zielname;
aufgelöste Zieladresse;
Quelladresse;
Zielport;
TCP-Ergebnis;
Zeitpunkt;
Teststandort;
VPN-Zustand;
IPv4 oder IPv6;
direkter oder weitergeleiteter Pfad.

Nur autorisierte Ziele und Ports dürfen geprüft werden. Breite Portscans sind für die Diagnose eines bekannten Dienstendpunkts normalerweise nicht erforderlich.

Anwendungsprotokoll statt nur Port prüfen

Nach erfolgreichem TCP-Verbindungsaufbau muss das erwartete Anwendungsprotokoll getestet werden.

HTTP:

curl -v http://127.0.0.1:8080/

HTTPS mit korrektem Hostnamen und festgelegter Zieladresse:

curl -v \
  --resolve app.example.test:443:192.0.2.25 \
  https://app.example.test/

TLS mit Server Name Indication:

openssl s_client \
  -connect 192.0.2.25:443 \
  -servername app.example.test

DNS über UDP:

dig @192.0.2.53 example.test A

DNS über TCP:

dig @192.0.2.53 example.test A +tcp

Ein erfolgreicher TCP-Test auf Port 443 beweist beispielsweise nicht:

dass der TLS-Handshake funktioniert;
dass das richtige Zertifikat geliefert wird;
dass SNI korrekt verarbeitet wird;
dass HTTP eine gültige Antwort liefert;
dass der erwartete virtuelle Host ausgewählt wird.

UDP richtig prüfen

UDP besitzt keinen TCP-Handshake. Deshalb kann ein allgemeiner UDP-Porttest kein gleichwertiges Ergebnis wie ein erfolgreicher TCP-Verbindungsaufbau liefern.

Zu prüfen sind:

existiert ein lokaler UDP-Endpunkt?
verlässt die Anfrage den Client?
erreicht sie den Server?
antwortet die Anwendung?
erreicht die Antwort den Client?
wird ein ICMP-Fehler zurückgegeben?
wird ICMP unterwegs gefiltert?
wird das richtige Anwendungsprotokoll verwendet?

Ein Aufruf wie:

nc -vzu 192.0.2.53 53

kann Datagramme erzeugen, liefert aber ohne geeignete Anwendungsantwort keinen belastbaren Nachweis für einen funktionsfähigen UDP-Dienst.

Für UDP ist ein protokollspezifischer Test vorzuziehen, beispielsweise:

dig für DNS;
ntpq, chronyc oder ein geeigneter NTP-Test für NTP;
ein herstellerspezifischer Testclient;
eine begrenzte Netzwerkaufzeichnung.

Firewall und Listener getrennt betrachten

Die Diagnoseebenen sind voneinander zu trennen:

Anwendungsprozess
→ lokaler Socket
→ lokale Firewall
→ Routing und Netzwerk
→ externe Firewall oder NAT
→ Client

Mögliche Befunde:

Dienst läuft, aber kein Socket wurde gebunden;
Socket existiert, lokale Firewall blockiert;
lokale Prüfung funktioniert, entfernte Prüfung schlägt fehl;
entfernte Verbindung erreicht den Server, Antwortweg fehlt;
NAT leitet auf einen falschen Hostport weiter;
Load Balancer verwendet den falschen Backendport;
Reverse Proxy erreicht sein lokales Backend nicht.

Ein laufender Dienststatus beweist keinen Listener. Ein Listener beweist keine Firewallfreigabe.

Windows-Firewallbezug lesend prüfen

Aktive eingehende Regeln anzeigen:

LESEND

Get-NetFirewallRule `
  -Enabled True `
  -Direction Inbound |
  Select-Object `
    DisplayName,
    Action,
    Profile,
    Direction

Portfilter zu einer bekannten Regel:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallPortFilter

Adressfilter:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallAddressFilter

Anwendungsfilter:

Get-NetFirewallRule `
  -DisplayName "<Regelname>" |
  Get-NetFirewallApplicationFilter

Zu prüfen sind:

TCP oder UDP;
lokaler Port;
lokales Programm;
lokales und entferntes Adressnetz;
aktives Firewallprofil;
eingehende oder ausgehende Richtung;
Block- und Zulassungsregeln;
durch Gruppenrichtlinie gelieferte Regeln.

Die Firewall darf nicht vorsorglich vollständig deaktiviert werden. Eine Änderung muss auf den nachgewiesenen Dienst, Port, Pfad und Zeitraum begrenzt werden.

Reverse Proxy und Backendlistener

Ein typischer Aufbau ist:

Client
→ Reverse Proxy auf 0.0.0.0:443
→ Backend auf 127.0.0.1:8080

In diesem Fall müssen zwei getrennte Endpunkte geprüft werden:

externer Listener des Reverse Proxys;
interner Listener des Backends.

Mögliche Fehler:

Proxy lauscht nicht auf Port 443;
Backend lauscht nicht auf Port 8080;
Backend ist nur über IPv6 erreichbar, Proxy verwendet IPv4;
Proxy verwendet den falschen Backendport;
Backend befindet sich in einem Container und 127.0.0.1 bezeichnet dort einen anderen Namespace;
Proxy erwartet einen Unix-Domain-Socket;
TLS endet am Proxy, während das Backend fälschlich ebenfalls TLS erwartet;
Health Check und produktiver Zielport unterscheiden sich.

Ein erfolgreicher externer TCP-Verbindungsaufbau beweist nicht, dass das Backend erreichbar ist.

Container und Netzwerk-Namespaces

Container besitzen häufig eine eigene Netzwerksicht. Dabei sind mindestens drei Endpunkte zu unterscheiden:

Anwendungsport im Container
veröffentlichter Port auf dem Host
Port des zugreifenden Clients

Beispiel:

Container: 172.18.0.5:80
Host:      192.0.2.25:8080
Client:    verbindet zu 192.0.2.25:8080

Ein Dienst, der innerhalb des Containers nur an 127.0.0.1:80 gebunden ist, ist über eine normale Portveröffentlichung häufig nicht erreichbar. Für den Zugriff über das Container-Netz muss er üblicherweise an der Containeradresse oder an einer geeigneten Wildcard-Adresse lauschen.

Docker: Portzuordnung prüfen

LESEND

Laufende Container und veröffentlichte Ports:

docker ps \
  --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Portzuordnungen eines Containers:

docker port <Containername>

Ausführliche Portkonfiguration:

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

Netzwerkmodus:

docker inspect \
  <Containername> \
  --format '{{.HostConfig.NetworkMode}}'

Containeradresse:

docker inspect \
  <Containername> \
  --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

Listener innerhalb des Containers, falls ss vorhanden ist:

docker exec \
  <Containername> \
  ss -lntup

Alternativ, falls lsof vorhanden ist:

docker exec \
  <Containername> \
  lsof -nP -i

Fehlende Diagnosewerkzeuge im Container sind kein Nachweis für einen fehlenden Listener. Minimal gehaltene Images enthalten häufig weder ss noch lsof.

Docker-Portveröffentlichung interpretieren

Beispiele für Veröffentlichungen:

127.0.0.1:8080:80

Bedeutung:

Host 127.0.0.1:8080
→ Containerport 80

Dieser Hostport soll nur lokal erreichbar sein.

8080:80

Bedeutung:

Hostport 8080
→ Containerport 80

Ohne ausdrücklich angegebene Hostadresse veröffentlicht Docker den Port standardmäßig auf den Hostadressen. Die genaue Erreichbarkeit hängt zusätzlich von Docker-, Firewall- und IPv4-/IPv6-Konfiguration ab.

Wichtige Unterscheidungen:

EXPOSE im Image veröffentlicht keinen Hostport;
-p beziehungsweise --publish erstellt eine Portveröffentlichung;
-P veröffentlicht dafür vorgesehene Ports automatisch auf Hostports;
Hostport und Containerport können unterschiedlich sein;
Container-IP und Host-IP sind unterschiedliche Adressen;
der Listener im Container muss zum Containerport passen;
im Host-Netzwerkmodus teilt der Container den Netzwerk-Namespace des Hosts;
im Host-Netzwerkmodus werden normale Publish-Optionen nicht wie bei einem Bridge-Netzwerk verwendet.

Ein veröffentlichter Docker-Port muss nicht immer als gewöhnlicher Benutzerprozess-Listener in der erwarteten Host-Socketliste erscheinen. Weiterleitung kann abhängig von Plattform und Konfiguration über Firewall-, NAT- oder Proxymechanismen erfolgen.

Kubernetes: Portebenen unterscheiden

Bei Kubernetes sind mehrere Portangaben auseinanderzuhalten:

Feld	Bedeutung
`containerPort`	Deklarative Portangabe am Container; erzwingt keinen Listener.
`targetPort`	Port, zu dem ein Service im ausgewählten Pod weiterleitet.
`port`	Port des Kubernetes-Service.
`nodePort`	Optionaler Port auf den Clusterknoten.
Pod-Port	Tatsächlicher Socket des Prozesses im Pod.
Ingress-/Gateway-Port	Extern bereitgestellter Listener eines Proxys oder Gateways.

Beispiel:

ports:
  - name: https
    port: 443
    targetPort: 8443

Der Service nimmt Verkehr auf Port 443 an und leitet ihn zum Zielport 8443 weiter.

Wenn targetPort nicht angegeben wird, entspricht er standardmäßig dem Wert von port.

Ein eingetragener containerPort erzeugt keinen Socket und startet keinen Dienst.

Kubernetes-Service und Endpunkte prüfen

LESEND

Services:

kubectl get service \
  --all-namespaces

Bestimmten Service beschreiben:

kubectl describe service \
  <Servicename> \
  -n <Namespace>

Service als YAML anzeigen:

kubectl get service \
  <Servicename> \
  -n <Namespace> \
  -o yaml

EndpointSlices anzeigen:

kubectl get endpointslice \
  -n <Namespace> \
  -l kubernetes.io/service-name=<Servicename> \
  -o wide

Pods und Pod-Adressen:

kubectl get pods \
  -n <Namespace> \
  -o wide

Pod beschreiben:

kubectl describe pod \
  <Podname> \
  -n <Namespace>

Listener im Pod, falls das Werkzeug vorhanden ist:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -- ss -lntup

Bei mehreren Containern im Pod:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -c <Containername> \
  -- ss -lntup

Zu prüfen sind:

Service-Port;
targetPort;
benannter oder numerischer Zielport;
Selektor des Service;
passende Pods;
Ready-Zustand der Pods;
vorhandene EndpointSlices;
tatsächlicher Listener im Pod;
Bindung an Pod-IP oder Wildcard;
NetworkPolicy;
Sidecar- oder Service-Mesh-Proxy;
Ingress- oder Gateway-Konfiguration.

Ein Service ohne passende Endpunkte kann existieren, obwohl kein Backend erreichbar ist.

Besonderheiten von NodePort, Service und Ingress

Ein Kubernetes-NodePort oder ein durch Regeln weitergeleiteter Service-Port muss nicht als klassischer Anwendungsprozess im Zustand LISTEN erscheinen. Je nach Plattform wird der Verkehr beispielsweise durch:

kube-proxy;
nftables;
iptables;
IPVS;
eBPF;
einen Cloud Load Balancer;
ein Ingress-Gateway

weitergeleitet.

Deshalb sind für Kubernetes mehrere Ebenen zu prüfen:

externer Listener oder Load Balancer
→ NodePort beziehungsweise Service
→ EndpointSlice
→ Pod-IP und targetPort
→ Prozess im Pod

Die alleinige Suche nach einem Hostprozess mit dem externen Port kann zu einer falschen Schlussfolgerung führen.

IPv4 und IPv6 getrennt prüfen

Zu prüfen sind:

existiert ein IPv4-Listener?
existiert ein IPv6-Listener?
welche Adresse liefert DNS?
welche Adresse wählt der Client zuerst?
ist die Firewall für beide Protokollfamilien passend konfiguriert?
existiert für beide Adressfamilien eine Route?
liefert die Anwendung auf beiden Pfaden dieselbe Antwort?

Windows:

Get-NetTCPConnection `
  -State Listen `
  -LocalPort 443 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Linux:

sudo ss -lntp 'sport = :443'

Gezielter IPv4-Test:

curl -4 -v https://app.example.test/

Gezielter IPv6-Test:

curl -6 -v https://app.example.test/

Wenn IPv6 fehlschlägt und IPv4 funktioniert, darf der Fehler nicht durch dauerhaftes Abschalten von IPv6 verdeckt werden. Bindung, Routing, DNS und Firewall müssen getrennt untersucht werden.

Temporäre und dynamische Clientports

Beim Aufbau einer ausgehenden Verbindung verwendet der Client normalerweise einen lokalen Quellport aus einem dynamischen Bereich.

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.25:443

Der Serverdienst lauscht auf Port 443. Der Clientport 53124 wurde für diese Verbindung lokal ausgewählt.

Typische Diagnosefehler:

den dynamischen Clientport mit dem Serverport verwechseln;
eine eingehende Firewallregel für den Clientquellport erwarten;
einen TIME-WAIT-Eintrag als Serverlistener interpretieren;
nur nach dem Zielport suchen und die Verbindungsrichtung ignorieren.

Die ausführliche Diagnose dynamischer Ports und Porterschöpfung erfolgt in der dafür vorgesehenen Folgeseite.

Dienststatus und Socketstatus vergleichen

Dienststatus	Socketstatus	Einordnung
läuft	Listener vorhanden	Dienst hat mindestens einen erwarteten Socket angelegt
läuft	Listener fehlt	Start teilweise fehlgeschlagen, falsche Konfiguration oder falscher Namespace
beendet	Listener vorhanden	anderer Prozess, Kernelkomponente oder alte Instanz besitzt den Port
startet wiederholt	Listener erscheint kurz	Absturz, Health-Check-Fehler oder Portkonflikt möglich
läuft	falsche Adresse	Bindung oder Schnittstellenkonfiguration fehlerhaft
läuft	falscher Port	Konfigurationsquelle oder Startparameter prüfen

Ein grüner Dienststatus ist kein ausreichender Funktionsnachweis.

Konfigurationsquelle des Listeners bestimmen

Mögliche Quellen der Bindung:

Anwendungskonfigurationsdatei;
Kommandozeilenparameter;
Umgebungsvariable;
Windows-Registry;
systemd-Unit;
Socketaktivierung;
Docker-Compose-Datei;
Kubernetes-Manifest;
Helm-Werte;
Reverse-Proxy-Konfiguration;
Orchestrator oder Service Discovery;
durch Gruppenrichtlinie oder zentrale Verwaltung gelieferte Einstellung.

Zu dokumentieren sind:

wirksamer Port:
<Port>

wirksame Bindungsadresse:
<Adresse>

Quelle:
<Datei, Parameter, Variable oder zentrale Richtlinie>

geladene Version:
<Version oder Prüfsumme>

Zeitpunkt der letzten Änderung:
<Zeitpunkt>

Neustart erforderlich:
<ja oder nein>

Die Änderung einer nicht wirksamen Konfigurationsdatei führt zu keinem belastbaren Ergebnis. Zuerst muss bestimmt werden, welche Konfiguration der laufende Prozess tatsächlich verwendet.

Netzwerkaufzeichnung gezielt einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

ob der Client ein SYN sendet;
ob das SYN den Server erreicht;
ob der Server mit SYN/ACK oder RST antwortet;
ob die Antwort den Client erreicht;
ob UDP-Anfragen und Antworten übertragen werden;
ob ein Proxy oder Load Balancer beteiligt ist;
ob IPv4 oder IPv6 verwendet wird;
ob Verbindungen wiederholt aufgebaut werden;
ob der Server die Verbindung nach dem Aufbau beendet.

Linux:

SENSITIV · LESEND

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 100

Auf eine Gegenstelle begrenzen:

sudo tcpdump \
  -ni any \
  'host 198.51.100.40 and tcp port 443' \
  -c 100

UDP-Beispiel:

sudo tcpdump \
  -ni any \
  'udp port 53' \
  -c 100

macOS mit konkreter Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'tcp port 443' \
  -c 100

Lokalen macOS-Verkehr auf Loopback:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 100

Aufzeichnungen müssen auf den benötigten Port, Host und Zeitraum begrenzt werden. Sie können sensible Adressen und Nutzdaten enthalten.

TCP-Paketbefunde einordnen

Beobachtung	Mögliche Einordnung
SYN verlässt Client, erreicht Server nicht	Routing, Firewall, NAT oder falsche Zieladresse
SYN erreicht Server, keine Antwort	Filterung, Überlastung oder falscher Netzwerk-Namespace
SYN erreicht Server, RST folgt	häufig kein passender Listener oder aktive Ablehnung
SYN, SYN/ACK, ACK sichtbar	TCP-Verbindungsaufbau erfolgreich
Aufbau erfolgreich, sofortiges FIN	Anwendung beendet Verbindung kontrolliert
Aufbau erfolgreich, sofortiges RST	Anwendung, Proxy oder Protokollfehler möglich
Server antwortet, Antwort erreicht Client nicht	Rückweg, Firewall, asymmetrisches Routing
wiederholte SYN-Pakete	Client erhält keine verwertbare Antwort

Die Paketaufzeichnung muss möglichst auf beiden Seiten oder an einem geeigneten Zwischenpunkt korreliert werden. Eine Aufzeichnung nur am Client zeigt nicht sicher, ob das Paket den Server erreicht hat.

Systematischer Diagnoseablauf

Exakte Fehlermeldung, Zeitpunkt und betroffene Anwendung dokumentieren.
Erwartetes Transportprotokoll bestimmen.
Erwarteten lokalen und entfernten Port bestimmen.
Erwartete Bindungsadresse festlegen.
Erforderliche Erreichbarkeit bestimmen: lokal, LAN, VPN oder öffentlich.
Host, Container, Pod und Netzwerk-Namespace unterscheiden.
Tatsächliche IP-Adressen des Systems erfassen.
DNS-Auflösung des Zielnamens dokumentieren.
TCP-Listener oder UDP-Endpunkt erfassen.
IPv4- und IPv6-Bindung getrennt auswerten.
Besitzenden Prozess bestimmen.
Prozess einem Dienst, Container oder Pod zuordnen.
Wirksame Konfigurationsquelle bestimmen.
Dienstprotokolle zum Startzeitpunkt prüfen.
Auf Portkonflikte oder Bindungsfehler prüfen.
Loopback-Endpunkt testen.
Konkrete lokale Schnittstellenadresse testen.
Test von einem repräsentativen entfernten Client durchführen.
Firewall, NAT und Portweiterleitung prüfen.
Reverse Proxy, Load Balancer oder Kubernetes-Service berücksichtigen.
Nach erfolgreichem Transport das Anwendungsprotokoll testen.
Bei Bedarf eine begrenzte Netzwerkaufzeichnung durchführen.
Hypothese, erwarteten Befund und Gegenbeweis formulieren.
Genau eine kontrollierte Maßnahme durchführen.
Identische Tests wiederholen.
Anwendung und weitere repräsentative Clients verifizieren.
Temporäre Diagnoseänderungen zurücknehmen.
Ursache und Prävention dokumentieren.

Hypothese und Gegenbeweis

Beispiel:

Hypothese:
Der Webdienst ist ausschließlich an 127.0.0.1:8080 gebunden und deshalb
von entfernten Clients nicht direkt erreichbar.

Erwarteter Befund:
Der lokale Test gegen 127.0.0.1:8080 funktioniert.
Die Socketliste zeigt keinen Listener auf 192.0.2.25:8080 oder
0.0.0.0:8080.
Der Test eines entfernten Clients schlägt fehl.

Gegenbeweis:
Die Socketliste zeigt einen Listener auf 0.0.0.0:8080 und eine
Netzwerkaufzeichnung bestätigt, dass der Server eingehende SYN-Pakete
mit SYN/ACK beantwortet.

Testmethode:
Socketliste, lokaler Test, entfernter Test und begrenzte Aufzeichnung.

Risiko:
Die lesenden Socketprüfungen sind risikoarm. Aktive Tests erzeugen
Netzwerkverkehr, verändern aber nicht die Dienstkonfiguration.

Eine Änderung darf erst erfolgen, wenn die vermutete Ursache einen messbaren Befund besitzt.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko
Bindungsadresse korrigieren	falsche Adresse nachgewiesen	Dienst kann auf weiteren Netzen erreichbar werden
Port korrigieren	Soll- und Ist-Port unterscheiden sich nachweislich	Clients oder Überwachung verwenden eventuell alten Port
kollidierenden Prozess beenden	falscher Prozessbesitz eindeutig bestätigt	Prozess oder abhängiger Dienst fällt aus
Dienst geordnet neu starten	Konfigurationsänderung erfordert Neustart	bestehende Verbindungen werden unterbrochen
Firewallregel anpassen	Listener funktioniert lokal und Filterung ist bestätigt	unbeabsichtigte Freigabe
Docker-Portzuordnung korrigieren	falscher Host- oder Containerport bestätigt	Container muss eventuell neu erstellt werden
Kubernetes-`targetPort` korrigieren	Service und Pod-Listener stimmen nicht überein	laufender Dienstverkehr wird umgeleitet
Reverse-Proxy-Ziel korrigieren	falscher Backendendpunkt nachgewiesen	alle über den Proxy laufenden Anfragen betroffen
IPv4-/IPv6-Bindung korrigieren	Protokollfamilienfehler bestätigt	zusätzliche Angriffsfläche oder geänderte Erreichbarkeit
Socketdateiberechtigung korrigieren	Unix-Socket und Zugriffsfehler bestätigt	weitere lokale Prozesse können Zugriff erhalten

Vor der Maßnahme sind zu dokumentieren:

Ausgangszustand;
betroffener Endpunkt;
Prozess und Dienst;
Konfigurationsquelle;
erwartete Wirkung;
Sicherheitsauswirkung;
Wartungsfenster;
Rückweg;
Erfolgskriterium.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
Dienst läuft, Port fehlt	Bindung fehlgeschlagen oder falsche Konfiguration	Startprotokoll und wirksame Konfiguration
Port vorhanden, falscher Prozess	Portkonflikt oder unerwarteter Dienst	Prozesspfad und Dienstzuordnung
Listener nur auf `127.0.0.1`	nur lokale Erreichbarkeit vorgesehen oder Fehlkonfiguration	Sollbindung und Proxyaufbau prüfen
Listener auf `0.0.0.0`	alle geeigneten IPv4-Adressen	Firewall und tatsächliche Erreichbarkeit prüfen
Listener nur auf `[::]`	IPv6-Wildcard	IPv4 und IPv6 ausdrücklich getrennt testen
lokaler Test funktioniert, remote nicht	Firewall, Routing, NAT oder Bindungsumfang	entfernte Aufzeichnung und Firewallzustand
TCP-Verbindung funktioniert, Anwendung nicht	Anwendungs- oder Protokollfehler	HTTP-, TLS- oder Diensttest
`Connection refused`	häufig kein passender Listener	Server-Socketliste und Paketaufzeichnung
Timeout	keine verwertbare Antwort	Routing, Filterung und Aufzeichnung
UDP-Endpunkt sichtbar, keine Antwort	Anwendung, Firewall oder Rückweg	protokollspezifischer Test und Aufzeichnung
Port erscheint kurz und verschwindet	Prozess beendet sich oder startet neu	Prozess- und Dienstprotokolle
Bindung meldet `Address already in use`	Endpunkt bereits belegt	Besitzer des vorhandenen Sockets bestimmen
Bindung meldet `Address not available`	konfigurierte lokale IP fehlt	Schnittstellen und Startreihenfolge
Docker-Port veröffentlicht, Anwendung nicht erreichbar	falscher Containerport oder Loopback-Bindung im Container	Listener innerhalb des Containers
Kubernetes-Service ohne Endpunkte	Selektor oder Readiness fehlerhaft	Pods und EndpointSlices
Service-Port stimmt, `targetPort` falsch	Weiterleitung auf falschen Pod-Port	Service-YAML und Pod-Listener
Host zeigt keinen Listener, NodePort funktioniert	regelbasierte Weiterleitung	Kubernetes- und Host-Netzwerkregeln
nur `localhost` schlägt fehl	IPv4-/IPv6-Auswahl oder Hosts-Auflösung	`127.0.0.1` und `::1` einzeln testen
nur einige Clients scheitern	Netzpfad, Adressfamilie oder Richtlinie	erfolgreiche und fehlerhafte Pfade vergleichen

Typische Diagnosefehler

TCP und UDP nicht unterscheiden.
Einen UDP-Endpunkt als TCP-Listener interpretieren.
Nur nach der Portnummer suchen und das Protokoll ignorieren.
0.0.0.0 als verwendbare Zieladresse eines Clients behandeln.
Loopback-Bindung und Wildcard-Bindung gleichsetzen.
Einen Listener als vollständigen Funktionsnachweis bewerten.
Nur den Dienststatus prüfen.
Den besitzenden Prozess nicht bestimmen.
Prozess-ID aus einer alten Aufnahme verwenden.
IPv4 und IPv6 nicht getrennt prüfen.
localhost als eindeutigen IPv4-Test behandeln.
Wildcard-Bindung automatisch als öffentliche Erreichbarkeit interpretieren.
Öffentliche Erreichbarkeit allein durch lokale Socketlisten bewerten.
Test-NetConnection -Port als UDP-Test verwenden.
Einen offenen TCP-Port mit funktionierendem TLS oder HTTP gleichsetzen.
Host- und Containerport verwechseln.
Container-IP und Host-IP verwechseln.
Den falschen Netzwerk-Namespace untersuchen.
EXPOSE mit einer Docker-Portveröffentlichung gleichsetzen.
Kubernetes-containerPort als echten Listener interpretieren.
port, targetPort und nodePort verwechseln.
Bei NodePort nur nach einem Benutzerprozess-Listener suchen.
Einen Reverse Proxy und sein Backend als einen einzigen Endpunkt behandeln.
Einen Portkonflikt durch wiederholte Neustarts verdecken.
Einen Prozess beenden, bevor seine Funktion und Abhängigkeiten geklärt sind.
Die Firewall vollständig deaktivieren.
Breite Portscans ohne technische Notwendigkeit durchführen.
Netzwerkaufzeichnungen unbegrenzt laufen lassen.
Sensible Socket- oder Paketdaten ungeschützt speichern.
Mehrere Konfigurationsvariablen gleichzeitig verändern.
Nach der Maßnahme nur lokal testen.
Temporäre Regeln und Diagnosewerkzeuge aktiv lassen.

Verifikation

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

der erwartete Prozess läuft;
der Prozess besitzt den vorgesehenen Socket;
das richtige Transportprotokoll wird verwendet;
der richtige lokale Port ist gebunden;
die richtige lokale Adresse ist gebunden;
die Bindung existiert im richtigen Netzwerk-Namespace;
keine unerwartete zusätzliche Bindung besteht;
IPv4 funktioniert, sofern vorgesehen;
IPv6 funktioniert, sofern vorgesehen;
Loopback-Verhalten entspricht der Planung;
konkrete Schnittstellenadressen funktionieren;
lokale Firewallregeln entsprechen dem Sollzustand;
NAT oder Portweiterleitung verwendet den richtigen Zielport;
Docker-Host- und Containerport stimmen überein;
Kubernetes-port und targetPort stimmen mit dem Pod-Listener überein;
EndpointSlices enthalten die vorgesehenen Backends;
Reverse Proxy oder Load Balancer erreicht das Backend;
ein repräsentativer entfernter Client kann den Endpunkt erreichen;
das Anwendungsprotokoll liefert die erwartete Antwort;
keine neuen Bindungs-, Prozess- oder Dienstfehler entstehen;
temporäre Diagnoseänderungen wurden zurückgenommen;
Sicherheitsauswirkungen der Bindung wurden geprüft;
Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine einzelne erfolgreiche lokale TCP-Verbindung ist keine ausreichende Gesamtverifikation.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Dienst:
<Dienst oder Anwendung>

Betroffener Host:
<Hostname und IP-Adresse>

Netzwerk-Namespace:
<Host, Container, Pod oder anderer Namespace>

Transportprotokoll:
<TCP oder UDP>

Erwartete Bindung:
<Adresse und Port>

Tatsächliche Bindung:
<Adresse und Port>

Prozess:
<Name, PID und Pfad>

Dienstzuordnung:
<Service, Container oder Pod>

Konfigurationsquelle:
<Datei, Startparameter, Variable oder Manifest>

Lokaler Test:
<Zieladresse, Port und Ergebnis>

Entfernter Test:
<Client, Zieladresse, Port und Ergebnis>

Anwendungsprotokolltest:
<Test und Ergebnis>

Firewall-, NAT- oder Proxyweg:
<Befund>

IPv4-Befund:
<Ergebnis>

IPv6-Befund:
<Ergebnis>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

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

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identische Tests und Anwendungstest>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Befehl
Windows-TCP-Verbindungen	`Get-NetTCPConnection`
Windows-TCP-Listener	`Get-NetTCPConnection -State Listen`
Windows-Port prüfen	`Get-NetTCPConnection -State Listen -LocalPort <Port>`
Windows-UDP-Endpunkte	`Get-NetUDPEndpoint`
Windows-UDP-Port prüfen	`Get-NetUDPEndpoint -LocalPort <Port>`
Windows-Prozess prüfen	`Get-Process -Id <PID>`
Windows-Dienst zu PID	`Get-CimInstance Win32_Service -Filter "ProcessId = <PID>"`
Windows-netstat	`netstat -ano`
Windows-IP-Adressen	`Get-NetIPAddress`
Windows-TCP-Test	`Test-NetConnection -ComputerName <Ziel> -Port <Port>`
Windows-HTTP.sys-Zustand	`netsh http show servicestate`
Windows-URL-Reservierungen	`netsh http show urlacl`
Windows-Portproxy	`netsh interface portproxy show all`
Linux-TCP-Listener	`sudo ss -lntp`
Linux-UDP-Endpunkte	`sudo ss -lnup`
Linux-TCP-Port prüfen	`sudo ss -lntp 'sport = :<Port>'`
Linux-Socketübersicht	`ss -s`
Linux-Prozess zu TCP-Port	`sudo lsof -nP -iTCP:<Port> -sTCP:LISTEN`
Linux-Prozess zu UDP-Port	`sudo lsof -nP -iUDP:<Port>`
Linux-IP-Adressen	`ip -brief address`
Linux-Netzwerk-Namespaces	`ip netns list`
macOS-TCP-Listener	`sudo lsof -nP -iTCP -sTCP:LISTEN`
macOS-UDP-Endpunkte	`sudo lsof -nP -iUDP`
macOS-TCP-Sockets	`netstat -anv -p tcp`
Unix-Domain-Sockets Linux	`sudo ss -lxnp`
Unix-Domain-Sockets mit lsof	`sudo lsof -U`
TCP-Test Linux/macOS	`nc -vz <Ziel> <Port>`
HTTP-Test	`curl -v http://<Ziel>:<Port>/`
HTTPS-Test mit Zieladresse	`curl -v --resolve <Name>:<Port>:<IP> https://<Name>/`
TLS-Test mit SNI	`openssl s_client -connect <IP>:<Port> -servername <Name>`
Docker-Portübersicht	`docker ps --format 'table {{.Names}}\t{{.Ports}}'`
Docker-Portzuordnung	`docker port <Container>`
Docker-Netzwerkmodus	`docker inspect <Container> --format '{{.HostConfig.NetworkMode}}'`
Listener im Container	`docker exec <Container> ss -lntup`
Kubernetes-Services	`kubectl get service --all-namespaces`
Kubernetes-Service prüfen	`kubectl describe service <Service> -n <Namespace>`
Kubernetes-EndpointSlices	`kubectl get endpointslice -n <Namespace> -l kubernetes.io/service-name=<Service>`
Listener im Pod	`kubectl exec -n <Namespace> <Pod> -- ss -lntup`
begrenzte Linux-Aufzeichnung	`sudo tcpdump -ni any 'tcp port <Port>' -c 100`

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
Set-NetFirewallRule
New-NetFirewallRule
Remove-NetFirewallRule
netsh advfirewall set allprofiles state off
kill
kill -9
systemctl stop
systemctl restart
iptables
nft
ufw disable
firewall-cmd --permanent
docker stop
docker restart
docker rm
kubectl delete
kubectl rollout restart
Änderung einer Wildcard- oder öffentlichen Bindung
Entfernen einer Portweiterleitung
vollständiges Deaktivieren einer Hostfirewall

Das Beenden eines Prozesses oder Neustarten eines Dienstes kann den aktuellen Portbesitz zwar verändern, vernichtet aber möglicherweise den für die Ursachenanalyse wichtigen Ausgangszustand.

Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Unix-Dokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Standards und Register

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9.2 TCP-Handshake, Timeouts und TCP Reset

Ziel dieser Seite

Diese Seite beschreibt den vollständigen Lebenszyklus einer TCP-Verbindung:

Verbindungsaufbau zwischen Client und Server;
Aushandlung wichtiger TCP-Optionen;
zuverlässige und geordnete Datenübertragung;
Bestätigungen, Sequenznummern und Wiederholungen;
kontrollierter Verbindungsabbau;
Timeouts auf unterschiedlichen Ebenen;
abrupter Verbindungsabbruch durch TCP Reset;
systematische Diagnose mit Windows, Linux, macOS und Paketaufzeichnungen.

Nach der Bearbeitung muss unterschieden werden können:

ob bereits der TCP-Verbindungsaufbau scheitert;
welche Seite den Verbindungsaufbau nicht fortsetzt;
ob ein Port aktiv abgelehnt wird;
ob Pakete verworfen oder verzögert werden;
ob TCP erfolgreich aufgebaut wurde und erst das Anwendungsprotokoll scheitert;
ob eine Verbindung kontrolliert mit FIN oder abrupt mit RST beendet wurde;
ob ein Timeout aus TCP, der Anwendung, einem Proxy oder einer Firewall stammt;
welche Gegenstelle oder Zwischenkomponente wahrscheinlich einen Reset erzeugt hat;
ob Wiederholungen auf Paketverlust oder lediglich auf eine unvollständige Aufzeichnung zurückzuführen sind.

Ein TCP-Fehler darf nicht allein anhand einer Anwendungsmeldung wie „Timeout“ oder „Connection reset“ eingeordnet werden. Er muss mit Socketzuständen, Zeitpunkten, Protokollen und bei Bedarf einer begrenzten Paketaufzeichnung korreliert werden.

Sicherheits- und Wirkungsklassen

Kennzeichnung	Bedeutung
LESEND	Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV	Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV	Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND	Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO	Kann Verbindungen, Prozesse oder Dienste beeinträchtigen.

Paketaufzeichnungen können enthalten:

interne und externe IP-Adressen;
Portnummern;
Hostnamen;
Anwendungsdaten;
Authentifizierungsinformationen;
Cookies oder Tokens;
unverschlüsselte Nutzdaten;
Zertifikatsinformationen;
Kommunikationsbeziehungen.

Aufzeichnungen müssen technisch und zeitlich begrenzt, geschützt gespeichert und nach Abschluss der Diagnose kontrolliert entfernt werden.

Grundlegende Eigenschaften von TCP

TCP stellt Anwendungen einen zuverlässigen, geordneten und bidirektionalen Bytestrom zur Verfügung.

TCP bietet unter anderem:

verbindungsorientierte Kommunikation;
Sequenznummern;
Bestätigungen;
Prüfsummen;
Wiederholungen verlorener Segmente;
Flusskontrolle;
Überlastkontrolle;
geordnete Übergabe der Daten;
kontrollierten Verbindungsabbau;
Erkennung bestimmter ungültiger oder nicht mehr existierender Verbindungen.

TCP stellt keine Anwendungsnachrichten bereit. Eine Anwendung übergibt einen Bytestrom. Die Aufteilung in einzelne TCP-Segmente kann sich während der Übertragung ändern.

Folgende Annahmen sind deshalb falsch:

Eine TCP-Verbindung entspricht einer Anfrage.
Ein TCP-Segment entspricht einer Anwendungsnachricht.
Ein ACK bedeutet, dass die Anwendung die Daten verarbeitet hat.
Ein erfolgreicher Handshake bedeutet, dass HTTP, TLS oder die Anwendung funktioniert.

Ein TCP-ACK bestätigt grundsätzlich, dass die TCP-Implementierung der Gegenstelle die entsprechenden Bytes angenommen hat. Es beweist nicht, dass:

die Anwendung die Bytes gelesen hat;
die Anwendung die Anfrage verstanden hat;
Daten auf einen Datenträger geschrieben wurden;
eine Transaktion erfolgreich abgeschlossen wurde;
eine Anwendungsantwort erzeugt wurde.

TCP-Verbindung eindeutig bestimmen

Eine TCP-Verbindung wird durch ihre Endpunkte unterschieden:

Transportprotokoll
lokale IP-Adresse
lokaler Port
entfernte IP-Adresse
entfernter Port

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.25:443

Die Verbindung kann kompakt dargestellt werden als:

192.0.2.100:53124 → 192.0.2.25:443

Auf der Serverseite ist dieselbe Verbindung aus umgekehrter Perspektive sichtbar:

lokal:   192.0.2.25:443
remote:  192.0.2.100:53124

Bei NAT, Load Balancern oder Proxys können sich Adressen und Ports entlang des Pfads verändern. Paketaufzeichnungen auf verschiedenen Seiten müssen deshalb anhand von:

Zeitpunkt;
Richtung;
TCP-Flags;
Sequenznummern;
Nutzdaten;
übersetzten Adressen und Ports

korreliert werden.

Wichtige TCP-Flags

Flag	Bedeutung
`SYN`	Synchronisiert Sequenznummern und beginnt normalerweise den Verbindungsaufbau.
`ACK`	Das Bestätigungsfeld ist gültig.
`FIN`	Der Sender hat keine weiteren Daten mehr zu senden.
`RST`	Verbindung zurücksetzen oder ungültige Verbindung ablehnen.
`PSH`	Kennzeichnet Daten für eine zeitnahe Weitergabe innerhalb des TCP-Datenstroms.
`URG`	Das Urgent-Pointer-Feld ist relevant.
`ECE`	Wird im Zusammenhang mit Explicit Congestion Notification verwendet.
`CWR`	Signalisiert eine reduzierte Congestion Window nach ECN.

PSH definiert keine Anwendungsnachricht und garantiert keine bestimmte Paketgröße oder sofortige Verarbeitung durch die Anwendung.

Verbindungsaufbau zwischen Client und Server

Der reguläre TCP-Verbindungsaufbau wird als Three-Way Handshake bezeichnet.

Client                                      Server

CLOSED                                      LISTEN
   |                                           |
   |  SYN, Seq=x                               |
   |------------------------------------------>|
   |                                           |
   |  SYN, ACK, Seq=y, Ack=x+1                 |
   |<------------------------------------------|
   |                                           |
   |  ACK, Ack=y+1                             |
   |------------------------------------------>|
   |                                           |
ESTABLISHED                                ESTABLISHED

Die drei logischen Schritte sind:

Der Client sendet ein Segment mit SYN.
Der Server bestätigt das Client-SYN und sendet sein eigenes SYN mit SYN, ACK.
Der Client bestätigt das Server-SYN mit ACK.

Das dritte Segment kann abhängig von Anwendung und TCP-Erweiterungen bereits Daten enthalten. Für die grundlegende Diagnose wird es dennoch als dritter Handshake-Schritt betrachtet.

Sequenznummern beim Handshake

Beispiel:

Client → Server:
SYN
Seq = 1000

Server → Client:
SYN, ACK
Seq = 7000
Ack = 1001

Client → Server:
ACK
Seq = 1001
Ack = 7001

Ein SYN verbraucht eine Sequenznummer. Deshalb bestätigt der Server:

1000 + 1 = 1001

Auch das SYN des Servers verbraucht eine Sequenznummer. Der Client bestätigt:

7000 + 1 = 7001

Die tatsächlich verwendeten Initial Sequence Numbers werden von den TCP-Implementierungen bestimmt und sind nicht als einfache fortlaufende Werte vorhersehbar.

TCP-Zustände während des Verbindungsaufbaus

Zustand	Bedeutung
`CLOSED`	Es besteht keine TCP-Verbindung.
`LISTEN`	Der Server wartet auf neue Verbindungsanfragen.
`SYN-SENT`	Ein SYN wurde gesendet; eine passende Antwort steht aus.
`SYN-RECEIVED`	SYN wurde empfangen und mit SYN/ACK beantwortet; abschließendes ACK steht aus.
`ESTABLISHED`	Der Handshake ist abgeschlossen.

Eine große Zahl von Verbindungen in SYN-SENT kann bedeuten:

Zieladresse nicht erreichbar;
Zielport wird gefiltert;
Rückweg ist fehlerhaft;
Server antwortet nicht;
SYN/ACK wird verworfen;
falsche IPv4- oder IPv6-Adresse;
Überlastung oder Ressourcenproblem;
ausgehende Verbindung wird lokal blockiert.

Viele Einträge in SYN-RECEIVED können bedeuten:

abschließende ACKs erreichen den Server nicht;
Rückweg vom Server zum Client funktioniert, Hinweg des ACKs jedoch nicht;
Clients brechen den Aufbau ab;
SYN-Flood oder ungewöhnlich viele unvollständige Verbindungsversuche;
vorgeschaltete Systeme oder Health Checks öffnen Verbindungen nicht vollständig;
Serverwarteschlangen oder Ressourcen sind erschöpft.

Ein einzelner kurz sichtbarer Zustand SYN-SENT oder SYN-RECEIVED ist normal. Entscheidend sind Häufigkeit, Dauer und Vergleich mit einer Baseline.

TCP-Optionen während des Handshakes

Wichtige Optionen werden typischerweise in SYN-Segmenten angeboten oder ausgehandelt.

Option	Zweck
`MSS`	Maximale TCP-Nutzdatenmenge, die die jeweilige Seite in einem Segment empfangen möchte.
`Window Scale`	Erweitert die darstellbare TCP-Empfangsfenstergröße.
`SACK Permitted`	Erlaubt Selective Acknowledgment.
`Timestamps`	Unterstützt unter anderem RTT-Messungen und Schutzmechanismen gegen alte Segmente.
`ECN`	Ermöglicht Überlastsignalisierung ohne zwingenden Paketverlust, sofern der Pfad sie unterstützt.

Bei der Diagnose müssen die SYN- und SYN/ACK-Optionen verglichen werden.

Zu prüfen sind:

bietet der Client eine MSS an?
bietet der Server eine abweichende MSS an?
wird Window Scaling angeboten?
wird SACK unterstützt?
werden TCP-Timestamps verwendet?
verschwinden Optionen zwischen Client und Server?
verändert eine Firewall oder Optimierungskomponente SYN-Pakete?
unterscheiden sich erfolgreiche und fehlerhafte Verbindungen?

Ein Handshake kann trotz unterschiedlicher angebotener Optionen erfolgreich sein. Die Optionen können jedoch das spätere Übertragungsverhalten beeinflussen.

Erfolgreicher TCP-Handshake

Eine normale Paketfolge ist:

Client → Server  SYN
Server → Client  SYN, ACK
Client → Server  ACK

Dieser Befund beweist:

der Client konnte ein SYN senden;
das SYN erreichte einen antwortenden TCP-Endpunkt;
eine SYN/ACK-Antwort erreichte den Client;
das abschließende ACK konnte gesendet werden;
die TCP-Verbindung wurde mindestens kurzfristig aufgebaut.

Dieser Befund beweist nicht:

dass TLS funktioniert;
dass das richtige Zertifikat geliefert wird;
dass HTTP antwortet;
dass der virtuelle Host stimmt;
dass die Anwendung gesund ist;
dass Authentifizierung funktioniert;
dass eine Datenbankanfrage verarbeitet wird;
dass die Verbindung dauerhaft stabil bleibt.

SYN ohne Antwort

Typischer Paketbefund:

Client → Server  SYN
Client → Server  SYN erneut
Client → Server  SYN erneut
...
Timeout

Mögliche Ursachen:

Zielhost ist nicht erreichbar;
Routing ist fehlerhaft;
lokale Firewall verwirft das SYN;
Netzwerkfirewall verwirft das SYN;
Zielport wird still verworfen;
SYN erreicht den Server nicht;
Server-SYN/ACK wird auf dem Rückweg verworfen;
falsche Zieladresse;
falsche Adressfamilie;
NAT-Zuordnung fehlt;
Load Balancer besitzt kein erreichbares Frontend;
Server oder Zwischenkomponente ist überlastet;
Paketaufzeichnung wurde am falschen Punkt durchgeführt.

Aus einer alleinigen Clientaufzeichnung kann nicht sicher geschlossen werden, ob das SYN den Server erreicht hat. Dafür wird eine korrelierte Aufzeichnung am Server oder an einem geeigneten Zwischenpunkt benötigt.

SYN wird mit Reset beantwortet

Typischer Paketbefund:

Client → Server  SYN
Server → Client  RST, ACK

Typische Einordnung:

Zielhost ist erreichbar;
auf dem angesprochenen Endpunkt existiert häufig kein passender Listener;
das Betriebssystem oder eine Zwischenkomponente lehnt die Verbindung aktiv ab;
eine Firewall kann mit einem Reset ablehnen;
ein Load Balancer besitzt möglicherweise kein verwendbares Backend;
Portweiterleitung zeigt auf einen geschlossenen Zielport.

Eine Anwendung meldet in diesem Fall häufig:

Connection refused
Verbindung abgelehnt
No connection could be made because the target machine actively refused it

Die Meldung beweist nicht, dass der eigentliche Zielserver selbst den Reset erzeugt hat. Firewalls, Proxys und Load Balancer können ebenfalls TCP-Reset-Segmente erzeugen.

Server sendet SYN/ACK, erhält aber kein ACK

Typischer Befund am Server:

Client → Server  SYN
Server → Client  SYN, ACK
Server → Client  SYN, ACK erneut
Server → Client  SYN, ACK erneut
...

Mögliche Ursachen:

SYN/ACK erreicht den Client nicht;
Clientfirewall verwirft die Antwort;
asymmetrischer Rückweg;
NAT-Zustand ist fehlerhaft;
Client sendet das ACK über einen anderen Pfad;
Quelladressprüfung verwirft das Paket;
Clientprozess wurde beendet;
fehlerhafte oder unvollständige Paketaufzeichnung;
Zwischenkomponente verwirft das abschließende ACK.

Zur Eingrenzung werden Aufzeichnungen auf Client- und Serverseite benötigt.

Handshake funktioniert nur teilweise

Paketbefund	Einordnung
kein SYN sichtbar	Anwendung startet keinen TCP-Aufbau oder Aufzeichnungspunkt ist falsch
SYN sichtbar, keine Antwort	Filterung, Routing, Verlust oder fehlender Rückweg
SYN gefolgt von RST	aktive Ablehnung
SYN/ACK wird wiederholt	abschließendes ACK fehlt
Handshake vollständig, danach keine Daten	Anwendung wartet, Protokollmissverständnis oder falsche Rolle
Handshake vollständig, danach RST	Anwendung, Betriebssystem oder Zwischenkomponente bricht ab
Handshake vollständig, danach FIN	kontrollierte Beendigung
Handshake vollständig, TLS beginnt und stoppt	TLS- oder Anwendungsproblem, nicht TCP-Verbindungsaufbau

Die kontrollierte Datenübertragung bei TCP

Nach dem Handshake können beide Seiten Daten senden.

TCP arbeitet als bidirektionaler Bytestrom:

Client ⇄ Server

Jede Richtung besitzt eigene:

Sequenznummern;
Bestätigungen;
Empfangsfenster;
Sendepuffer;
Empfangspuffer;
Wiederholungszustände.

Ein Client kann gleichzeitig Daten senden und Daten des Servers empfangen.

Sequenznummern bei der Datenübertragung

Beispiel:

Client sendet:
Seq = 1001
TCP-Nutzdatenlänge = 500 Bytes

Der Server bestätigt als nächste erwartete Sequenznummer:

Ack = 1501

Berechnung:

1001 + 500 = 1501

Die Bestätigungsnummer bezeichnet das nächste Byte, das die empfangende Seite erwartet.

Wenn der Server Ack = 1501 sendet, bestätigt er kumulativ alle Bytes bis einschließlich Sequenznummer 1500.

Kumulative Bestätigungen

TCP-ACKs sind grundsätzlich kumulativ.

Beispiel:

Segment 1: Seq 1001, Länge 500
Segment 2: Seq 1501, Länge 500
Segment 3: Seq 2001, Länge 500

Wenn der Empfänger anschließend sendet:

Ack = 2501

sind damit alle zusammenhängend empfangenen Bytes bis 2500 bestätigt.

Ein fehlendes Segment kann dazu führen, dass der Empfänger weiterhin dieselbe nächste erwartete Sequenznummer bestätigt.

Selective Acknowledgment

Wenn SACK während des Handshakes erlaubt wurde, kann der Empfänger zusätzlich mitteilen, welche späteren Datenblöcke bereits angekommen sind.

Beispiel:

Segment 1 angekommen
Segment 2 fehlt
Segment 3 angekommen
Segment 4 angekommen

Der kumulative ACK verweist weiterhin auf Segment 2. SACK-Informationen können jedoch anzeigen, dass Segment 3 und Segment 4 bereits vorhanden sind.

Dadurch muss der Sender nicht zwingend alle späteren Daten erneut übertragen.

Verzögerte ACKs

TCP-Implementierungen können Bestätigungen kurz verzögern, um:

mehrere empfangene Segmente gemeinsam zu bestätigen;
ACKs mit eigenen ausgehenden Daten zu kombinieren;
unnötige kleine Pakete zu reduzieren.

Ein nicht sofort sichtbares ACK ist deshalb nicht automatisch ein Fehler.

Entscheidend sind:

tatsächliche Verzögerungsdauer;
Wiederholungen;
Anwendungsreaktion;
Vergleich mit erfolgreichen Verbindungen;
Betriebssystem- und Protokollverhalten.

Flusskontrolle

Der Empfänger teilt über das TCP-Empfangsfenster mit, wie viele weitere Bytes er aufnehmen kann.

Vereinfacht:

Sender darf nur so viele unbestätigte Daten senden,
wie das angekündigte Empfangsfenster zulässt.

Ein kleiner werdendes Empfangsfenster kann darauf hindeuten, dass die empfangende Anwendung Daten nicht schnell genug aus dem Socket liest.

Ein Empfangsfenster von null bedeutet, dass momentan kein weiterer Empfangspuffer verfügbar ist. Die ausführliche Diagnose von Zero Window und Übertragungsstillständen erfolgt auf der dafür vorgesehenen Seite zu Retransmissions, Zero Window und MTU-Problemen.

Überlastkontrolle

Zusätzlich zur Flusskontrolle begrenzt TCP die Sendemenge anhand des vermuteten Netzzustands.

Wichtige Begriffe:

Begriff	Bedeutung
`cwnd`	Congestion Window des Senders
`rwnd`	vom Empfänger angekündigtes Receive Window
`RTT`	gemessene Round Trip Time
`RTO`	berechneter Retransmission Timeout
Slow Start	vorsichtige Erhöhung der Sendemenge zu Beginn oder nach bestimmten Verlusten
Congestion Avoidance	kontrollierte Anpassung der Sendemenge
Fast Retransmit	schnelle Wiederholung bei Verlusthinweisen
Fast Recovery	Wiederherstellung nach bestimmten Verlustereignissen

Die tatsächlich sendbare unbestätigte Datenmenge wird unter anderem durch Empfangsfenster und Congestion Window begrenzt.

Retransmission Timeout

Ein Sender startet für noch nicht bestätigte Daten einen Wiederholungstimer.

Der RTO wird aus gemessenen Laufzeiten und deren Schwankungen berechnet. Er ist kein fester universeller Wert.

Wenn eine Bestätigung nicht rechtzeitig eintrifft:

läuft der Wiederholungstimer ab;
das betreffende Segment kann erneut gesendet werden;
der Wiederholungstimer wird typischerweise vergrößert;
die Sendegeschwindigkeit kann reduziert werden;
nach weiteren erfolglosen Versuchen kann die Verbindung aufgegeben werden.

Die genaue Anzahl der Versuche und die Gesamtdauer sind abhängig von:

Betriebssystem;
TCP-Implementierung;
Verbindungsphase;
Anwendung;
Socketoptionen;
Systemkonfiguration;
Zwischenkomponenten.

Es darf kein universeller TCP-Timeoutwert angenommen werden.

Fast Retransmit

Beim klassischen Fast-Retransmit-Verfahren können mehrere Duplicate ACKs den Sender darauf hinweisen, dass ein früheres Segment fehlt, während spätere Segmente angekommen sind.

Der Sender kann das fehlende Segment wiederholen, bevor der normale RTO abläuft.

Moderne TCP-Implementierungen können zusätzlich oder alternativ weitere Verlustalgorithmen und SACK-Informationen verwenden. Deshalb darf nicht jeder Fast-Retransmit ausschließlich anhand einer festen Zahl von Duplicate ACKs erklärt werden.

Duplicate ACKs richtig einordnen

Duplicate ACKs können entstehen durch:

tatsächlich verlorenes Segment;
Paketumordnung;
duplizierte Pakete;
verzögerte Übertragung;
unvollständige Paketaufzeichnung;
asymmetrische Aufzeichnung;
unterschiedliche Netzwerkpfade;
Captureverlust am Analysesystem.

Ein Duplicate ACK ist ein Hinweis und kein alleiniger Beweis für Paketverlust.

TCP-Retransmissions richtig einordnen

Eine als Retransmission markierte Übertragung kann bedeuten:

ursprüngliches Segment ging im Netzwerk verloren;
Bestätigung ging verloren;
ursprüngliches Segment wurde am Aufzeichnungspunkt nicht erfasst;
Pakete trafen in anderer Reihenfolge ein;
Aufzeichnungssoftware verlor Pakete;
Daten wurden durch Offloading anders dargestellt;
Wireshark ordnete den Datenstrom heuristisch ein.

Wireshark-Analysefelder wie tcp.analysis.retransmission sind Analyseergebnisse und keine im TCP-Paket übertragenen Flags.

TCP Checksum Offloading berücksichtigen

Bei einer Aufzeichnung auf dem sendenden Host kann eine TCP-Prüfsumme als fehlerhaft erscheinen, obwohl das Netzwerkpaket später korrekt übertragen wird.

Mögliche Ursache:

die Netzwerkkarte berechnet die Prüfsumme erst nach dem Aufzeichnungspunkt;
TCP Segmentation Offload zerlegt große Datenblöcke erst in der Netzwerkkarte;
Generic Receive Offload oder Large Receive Offload fasst Daten zusammen.

Deshalb gilt:

Eine lokal als fehlerhaft angezeigte TCP-Prüfsumme
beweist ohne weitere Prüfung keinen Netzwerkfehler.

Zu vergleichen sind:

Aufzeichnung am sendenden Host;
Aufzeichnung auf einem externen Messpunkt;
Offloading-Anzeige des Analysewerkzeugs;
erfolgreiche und fehlerhafte Verbindungen.

TCP besitzt keine Anwendungs-Lebendigkeitsprüfung

Eine bestehende TCP-Verbindung kann im Zustand ESTABLISHED verbleiben, obwohl:

die Gegenstelle ausgefallen ist;
ein Kabel getrennt wurde;
eine Firewall den Sitzungszustand gelöscht hat;
der Netzwerkpfad nicht mehr funktioniert;
die Anwendung der Gegenstelle nicht mehr reagiert.

Solange keine Daten übertragen oder Prüfmechanismen ausgelöst werden, erkennt TCP einen solchen Zustand nicht zwingend sofort.

Mögliche zusätzliche Mechanismen sind:

TCP Keepalive;
anwendungsspezifische Heartbeats;
Request-Timeouts;
Health Checks;
Sitzungszeitüberschreitungen;
erneuter Verbindungsaufbau.

Ein TCP-Keepalive beweist nur eine Reaktion des TCP-Endpunkts. Es beweist nicht automatisch, dass die Anwendung fachlich gesund ist.

Timeout ist nicht gleich Timeout

Die Meldung „Timeout“ kann aus verschiedenen Ebenen stammen.

Timeoutart	Phase	Typischer Befund
DNS-Timeout	vor TCP	kein SYN zum eigentlichen Server
TCP-Connect-Timeout	Handshake	SYN bleibt unbeantwortet
TCP-Retransmission-Timeout	Datenübertragung	unbestätigte Segmente werden wiederholt
TLS-Handshake-Timeout	nach TCP-Aufbau	TCP steht, TLS wird nicht abgeschlossen
Application-Read-Timeout	nach Anfrage	TCP steht, erwartete Antwort fehlt
Application-Write-Timeout	Datenversand	Anwendung kann nicht rechtzeitig schreiben
Proxy-Connect-Timeout	Proxy zum Backend	Client erreicht Proxy, Proxy nicht das Backend
Proxy-Read-Timeout	Proxy wartet auf Backend	Backendverbindung besteht, Antwort dauert zu lange
Firewall-Idle-Timeout	längere Inaktivität	Sitzungszustand der Firewall wird entfernt
NAT-Idle-Timeout	längere Inaktivität	NAT-Zuordnung läuft ab
Load-Balancer-Idle-Timeout	längere Inaktivität	Load Balancer verwirft inaktive Sitzung
TCP-Keepalive-Timeout	Prüfmechanismus	Gegenstelle reagiert nicht auf Keepalive-Probes
Anwendungsdeadline	beliebige Phase	Anwendung bricht nach eigener Gesamtfrist ab

Vor einer Änderung muss festgestellt werden, welcher Zeitgeber tatsächlich abgelaufen ist.

Connect-Timeout erkennen

Typischer Ablauf:

Anwendung startet Verbindung
Client sendet SYN
keine verwertbare Antwort
SYN wird wiederholt
Anwendung meldet Timeout

Zu prüfen sind:

Zeitpunkt des ersten SYN;
Anzahl und Abstand der SYN-Wiederholungen;
Zeitpunkt der Anwendungsmeldung;
kommt ein SYN/ACK oder RST an?
erreicht das SYN den Server?
erreicht die Antwort den Client?
beendet die Anwendung den Versuch vor dem TCP-Stack?
versucht die Anwendung danach eine weitere Zieladresse?

Bei mehreren DNS-Adressen kann die Anwendung nacheinander oder parallel unterschiedliche Ziele versuchen. Die sichtbare Gesamtdauer muss daher nicht dem Timeout eines einzelnen TCP-Versuchs entsprechen.

Anwendungs-Timeout nach erfolgreichem Handshake

Typischer Ablauf:

SYN
SYN, ACK
ACK
Anwendungsanfrage
keine oder verspätete Anwendungsantwort
Anwendung meldet Timeout

TCP ist in diesem Fall grundsätzlich aufgebaut.

Mögliche Ursachen:

Serveranwendung verarbeitet die Anfrage zu langsam;
Backenddienst reagiert nicht;
Datenbankabfrage blockiert;
Thread- oder Workerpool ist erschöpft;
Empfangsfenster wird klein oder null;
Proxy wartet auf ein Backend;
falsches Anwendungsprotokoll;
Deadlock oder Ressourcensperre;
Antwortpakete gehen verloren;
Anwendung verwendet eine zu kurze Frist.

Die Diagnose darf nicht bei einem erfolgreichen Porttest enden.

Idle-Timeout erkennen

Typischer Ablauf:

TCP-Verbindung wird erfolgreich aufgebaut
Datenübertragung funktioniert
Verbindung bleibt längere Zeit inaktiv
erste neue Übertragung schlägt fehl
eine neue TCP-Verbindung funktioniert wieder

Mögliche Ursachen:

Firewall hat Sessiontabelleneintrag entfernt;
NAT-Zuordnung ist abgelaufen;
Load Balancer hat die Verbindung geschlossen;
Proxy hat seine Idle-Frist erreicht;
Serveranwendung hat die Sitzung beendet;
Client verwendet eine veraltete Verbindung aus einem Connection Pool;
TCP Keepalive ist nicht aktiv oder zu spät eingestellt.

Benötigter Nachweis:

genaue Dauer der Inaktivität;
Zeitpunkt der letzten erfolgreichen Datenübertragung;
Paketfolge beim ersten erneuten Sendeversuch;
Verhalten bei einer frisch aufgebauten Verbindung;
konfigurierte Idle-Timeouts aller Zwischenkomponenten;
Anwendungspool- und Keepalive-Konfiguration.

TCP Reset

Ein TCP-Reset wird durch das Flag RST signalisiert.

Ein Reset bedeutet grundsätzlich:

Diese TCP-Verbindung soll sofort zurückgesetzt werden
oder der angesprochene TCP-Zustand ist nicht gültig.

Im Unterschied zu einem geordneten Abbau mit FIN ist ein Reset ein abrupter Abbruch.

Mögliche Anwendungsmeldungen:

Connection reset by peer
ECONNRESET
An existing connection was forcibly closed by the remote host
Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
SocketException: Connection reset

Die Formulierung „by peer“ bedeutet nicht zwingend, dass der eigentliche Anwendungsprozess der Gegenstelle den Reset absichtlich erzeugt hat. Der Reset kann stammen von:

Betriebssystem der Gegenstelle;
Anwendung;
lokalem Betriebssystem;
Firewall;
Load Balancer;
Reverse Proxy;
NAT-Gateway;
Intrusion-Prevention-System;
Service Mesh;
Container- oder Cloudnetzkomponente.

Typische Ursachen eines TCP Reset

Verbindung zu einem geschlossenen TCP-Port;
Anwendung bricht einen Socket ausdrücklich ab;
Prozess wird beendet oder stürzt ab;
Anwendung schließt mit ungelesenen Eingangsdaten;
ungültiges Segment für eine nicht mehr existierende Verbindung;
Gegenstelle hat den Verbindungszustand verloren;
Host wurde neu gestartet;
alte Verbindung wird nach längerer Inaktivität erneut verwendet;
Firewall oder Load Balancer hat den Sitzungszustand entfernt;
Proxy lehnt eine Verbindung oder Anfrage ab;
Backend ist nicht verfügbar;
Protokoll wird auf dem falschen Port verwendet;
Sicherheitskomponente beendet die Sitzung;
Verbindungslimit oder Ressourcenlimit wurde erreicht;
Zeitüberschreitung führt zu einem erzwungenen Abbruch;
fehlerhafte NAT- oder Sessionzuordnung;
Paket gehört zu einer früheren Verbindung mit wiederverwendetem Port;
Anwendung verwendet eine abortive Socket-Schließung.

Nicht jede Prozessbeendigung erzeugt zwingend einen Reset. Abhängig vom Socketzustand und Betriebssystem kann auch ein kontrollierter FIN-Abbau erfolgen.

Reset während des Handshakes

Paketfolge:

Client → Server  SYN
Server → Client  RST, ACK

Mögliche Einordnung:

kein Listener auf dem Zielport;
Firewall lehnt aktiv ab;
Portweiterleitung zeigt auf geschlossenen Port;
Load Balancer lehnt ab;
falsche Zieladresse;
Dienst wurde beendet;
Listener existiert nur auf einer anderen lokalen Adresse;
IPv4-/IPv6-Bindung passt nicht.

Nächster Nachweis:

Listener direkt auf dem Zielsystem prüfen;
Prozessbesitzer bestimmen;
Zieladresse und Adressfamilie bestätigen;
Paketaufzeichnung auf Serverseite durchführen;
Firewall- und NAT-Pfad prüfen.

Reset unmittelbar nach erfolgreichem Handshake

Paketfolge:

SYN
SYN, ACK
ACK
RST

Mögliche Ursachen:

Anwendung akzeptiert und verwirft die Verbindung sofort;
Prozess- oder Workerlimit erreicht;
Zugriffskontrolle lehnt ab;
Proxy besitzt kein Backend;
Client beendet den Socket abrupt;
Server erwartet sofortige Protokolldaten;
Health Check verwendet ein unpassendes Protokoll;
Verbindungszustand ist zwischen Komponenten inkonsistent.

Zu prüfen sind:

wer sendet den Reset?
wird vor dem Reset Anwendungsnutzlast übertragen?
existiert im Serverlog eine passende Verbindung?
tritt der Fehler bei jedem Client auf?
funktioniert ein protokollspezifischer Test?

Reset nach Übertragung einer Anfrage

Paketfolge:

Handshake erfolgreich
Client sendet Anfrage
Server oder Zwischenkomponente sendet RST

Mögliche Ursachen:

ungültiges Anwendungsprotokoll;
TLS-Daten an einem Klartextport;
Klartextdaten an einem TLS-Port;
fehlerhafte oder verbotene Anfrage;
Anwendung stürzt bei der Verarbeitung ab;
Proxy oder WAF beendet die Verbindung;
maximale Anfragegröße überschritten;
Sicherheitsrichtlinie löst aus;
Backend schließt abrupt;
Server liest die Anfrage nicht vollständig;
Client sendet weiter, nachdem der Server bereits geschlossen hat.

Der Inhalt unmittelbar vor dem Reset ist für die Ursachenbestimmung besonders wichtig.

Reset nach längerer Inaktivität

Typischer Ablauf:

Verbindung ist ESTABLISHED
keine Übertragung über längere Zeit
Client sendet neue Daten
RST wird empfangen

Mögliche Ursache:

Zwischenkomponente hat den Sitzungszustand gelöscht;
Server hat die Verbindung lokal bereits beendet;
Anwendung verwendet einen veralteten Socket;
Connection Pool prüft die Verbindung vor Wiederverwendung nicht;
Idle-Timeouts verschiedener Komponenten sind nicht abgestimmt.

Zu vergleichen sind:

TCP-Keepalive;
Anwendungsheartbeat;
Firewall-Idle-Timeout;
NAT-Timeout;
Proxy-Timeout;
Load-Balancer-Timeout;
Connection-Pool-Lebensdauer.

Reset nach Wiederholungen

Möglicher Ablauf:

Daten werden gesendet
Bestätigung fehlt
Daten werden wiederholt
weitere Wiederholungen
RST oder lokaler Verbindungsabbruch

Ein Reset nach Wiederholungen kann bedeuten:

Netzwerkpfad war unterbrochen;
Gegenstelle hat den Zustand verloren;
Anwendung oder Betriebssystem gibt die Verbindung auf;
eine Zwischenkomponente reagiert auf eine nicht mehr bekannte Sitzung;
Prozess wurde während des Fehlers beendet.

Die zeitliche Reihenfolge muss genau ausgewertet werden. Der Reset kann Folge und nicht Ursache des ursprünglichen Problems sein.

Reset-Absender bestimmen

In der Clientaufzeichnung ist zunächst die Quelladresse des Reset-Segments sichtbar. Sie ist jedoch nicht immer ein eindeutiger Beweis für den tatsächlichen Erzeuger.

Zwischenkomponenten können:

mit der Adresse des Servers antworten;
Verbindungen stellvertretend terminieren;
NAT-Adressen verwenden;
einen eigenen TCP-Endpunkt darstellen;
Reset-Segmente erzeugen.

Belastbarer Nachweis:

Aufzeichnung am Client.
Aufzeichnung am Server.
Zeitliche Synchronisation beider Systeme.
Vergleich derselben TCP-Verbindung.
Prüfung, ob der Reset den Server verlässt.
Prüfung, ob der Server den Reset überhaupt empfängt.
Protokolle von Firewall, Proxy und Load Balancer korrelieren.

Beispiel:

Client sieht einen RST.
Serveraufzeichnung zeigt keinen ausgehenden RST.
Firewallprotokoll zeigt eine aktive Sitzungsbeendigung.

Einordnung:
Der Reset wurde wahrscheinlich von der Firewall erzeugt.

Dies ist eine Schlussfolgerung aus mehreren Befunden und nicht allein aus der IP-Quelladresse.

FIN, RST und Timeout unterscheiden

Befund	Bedeutung
`FIN`	Sender beendet seine Senderichtung geordnet.
`RST`	Verbindung wird abrupt zurückgesetzt.
Timeout	Innerhalb der erwarteten Frist kam keine verwertbare Reaktion.
ICMP-Fehler	IP- oder Netzwerkebene meldet ein Problem.
Anwendungsfehler	TCP kann funktionieren, während das höhere Protokoll fehlschlägt.

Ein FIN bedeutet nicht zwingend, dass die gesamte Verbindung sofort beendet ist. TCP unterstützt einen geordneten Abbau je Richtung.

Verbindungsabbau zwischen Client und Server

Ein regulärer TCP-Abbau besteht logisch aus:

Teilnehmer A                                 Teilnehmer B

ESTABLISHED                                 ESTABLISHED
     |                                           |
     |  FIN, ACK                                 |
     |------------------------------------------>|
     |                                           |
FIN-WAIT-1                                  CLOSE-WAIT
     |                                           |
     |  ACK                                      |
     |<------------------------------------------|
     |                                           |
FIN-WAIT-2                                  CLOSE-WAIT
     |                                           |
     |  FIN, ACK                                 |
     |<------------------------------------------|
     |                                           |
TIME-WAIT                                   LAST-ACK
     |                                           |
     |  ACK                                      |
     |------------------------------------------>|
     |                                           |
TIME-WAIT                                     CLOSED
     |
     | nach Ablauf der Wartezeit
     |
  CLOSED

Dies wird häufig als Four-Way Termination bezeichnet.

In einer echten Aufzeichnung müssen nicht immer vier getrennte Pakete sichtbar sein. ACK und FIN können kombiniert werden.

FIN verbraucht eine Sequenznummer

Wie SYN verbraucht auch FIN eine Sequenznummer.

Beispiel:

Teilnehmer A sendet:
FIN, Seq = 5000

Teilnehmer B bestätigt:
ACK = 5001

Das FIN signalisiert:

Ich werde in dieser Richtung keine weiteren Daten mehr senden.

Die Gegenrichtung kann abhängig vom Anwendungs- und Socketzustand noch Daten übertragen.

Half-Close

Bei einem Half-Close wurde nur eine Senderichtung geordnet geschlossen.

Beispiel:

Client sendet FIN.
Server bestätigt FIN.
Server sendet weiterhin verbleibende Antwortdaten.
Server sendet später sein eigenes FIN.

Half-Close ist nicht dasselbe wie eine Half-Open Connection.

Begriff	Bedeutung
Half-Close	Eine Richtung wurde geordnet mit FIN beendet.
Half-Open	Beide Endpunkte besitzen unterschiedliche Vorstellungen darüber, ob die Verbindung noch existiert.

Eine Half-Open Connection kann beispielsweise entstehen, wenn ein System neu startet und den früheren TCP-Zustand verliert, während die Gegenstelle die Verbindung weiterhin als vorhanden betrachtet.

TCP-Zustände beim Verbindungsabbau

Zustand	Bedeutung
`FIN-WAIT-1`	Lokales FIN wurde gesendet; Bestätigung oder FIN der Gegenstelle steht aus.
`FIN-WAIT-2`	Lokales FIN wurde bestätigt; FIN der Gegenstelle steht aus.
`CLOSE-WAIT`	FIN der Gegenstelle wurde empfangen; lokale Anwendung hat noch nicht geschlossen.
`CLOSING`	Beide Seiten haben nahezu gleichzeitig FIN gesendet.
`LAST-ACK`	Lokales FIN wurde nach empfangenem FIN gesendet; abschließendes ACK steht aus.
`TIME-WAIT`	Endpunkt wartet, damit verspätete Segmente einer alten Verbindung nicht falsch zugeordnet werden.
`CLOSED`	Verbindung ist vollständig beendet.

CLOSE-WAIT richtig interpretieren

CLOSE-WAIT bedeutet:

Die Gegenstelle hat ihre Senderichtung geschlossen.
Das lokale Betriebssystem wartet darauf,
dass die lokale Anwendung ihren Socket schließt.

Viele dauerhaft vorhandene CLOSE-WAIT-Sockets können hinweisen auf:

Anwendung liest EOF, schließt aber nicht;
Fehler im Connection-Handling;
blockierte Threads;
fehlende Fehlerbehandlung;
Ressourcenleck;
Anwendung wartet auf einen internen Vorgang;
Prozess reagiert nicht.

CLOSE-WAIT wird nicht durch das bloße Ändern eines TCP-Timers behoben. Zuerst müssen Prozess und Anwendungscode beziehungsweise Herstellerprotokolle geprüft werden.

FIN-WAIT-2 richtig interpretieren

FIN-WAIT-2 bedeutet:

Die lokale Seite hat ihre Senderichtung geschlossen.
Die Gegenstelle hat dies bestätigt,
aber noch kein eigenes FIN gesendet.

Mögliche Ursachen bei ungewöhnlich langen Beständen:

Gegenanwendung hält ihre Senderichtung offen;
Anwendung wartet auf weitere Verarbeitung;
Gegenprozess reagiert nicht;
Half-Close wird absichtlich verwendet;
Netzwerk- oder Zustandsproblem.

Ein kurzfristiger FIN-WAIT-2-Zustand ist nicht automatisch fehlerhaft.

TIME-WAIT richtig interpretieren

TIME-WAIT schützt unter anderem davor, dass verspätete Segmente einer alten Verbindung einer späteren Verbindung mit denselben Endpunkten zugeordnet werden.

Viele TIME-WAIT-Einträge können bei folgenden Arbeitslasten normal sein:

viele kurze HTTP-Verbindungen;
häufige Health Checks;
Proxy- oder API-Aufrufe;
fehlendes oder nicht genutztes Connection Pooling;
Lasttests;
Microservice-Kommunikation.

Zu prüfen sind:

Rate neuer Verbindungen;
Wiederverwendung bestehender Verbindungen;
Quellportbestand;
Verbindungslaufzeit;
Baseline;
Anwendungskonfiguration.

TIME-WAIT darf nicht vorsorglich durch aggressive Timeränderungen beseitigt werden.

Windows: TCP-Zustände prüfen

LESEND

Alle TCP-Verbindungen:

Get-NetTCPConnection |
  Sort-Object State, LocalPort

Verbindungen im Zustand SYN-SENT:

Get-NetTCPConnection `
  -State SynSent

Verbindungen im Zustand SYN-RECEIVED:

Get-NetTCPConnection `
  -State SynReceived

Aufgebaute Verbindungen:

Get-NetTCPConnection `
  -State Established

CLOSE-WAIT:

Get-NetTCPConnection `
  -State CloseWait

TIME-WAIT:

Get-NetTCPConnection `
  -State TimeWait

Bestimmten entfernten Port prüfen:

Get-NetTCPConnection `
  -RemotePort 443 |
  Select-Object `
    LocalAddress,
    LocalPort,
    RemoteAddress,
    RemotePort,
    State,
    OwningProcess

Serververbindungen eines lokalen Ports:

Get-NetTCPConnection `
  -LocalPort 443 |
  Select-Object `
    LocalAddress,
    LocalPort,
    RemoteAddress,
    RemotePort,
    State,
    OwningProcess

Kurzlebige Zustände können zwischen zwei Abfragen verschwinden. Eine Paketaufzeichnung ist für die vollständige zeitliche Reihenfolge zuverlässiger.

Windows: Prozess zuordnen

LESEND

Get-NetTCPConnection `
  -RemotePort 443 |
  ForEach-Object {
    $connection = $_
    $process = Get-Process `
      -Id $connection.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress  = $connection.LocalAddress
      LocalPort     = $connection.LocalPort
      RemoteAddress = $connection.RemoteAddress
      RemotePort    = $connection.RemotePort
      State         = $connection.State
      ProcessId     = $connection.OwningProcess
      ProcessName   = $process.ProcessName
    }
  }

Ein Prozess kann zwischen Socketabfrage und Prozessabfrage bereits beendet sein. Fehlende Prozessinformationen müssen deshalb mit Zeitpunkt und Ereignisprotokollen korreliert werden.

Windows: TCP-Verbindung aktiv testen

NETZAKTIV

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Wichtige Felder:

ComputerName;
RemoteAddress;
RemotePort;
InterfaceAlias;
SourceAddress;
TcpTestSucceeded.

TcpTestSucceeded = True bestätigt einen erfolgreichen TCP-Verbindungsaufbau für diesen Versuch. Es bestätigt nicht die Funktion von TLS, HTTP oder der eigentlichen Anwendung.

Getrennte Prüfung einer konkreten Adresse:

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

Windows: TCP-Statistiken prüfen

LESEND

netstat -s -p tcp

IPv6-TCP-Statistiken:

netstat -s -p tcpv6

Verfügbare Leistungsindikatoren suchen:

Get-Counter `
  -ListSet "*TCP*"

Die Namen der Leistungsindikatoren können von Sprache und Windows-Version abhängen.

Zähler müssen über einen definierten Zeitraum als Differenz oder Rate ausgewertet werden. Ein hoher kumulierter Wert seit dem Systemstart beweist keine aktuelle Störung.

Windows: Paketaufzeichnung mit pktmon

pktmon verändert den Aufzeichnungszustand und erstellt Dateien.

SENSITIV · ÄNDERND

Vorhandene Aufzeichnung stoppen:

pktmon stop

Vorhandene Filter entfernen:

pktmon filter remove

Filter für TCP-Port 443 anlegen:

pktmon filter add TCP443 -t TCP -p 443

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\tcp443.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

In PCAPNG konvertieren:

pktmon etl2pcap C:\Temp\tcp443.etl --out C:\Temp\tcp443.pcapng

Temporären Filter entfernen:

pktmon filter remove

Voraussetzungen:

Zielverzeichnis existiert;
ausreichend freier Speicher ist vorhanden;
Aufzeichnungszeitraum ist begrenzt;
Datei wird geschützt gespeichert;
Filter und Aufzeichnungszustand werden anschließend zurückgesetzt.

Linux: TCP-Zustände mit ss prüfen

LESEND

Alle TCP-Sockets:

ss -tan

TCP-Sockets mit Prozessinformationen:

sudo ss -tanp

SYN-SENT:

ss -tan state syn-sent

SYN-RECEIVED:

ss -tan state syn-recv

Aufgebaute Verbindungen:

ss -tan state established

CLOSE-WAIT:

ss -tan state close-wait

TIME-WAIT:

ss -tan state time-wait

Erweiterte TCP-Informationen für Zielport 443:

sudo ss -tin \
  'dport = :443'

Erweiterte Informationen für einen lokalen Serverport:

sudo ss -tin \
  'sport = :443'

Je nach Zustand und Kernel können erweiterte Angaben enthalten sein:

RTT;
RTO;
Congestion Window;
Retransmissions;
Sendemenge;
Empfangsmenge;
Window Scaling;
MSS;
Timer.

Die konkrete Ausgabe hängt von Kernel und TCP-Zustand ab.

Linux: TCP-Zähler prüfen

LESEND

nstat -az

Bestimmte Zähler:

nstat -az TcpRetransSegs

nstat -az TcpAttemptFails

nstat -az TcpEstabResets

Zusätzliche klassische Statistik:

netstat -s

Zu beachten:

Zähler sind häufig kumulativ;
ein Reset-Zähler nennt nicht automatisch die betroffene Anwendung;
Container oder Netzwerk-Namespaces können eigene Sichten besitzen;
für eine aktuelle Störung sind Vorher-Nachher-Differenzen notwendig.

macOS: TCP-Zustände prüfen

LESEND

netstat -anv -p tcp

TCP-Verbindungen mit Prozesszuordnung:

sudo lsof -nP -iTCP

Aufgebaute TCP-Verbindungen:

sudo lsof \
  -nP \
  -iTCP \
  -sTCP:ESTABLISHED

Interaktive TCP-Ansicht:

nettop -m tcp

TCP-Statistiken:

netstat -s -p tcp

Kurzlebige Handshakezustände können auch unter macOS leichter mit einer Paketaufzeichnung als mit wiederholten Socketabfragen erfasst werden.

Aktive Tests unter Linux und macOS

TCP-Porttest:

NETZAKTIV

nc -vz app.example.test 443

Linux mit begrenzter Wartezeit, abhängig von der installierten nc-Variante:

nc -vz -w 5 app.example.test 443

macOS mit TCP-Verbindungsfrist:

nc -vz -G 5 app.example.test 443

HTTP- oder HTTPS-Test mit getrennten Fristen:

curl \
  --connect-timeout 5 \
  --max-time 15 \
  -v \
  https://app.example.test/

Bedeutung:

--connect-timeout begrenzt die Verbindungsphase;
--max-time begrenzt den gesamten Aufruf.

Ein Fehler nach erfolgreicher Connected-Meldung ist kein reiner TCP-Connect-Fehler mehr.

Paketaufzeichnung unter Linux

SENSITIV · LESEND

Auf Port 443 begrenzen:

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 200

Auf einen Host und Port begrenzen:

sudo tcpdump \
  -ni any \
  'host 192.0.2.25 and tcp port 443' \
  -c 200

Mit ausführlicheren TCP-Informationen in Datei schreiben:

sudo tcpdump \
  -ni any \
  -s 0 \
  -w /tmp/tcp443.pcap \
  'host 192.0.2.25 and tcp port 443'

Nach reproduziertem Fehler mit Strg+C beenden.

Die Datei enthält möglicherweise sensible Daten und muss anschließend geschützt ausgewertet und kontrolliert entfernt werden.

Paketaufzeichnung unter macOS

Verwendbare Schnittstellen anzeigen:

tcpdump -D

Auf einer konkreten Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.25 and tcp port 443' \
  -c 200

Lokale Loopback-Verbindung:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni en0 \
  -s 0 \
  -w /tmp/tcp443.pcap \
  'host 192.0.2.25 and tcp port 443'

Wireshark-Filter für TCP

Bestimmter Port:

tcp.port == 443

Bestimmte IP-Adresse und Port:

ip.addr == 192.0.2.25 && tcp.port == 443

Nur initiale SYN-Segmente:

tcp.flags.syn == 1 && tcp.flags.ack == 0

SYN/ACK:

tcp.flags.syn == 1 && tcp.flags.ack == 1

Reset:

tcp.flags.reset == 1

FIN:

tcp.flags.fin == 1

Vermutete Wiederholungen:

tcp.analysis.retransmission

Vermuteter Fast Retransmit:

tcp.analysis.fast_retransmission

Duplicate ACKs:

tcp.analysis.duplicate_ack

Zero Window:

tcp.analysis.zero_window

Ein bestimmter TCP-Datenstrom:

tcp.stream == 7

Die Nummer des TCP-Streams wird von Wireshark innerhalb der geöffneten Aufzeichnung vergeben und ist keine übertragene Protokollnummer.

Aufzeichnung richtig planen

Vor Beginn sind festzulegen:

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Port:
<TCP-Port>

Zeitfenster:
<Start und Ende>

Testhandlung:
<genau ein reproduzierbarer Versuch>

Aufzeichnungspunkte:
<Client, Server und gegebenenfalls Zwischenkomponente>

Erwartete Paketfolge:
<SYN, SYN/ACK, ACK und Anwendungsdaten>

Fehlerkriterium:
<Timeout, RST, FIN oder fehlende Antwort>

Die Systemzeiten der beteiligten Geräte müssen ausreichend synchron sein. Anderenfalls können Client-, Server-, Firewall- und Proxyprotokolle nicht zuverlässig korreliert werden.

Aufzeichnung am Client und Server vergleichen

Clientaufzeichnung	Serveraufzeichnung	Mögliche Einordnung
SYN sichtbar	SYN nicht sichtbar	Fehler vor dem Server
SYN sichtbar	SYN sichtbar	Hinweg funktioniert
kein SYN/ACK am Client	SYN/ACK verlässt Server	Rückweg oder Filterung
RST am Client	RST verlässt Server	Server oder Serveranwendung wahrscheinlich beteiligt
RST am Client	kein RST am Server	Zwischenkomponente wahrscheinlich beteiligt
Daten am Client gesendet	Daten erreichen Server	Hinweg der Daten funktioniert
ACK fehlt am Client	ACK verlässt Server	Rückwegproblem
Server erhält ACK nicht	Client sendet ACK	Filterung oder asymmetrischer Pfad
FIN auf beiden Seiten	FIN verlässt ursprünglichen Sender	kontrollierter Abbau
unterschiedliche Paketfolgen	Übersetzung oder Verlust	NAT, Proxy, Capturepunkt oder Netzwerkpfad prüfen

NAT, Firewall, Proxy und Load Balancer berücksichtigen

Eine Ende-zu-Ende-Verbindung kann tatsächlich aus mehreren getrennten TCP-Verbindungen bestehen.

Beispiel mit Reverse Proxy:

Client
→ TCP-Verbindung 1
→ Reverse Proxy
→ TCP-Verbindung 2
→ Backend

Ein Reset zwischen Proxy und Backend muss nicht als Reset zwischen Proxy und Client weitergegeben werden. Der Proxy kann stattdessen eine HTTP-Fehlerantwort erzeugen.

Beispiel mit NAT:

Client intern:        192.0.2.100:53124
NAT extern:           203.0.113.10:62000
Server:               198.51.100.25:443

Zu prüfen sind:

übersetzte Quelladresse;
übersetzter Quellport;
Sessiontabelleneintrag;
Ablaufzeit;
Rückweg;
Verbindung zum Backend;
getrennte Timeouts je TCP-Abschnitt;
welcher Abschnitt den Reset enthält.

Container und Kubernetes berücksichtigen

Eine TCP-Verbindung kann durch mehrere Netzwerk-Namespaces laufen:

Client
→ Hostport
→ Container-Netzwerk
→ Containersocket

oder:

Client
→ Load Balancer
→ Kubernetes-Service
→ Pod-IP
→ Anwendungscontainer

Zu prüfen sind:

Handshake am externen Endpunkt;
Handshake zum Backend;
Listener im Container oder Pod;
Host- und Containerport;
Service-port und targetPort;
Sidecar- oder Service-Mesh-Verbindung;
NetworkPolicy;
Readiness und EndpointSlices;
Reset innerhalb des Pods;
Reset am Ingress oder Gateway.

Ein erfolgreicher Handshake zum Load Balancer beweist keinen erfolgreichen Handshake zum Backend.

Typische Fehlermeldungen einordnen

Meldung	Mögliche TCP-Einordnung
`Connection refused`	häufig Reset als Antwort auf SYN
`Connection timed out`	Handshake oder Datenübertragung ohne rechtzeitige Antwort
`Connection reset by peer`	gültiger Reset wurde empfangen
`Broken pipe`	Schreiben auf bereits geschlossene Verbindung
`EOF`	Gegenstelle hat den Datenstrom beendet
`Operation timed out`	Frist der Anwendung oder Bibliothek abgelaufen
`No route to host`	Routing- oder lokal gemeldeter Erreichbarkeitsfehler
`Network is unreachable`	keine verwendbare Route
`TLS handshake timeout`	TCP möglicherweise erfolgreich, TLS nicht abgeschlossen
`Read timed out`	Verbindung steht, erwartete Daten fehlen
`Write timed out`	Daten konnten nicht innerhalb der Frist geschrieben werden

Der genaue Wortlaut hängt von Betriebssystem, Programmiersprache, Bibliothek und Anwendung ab.

Hypothese und Gegenbeweis

Beispiel für einen Connect-Timeout:

Hypothese:
Eine Netzwerkfirewall verwirft die SYN-Pakete zum TCP-Port 443.

Erwarteter Befund:
Der Client sendet wiederholt SYN-Pakete.
Der Server empfängt diese SYN-Pakete nicht.
Es wird weder SYN/ACK noch RST empfangen.

Gegenbeweis:
Die Serveraufzeichnung zeigt das eingehende SYN und ein ausgehendes SYN/ACK.

Testmethode:
Zeitgleich begrenzte Paketaufzeichnung auf Client und Server.

Erfolgskriterium:
Der genaue Punkt des Paketverlusts ist eingegrenzt.

Risiko:
Die Aufzeichnung enthält interne Verbindungsdaten und muss geschützt werden.

Beispiel für einen Reset:

Hypothese:
Der Reverse Proxy erzeugt den Reset, weil kein Backend verfügbar ist.

Erwarteter Befund:
Der Client-Handschlag mit dem Proxy ist erfolgreich.
Der Proxy kann keine Verbindung zum Backend aufbauen.
Der Client empfängt anschließend einen Reset.
Das Backend empfängt keinen Verbindungsversuch oder lehnt ihn ab.

Gegenbeweis:
Der Backend-Handschlag ist erfolgreich und der Reset verlässt nachweislich
das Backend.

Testmethode:
Aufzeichnungen und Protokolle an Client, Proxy und Backend korrelieren.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko
Listener starten oder Bindung korrigieren	Reset wegen fehlendem Listener bestätigt	geänderte Erreichbarkeit
Firewallregel korrigieren	Paketverlust an der Firewall nachgewiesen	unbeabsichtigte Freigabe
Rückweg korrigieren	asymmetrischer oder fehlender Rückweg bestätigt	weitere Netze können betroffen sein
NAT-Zuordnung korrigieren	falsche Übersetzung bestätigt	bestehende Sitzungen werden beeinflusst
Proxy-Backend korrigieren	fehlerhafter Backendpfad nachgewiesen	produktiver Datenverkehr wird umgeleitet
Idle-Timeout abstimmen	Sitzungsablauf nach Inaktivität bestätigt	mehr Sitzungszustand und Ressourcenverbrauch
Connection-Pool-Lebensdauer anpassen	Wiederverwendung veralteter Verbindungen bestätigt	mehr neue Verbindungen
Anwendungs-Timeout anpassen	Verarbeitung dauert legitim länger und Ursache ist bekannt	Fehler werden eventuell später erkannt
TCP-Keepalive gezielt konfigurieren	verwaiste Idle-Verbindungen bestätigt	zusätzlicher Netzwerkverkehr
Anwendung korrigieren	`CLOSE-WAIT`, abortives Schließen oder Absturz bestätigt	Dienstneustart oder Deployment erforderlich
Backendkapazität erhöhen	Ressourcenengpass nachgewiesen	Kosten und Betriebsänderung
Protokoll oder Zielport korrigieren	falsches Protokoll beziehungsweise falscher Port bestätigt	Clientkonfiguration ändert sich

Timeouts dürfen nicht pauschal verlängert werden, um Paketverlust, Deadlocks oder überlastete Backends zu verdecken.

Systematischer Diagnoseablauf

Exakte Anwendungsmeldung aufnehmen.
Datum, Uhrzeit und Zeitzone dokumentieren.
Client, Server, Zielname und Zielport bestimmen.
Verwendete IP-Adresse und Adressfamilie erfassen.
Transportprotokoll bestätigen.
Erwarteten Listener auf dem Server prüfen.
Besitzenden Prozess bestimmen.
Lokalen TCP-Test am Server durchführen.
TCP-Test vom betroffenen Client durchführen.
Socketzustand während des Versuchs beobachten.
Prüfen, ob ein SYN erzeugt wird.
Prüfen, ob der Server das SYN empfängt.
Prüfen, ob SYN/ACK oder RST zurückgesendet wird.
Prüfen, ob das abschließende ACK ankommt.
Bei erfolgreichem Handshake Anwendungsdaten prüfen.
Connect- und Anwendungs-Timeout unterscheiden.
FIN und RST unterscheiden.
Reset-Richtung und Reset-Zeitpunkt bestimmen.
Client-, Server- und Zwischenprotokolle korrelieren.
Retransmissions und Duplicate ACKs auswerten.
Captureverlust und Offloading berücksichtigen.
NAT-, Firewall- und Proxyzustand prüfen.
Load Balancer und Backendverbindung getrennt prüfen.
Container- und Netzwerk-Namespace berücksichtigen.
Idle-Phase und Timeoutwerte dokumentieren.
Frische und wiederverwendete Verbindung vergleichen.
Hypothese und Gegenbeweis formulieren.
Genau eine kontrollierte Maßnahme durchführen.
Identischen Verbindungsversuch wiederholen.
Anwendungsprotokoll vollständig verifizieren.
Weitere repräsentative Clients prüfen.
Temporäre Filter und Aufzeichnungen entfernen.
Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
kein SYN sichtbar	Anwendung, DNS oder lokaler Socketaufruf	Anwendungstrace und Zieladresse
SYN wiederholt, keine Antwort	Drop, Routing oder Rückweg	serverseitige Aufzeichnung
SYN erreicht Server nicht	Netzpfad vor dem Server	Zwischenpunkte und Firewalllogs
SYN erreicht Server, kein SYN/ACK	lokaler Filter, kein Listener oder Überlastung	Socketliste und Servertrace
SYN wird mit RST beantwortet	aktive Ablehnung	Reset-Erzeuger und Listener prüfen
SYN/ACK verlässt Server, erreicht Client nicht	Rückweg oder Filterung	Client- und Firewallaufzeichnung
SYN/ACK wird wiederholt	abschließendes ACK fehlt	Clientaufzeichnung
Handshake vollständig	TCP-Connect funktioniert	Anwendungsprotokoll prüfen
Handshake vollständig, keine Nutzdaten	Anwendung wartet oder startet Anfrage nicht	Anwendungstrace
Anfrage gesendet, keine Antwort	Backend oder Anwendung langsam	Server- und Backendprotokolle
RST direkt nach Handshake	Anwendung oder Zwischenkomponente lehnt ab	Reset-Sender und Logs
RST nach Anfrage	Protokoll-, Anwendungs- oder Sicherheitsfehler	Daten vor dem Reset auswerten
RST nach langer Inaktivität	Idle-Timeout oder veralteter Socket	Timeoutwerte und frische Verbindung
FIN nach Anfrage	kontrollierte Schließung	Anwendungsergebnis prüfen
viele `CLOSE-WAIT`	lokale Anwendung schließt nicht	Prozess- und Threadanalyse
viele `TIME-WAIT`	viele kurzlebige Verbindungen	Verbindungsrate und Pooling
viele `SYN-SENT`	Ziele antworten nicht	Ziel- und Pfadvergleich
viele `SYN-RECEIVED`	Handshake bleibt unvollständig	Serverwarteschlange und Clientpfad
Retransmissions nur in einer Capturedatei	Captureverlust oder Offloading möglich	zweiter Aufzeichnungspunkt
frische Verbindung funktioniert	alte Verbindung fehlerhaft	Idle- und Poolingverhalten
Porttest funktioniert, TLS scheitert	TCP funktioniert, TLS fehlerhaft	TLS-Handshake analysieren
nur große Übertragung stockt	Verlust, Window oder MTU möglich	Folgeseite zu Retransmissions und MTU
nur ein Backend erzeugt Resets	Backend- oder Pfadproblem	direkte Backendtests
Reset am Client, nicht am Server	Zwischenkomponente wahrscheinlich	Firewall-, Proxy- und LB-Protokolle

Typische Diagnosefehler

Anwendungstimeout und TCP-Timeout gleichsetzen.
Einen erfolgreichen Ping als TCP-Nachweis verwenden.
Einen offenen TCP-Port als vollständigen Anwendungsnachweis bewerten.
Nur Test-NetConnection oder nc verwenden.
DNS-Zeit und TCP-Verbindungszeit vermischen.
Nur auf dem Client aufzeichnen.
Aus einer fehlenden Clientantwort schließen, dass der Server nichts gesendet hat.
Aus der RST-Quelladresse sicher auf den Erzeuger schließen.
Firewall, Proxy oder Load Balancer als Reset-Erzeuger ignorieren.
FIN und RST gleich behandeln.
CLOSE-WAIT durch Änderung von TCP-Timern beheben wollen.
TIME-WAIT pauschal als Fehler bewerten.
Wiederholungen ohne Sequenznummern und ACKs auswerten.
Duplicate ACKs automatisch als Paketverlust bewerten.
Wireshark-Analysemarkierungen als echte TCP-Flags interpretieren.
Checksum-Offloading ignorieren.
Captureverlust am Analysesystem ignorieren.
IPv4 und IPv6 nicht getrennt prüfen.
Client- und Serverzeit nicht synchronisieren.
NAT-Adressen und ursprüngliche Adressen verwechseln.
Proxyverbindung und Backendverbindung als eine einzige TCP-Verbindung behandeln.
Host-, Container- und Pod-Namespace verwechseln.
Veraltete Verbindung aus einem Pool nicht berücksichtigen.
Idle-Timeout ohne Messung vermuten.
Timeout pauschal erhöhen.
TCP Keepalive als Nachweis der Anwendungsgesundheit betrachten.
Firewall vollständig deaktivieren.
Prozess vorsorglich beenden.
Server vorsorglich neu starten.
mehrere Einstellungen gleichzeitig verändern.
Paketaufzeichnung ohne Filter laufen lassen.
sensible Capturedateien ungeschützt speichern.
nach der Maßnahme nur einen einzelnen erfolgreichen Versuch prüfen.

Verifikation

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

Zielname wird zur richtigen Adresse aufgelöst;
richtige IPv4- oder IPv6-Adresse wird verwendet;
erwarteter TCP-Listener ist vorhanden;
richtiger Prozess besitzt den Listener;
SYN erreicht den Server;
SYN/ACK erreicht den Client;
abschließendes ACK erreicht den Server;
TCP-Verbindung erreicht ESTABLISHED;
keine unerwarteten Reset-Segmente entstehen;
Daten werden in beiden Richtungen übertragen;
ACKs bestätigen die erwarteten Sequenzbereiche;
Retransmissionsrate entspricht der Baseline;
Anwendung antwortet innerhalb der vorgesehenen Frist;
TLS funktioniert, sofern vorgesehen;
Proxy erreicht sein Backend;
Load Balancer verwendet gesunde Backends;
NAT- und Firewallzustand bleiben während der Sitzung bestehen;
wiederverwendete Verbindungen funktionieren;
Verhalten nach repräsentativer Inaktivität ist korrekt;
Verbindung wird kontrolliert beendet;
keine dauerhaft wachsenden CLOSE-WAIT-Bestände entstehen;
TIME-WAIT-Bestand ist zur Arbeitslast plausibel;
mehrere aufeinanderfolgende Versuche funktionieren;
weitere repräsentative Clients funktionieren;
temporäre Capturefilter wurden entfernt;
Aufzeichnungen wurden geschützt oder kontrolliert gelöscht;
Ursache, Maßnahme und Prävention wurden dokumentiert.

Ein einzelner erfolgreicher Three-Way Handshake ist keine vollständige Verifikation der Anwendung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Zielname:
<FQDN>

Zielport:
<TCP-Port>

Adressfamilie:
<IPv4 oder IPv6>

Anwendung:
<Client- und Serveranwendung>

Exakte Fehlermeldung:
<Wortlaut>

Verwendete Quelladresse:
<Adresse und Port>

Verwendete Zieladresse:
<Adresse und Port>

Listener:
<Adresse, Port, Prozess und PID>

Handshake-Befund:
<SYN, SYN/ACK, ACK, RST oder fehlende Antwort>

Socketzustände:
<SYN-SENT, SYN-RECEIVED, ESTABLISHED und weitere>

Anwendungsdaten:
<gesendet, empfangen oder nicht sichtbar>

Timeoutart:
<DNS, Connect, TCP, TLS, Anwendung, Proxy oder Idle>

Timeoutdauer:
<gemessene Dauer>

Reset-Absender:
<nachgewiesener oder vermuteter Erzeuger>

Nachweis des Reset-Absenders:
<Client-, Server- und Zwischenaufzeichnung>

Retransmissions:
<Anzahl und Richtung>

FIN-Befund:
<kontrollierter Abbau oder fehlendes FIN>

Zwischenkomponenten:
<Firewall, NAT, Proxy, Load Balancer oder Service Mesh>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

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

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<Handshake, Anwendungstest und weitere Systeme>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Befehl oder Filter
Windows-TCP-Verbindungen	`Get-NetTCPConnection`
Windows `SYN-SENT`	`Get-NetTCPConnection -State SynSent`
Windows `SYN-RECEIVED`	`Get-NetTCPConnection -State SynReceived`
Windows `ESTABLISHED`	`Get-NetTCPConnection -State Established`
Windows `CLOSE-WAIT`	`Get-NetTCPConnection -State CloseWait`
Windows `TIME-WAIT`	`Get-NetTCPConnection -State TimeWait`
Windows-TCP-Test	`Test-NetConnection -ComputerName <Ziel> -Port <Port> -InformationLevel Detailed`
Windows-TCP-Statistik	`netstat -s -p tcp`
Windows-Paketmonitor	`pktmon`
Linux-TCP-Sockets	`ss -tan`
Linux-TCP-Details	`sudo ss -tin`
Linux `SYN-SENT`	`ss -tan state syn-sent`
Linux `SYN-RECEIVED`	`ss -tan state syn-recv`
Linux `ESTABLISHED`	`ss -tan state established`
Linux `CLOSE-WAIT`	`ss -tan state close-wait`
Linux `TIME-WAIT`	`ss -tan state time-wait`
Linux-TCP-Zähler	`nstat -az`
macOS-TCP-Sockets	`netstat -anv -p tcp`
macOS-Prozesszuordnung	`sudo lsof -nP -iTCP`
macOS-Liveansicht	`nettop -m tcp`
TCP-Porttest	`nc -vz <Ziel> <Port>`
HTTP-/HTTPS-Test	`curl --connect-timeout 5 --max-time 15 -v <URL>`
Linux-Aufzeichnung	`sudo tcpdump -ni any 'tcp port <Port>' -c 200`
macOS-Aufzeichnung	`sudo tcpdump -ni <Schnittstelle> 'tcp port <Port>' -c 200`
Wireshark: Port	`tcp.port == <Port>`
Wireshark: initiales SYN	`tcp.flags.syn == 1 && tcp.flags.ack == 0`
Wireshark: SYN/ACK	`tcp.flags.syn == 1 && tcp.flags.ack == 1`
Wireshark: Reset	`tcp.flags.reset == 1`
Wireshark: FIN	`tcp.flags.fin == 1`
Wireshark: Retransmission	`tcp.analysis.retransmission`
Wireshark: Fast Retransmit	`tcp.analysis.fast_retransmission`
Wireshark: Duplicate ACK	`tcp.analysis.duplicate_ack`
Wireshark: TCP-Stream	`tcp.stream == <Nummer>`

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
netsh int ip reset
netsh winsock reset
Set-NetFirewallRule
New-NetFirewallRule
Deaktivieren der Windows-Firewall
kill
kill -9
systemctl stop
systemctl restart
sysctl -w
iptables
nft
ufw disable
firewall-cmd --permanent
docker restart
docker stop
kubectl delete
kubectl rollout restart
pauschales Erhöhen aller Timeouts
aggressives Verkürzen von TIME-WAIT
unkontrolliertes Aktivieren oder Ändern von TCP Keepalive
Deaktivieren von TCP-Offloading ohne Vergleichstest
Neustart von Firewall, Proxy oder Load Balancer

Ein Neustart kann TCP-Zustände, Sessiontabellen und den für die Diagnose wichtigen Ausgangszustand zerstören.

Quellen

Standards

Offizielle Microsoft-Dokumentation

Offizielle Linux-Dokumentation

Offizielle Wireshark-Dokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9.3 UDP-Diagnose und ICMP-Fehlermeldungen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose von UDP-Kommunikation und zugehörigen ICMP- beziehungsweise ICMPv6-Fehlermeldungen.

Nach der Bearbeitung muss unterschieden werden können:

ob ein lokaler UDP-Endpunkt vorhanden ist;
welcher Prozess den UDP-Port besitzt;
ob ein Datagramm den Client tatsächlich verlässt;
ob es den vorgesehenen Server erreicht;
ob die Serveranwendung das Datagramm verarbeitet;
ob eine Antwort erzeugt und zurückgesendet wird;
ob eine Firewall, NAT-Instanz oder andere Zwischenkomponente eingreift;
ob eine ICMP-Fehlermeldung zurückkommt;
ob ein Port geschlossen oder lediglich nicht eindeutig prüfbar ist;
ob Paketgröße, Fragmentierung oder Path MTU beteiligt sind;
ob Unicast, Broadcast oder Multicast verwendet wird;
ob der richtige Host-, Container- oder Pod-Namespace untersucht wird.

UDP besitzt keinen Handshake und keine integrierte Empfangsbestätigung. Ein erfolgreich abgesendetes Datagramm beweist deshalb nicht, dass es den Zielhost oder die Zielanwendung erreicht hat.

Sicherheits- und Wirkungsklassen

Kennzeichnung	Bedeutung
LESEND	Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV	Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV	Kann interne Adressen, Verbindungen oder Nutzdaten sichtbar machen.
ÄNDERND	Verändert Konfiguration oder Laufzeitzustand.
AUSFALLRISIKO	Kann Verbindungen, Dienste oder Netzwerkkomponenten beeinträchtigen.

UDP-Dienste dürfen nur mit gültigen, erwarteten und autorisierten Anfragen getestet werden. Unkontrollierte oder sehr schnelle UDP-Anfragen können:

Dienste überlasten;
Rate Limits auslösen;
Intrusion-Detection-Systeme alarmieren;
Verstärkungsangriffe begünstigen;
große Antwortmengen erzeugen;
produktive Protokollzustände beeinflussen.

Grundlegende Eigenschaften von UDP

UDP ist ein minimales, nachrichtenorientiertes Transportprotokoll.

UDP bietet:

Quell- und Zielport;
Datagrammgrenzen;
Längenfeld;
Prüfsumme;
geringen Protokolloverhead;
Unicast-, Broadcast- und Multicast-Kommunikation.

UDP bietet selbst nicht:

Verbindungsaufbau;
Verbindungsabbau;
Empfangsbestätigung;
Sequenznummern;
automatische Wiederholung;
Reihenfolgegarantie;
Duplikatschutz;
Flusskontrolle;
Überlastkontrolle;
Sitzungserkennung;
zuverlässige Erkennung einer ausgefallenen Gegenstelle.

Eine Anwendung oder ein über UDP betriebenes Protokoll kann solche Funktionen selbst implementieren. Beispiele sind:

DNS mit eigenen Wiederholungen und TCP-Fallback;
QUIC mit eigener Zuverlässigkeit und Überlastkontrolle;
anwendungsspezifische Sequenznummern;
Zeitstempel;
Request-IDs;
Heartbeats;
Bestätigungsdatagramme.

TCP und UDP vergleichen

Merkmal	TCP	UDP
Verbindungsaufbau	Three-Way Handshake	kein Handshake
Datenmodell	Bytestrom	einzelne Datagramme
Bestätigung	TCP-ACK	nicht in UDP enthalten
Reihenfolge	durch TCP sichergestellt	nicht sichergestellt
Wiederholung	durch TCP	nur durch Anwendung
Flusskontrolle	vorhanden	nicht vorhanden
Überlastkontrolle	vorhanden	nicht in UDP selbst
Verbindungszustände	unter anderem `LISTEN`, `ESTABLISHED`	keine entsprechenden TCP-Zustände
Reaktion bei geschlossenem Port	normalerweise TCP Reset	möglicherweise ICMP Port Unreachable
Porttest	TCP-Handshake liefert klares Ergebnis	ohne Protokollantwort häufig mehrdeutig

Ein Test von TCP-Port 53 beweist nicht, dass UDP-Port 53 funktioniert. Umgekehrt beweist eine erfolgreiche UDP-DNS-Abfrage nicht automatisch, dass DNS über TCP funktioniert.

UDP-Header

Der UDP-Header besitzt vier Felder:

Quellport
Zielport
Länge
Prüfsumme

Die Mindestlänge eines UDP-Datagramms beträgt acht Byte, weil der UDP-Header selbst acht Byte groß ist.

Feld	Größe	Bedeutung
Source Port	16 Bit	Port des Senders
Destination Port	16 Bit	Port des Empfängers
Length	16 Bit	Gesamtlänge von UDP-Header und UDP-Nutzdaten
Checksum	16 Bit	Prüfsumme über relevante IP-, UDP- und Nutzdatenfelder

UDP enthält keine Felder für:

Sequenznummer;
Bestätigungsnummer;
Empfangsfenster;
SYN;
FIN;
RST.

Bei IPv4 kann eine UDP-Prüfsumme gemäß der ursprünglichen UDP-Spezifikation als nicht verwendet gekennzeichnet sein. Bei IPv6 ist eine gültige UDP-Prüfsumme grundsätzlich erforderlich; nur eng definierte Sonderfälle besitzen Ausnahmen.

UDP-Kommunikation eindeutig bestimmen

Ein UDP-Datagramm wird durch folgende Angaben eingeordnet:

Quell-IP-Adresse
Quellport
Ziel-IP-Adresse
Zielport
Transportprotokoll UDP

Beispiel:

Client: 192.0.2.100:53124
Server: 192.0.2.53:53

Anfrage:

192.0.2.100:53124 → 192.0.2.53:53 UDP

Antwort:

192.0.2.53:53 → 192.0.2.100:53124 UDP

Eine Stateful Firewall oder NAT-Instanz kann diese Angaben verwenden, um einen zeitlich begrenzten Pseudo-Sitzungszustand zu verwalten. UDP selbst erzeugt diesen Zustand nicht.

UDP besitzt keinen Listenerzustand wie TCP

Werkzeuge sprechen bei UDP teilweise trotzdem von „Listening“, weil ein Prozess einen UDP-Endpunkt gebunden hat.

Technisch bedeutet der Befund:

Ein UDP-Socket ist an eine lokale Adresse und einen lokalen Port gebunden.

Der Befund beweist nicht:

dass eine bestimmte Anfrage korrekt formatiert ist;
dass die Anwendung das Datagramm liest;
dass die Anwendung antwortet;
dass der Rückweg funktioniert;
dass die Firewall den Datenverkehr erlaubt;
dass NAT die Antwort richtig zuordnet;
dass der Dienst auf Anwendungsebene gesund ist.

Verbundener UDP-Socket

Eine Anwendung kann einen UDP-Socket mit einer Gegenstelle „verbinden“.

Dieser Vorgang führt nicht zu einem Netzwerk-Handshake. Das Betriebssystem kann dadurch lediglich:

eine Standardzieladresse hinterlegen;
eingehende Datagramme auf eine Gegenstelle begrenzen;
bestimmte ICMP-Fehler dem Socket zuordnen;
normale send- und receive-Aufrufe ermöglichen.

Ein als verbunden dargestellter UDP-Socket beweist deshalb keine erreichbare Gegenstelle.

Was ein erfolgreicher send-Aufruf beweist

Wenn eine Anwendung ein UDP-Datagramm erfolgreich an das Betriebssystem übergibt, bedeutet das zunächst:

Der lokale Netzwerkstack hat das Datagramm zur Übertragung angenommen.

Es beweist nicht:

dass die Netzwerkkarte es gesendet hat;
dass es die lokale Firewall passiert hat;
dass es den Zielhost erreicht hat;
dass ein Prozess am Zielport lauscht;
dass die Zielanwendung es verarbeitet hat;
dass eine Antwort erzeugt wurde;
dass die Antwort den Client erreicht.

Für einen belastbaren Nachweis sind Protokollantwort, Serverprotokoll oder korrelierte Paketaufzeichnung notwendig.

Erwarteten UDP-Ablauf festlegen

Vor der Diagnose müssen mindestens folgende Angaben dokumentiert werden:

Anwendung:
<Dienst oder Protokoll>

Quellhost:
<Hostname und IP-Adresse>

Zielhost:
<Hostname und IP-Adresse>

Quellport:
<fest oder dynamisch>

Zielport:
<UDP-Port>

Adressfamilie:
<IPv4 oder IPv6>

Anfrage:
<erwartete gültige Protokollnachricht>

Erwartete Antwort:
<Antworttyp oder bewusst keine Antwort>

Timeout:
<Anwendungsfrist>

Kommunikationsart:
<Unicast, Broadcast oder Multicast>

Zwischenkomponenten:
<Firewall, NAT, Load Balancer, Proxy oder Tunnel>

Bei einem Protokoll ohne Antwort muss der Nachweis auf der Empfängerseite erfolgen.

UDP-Diagnose benötigt ein protokollspezifisches Werkzeug

Ein allgemeiner UDP-Test kann häufig nur ein Datagramm senden. Er kann nicht sicher bestimmen, ob ein beliebiger UDP-Dienst korrekt arbeitet.

Geeignete Tests sind beispielsweise:

Protokoll	Geeigneter Nachweis
DNS	gültige DNS-Abfrage mit `Resolve-DnsName` oder `dig`
NTP	gültige Zeitabfrage mit vorgesehenem NTP-Werkzeug
SNMP	gültige, autorisierte SNMP-Abfrage
TFTP	kontrollierter TFTP-Protokolltest
Syslog	Empfang im vorgesehenen Logziel bestätigen
RADIUS	autorisierter Test mit passendem RADIUS-Werkzeug
QUIC/HTTP/3	HTTP/3-fähiger Client und Serverprotokolle
anwendungsspezifisches UDP	Herstellerclient, Testfunktion oder definierte Testnachricht

Ein zufälliges oder leeres Datagramm kann von einem korrekt funktionierenden Dienst absichtlich ignoriert werden.

DNS als UDP-Diagnosebeispiel

Windows:

NETZAKTIV

Resolve-DnsName `
  -Name "example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Linux und macOS:

dig \
  @192.0.2.53 \
  example.test \
  A

Vergleich über TCP:

dig \
  @192.0.2.53 \
  example.test \
  A \
  +tcp

Auswertung:

UDP	TCP	Mögliche Einordnung
funktioniert	funktioniert	beide Transportwege grundsätzlich nutzbar
fehlerhaft	funktioniert	UDP-Filterung, Fragmentierung, EDNS oder MTU möglich
funktioniert	fehlerhaft	TCP-Port, Firewall oder TCP-Listener prüfen
beide fehlerhaft	beide Pfade oder DNS-Dienst betroffen	Server, Zone, Routing und Firewall prüfen

Der Vergleich ist protokollspezifisch. Er darf nicht auf beliebige UDP-Dienste übertragen werden.

Allgemeine UDP-Porttests richtig bewerten

Ein Aufruf wie:

nc -vzu 192.0.2.53 53

liefert bei UDP keinen gleichwertigen Nachweis wie ein erfolgreicher TCP-Handshake.

Mögliche Ergebnisse ohne Antwort:

Port ist geöffnet, aber die Anwendung ignoriert die ungültige Anfrage;
Port wird gefiltert;
Datagramm erreicht den Server nicht;
Antwort erreicht den Client nicht;
ICMP-Fehler wird gefiltert;
Zielhost ist ausgefallen;
Anwendung antwortet grundsätzlich nicht;
Werkzeug interpretiert fehlende Antwort als möglichen Erfolg.

nc -u darf deshalb nur zum gezielten Erzeugen eines autorisierten Datagramms verwendet werden. Für die Funktionsprüfung ist ein protokollspezifischer Test erforderlich.

Windows: UDP-Endpunkte erfassen

LESEND

Alle UDP-Endpunkte:

Get-NetUDPEndpoint |
  Sort-Object LocalPort, LocalAddress

Bestimmten UDP-Port prüfen:

Get-NetUDPEndpoint `
  -LocalPort 53

Wesentliche Felder anzeigen:

Get-NetUDPEndpoint |
  Select-Object `
    LocalAddress,
    LocalPort,
    OwningProcess |
  Sort-Object LocalPort, LocalAddress

Zu prüfen sind:

lokale Adresse;
lokaler Port;
Prozess-ID;
IPv4 oder IPv6;
Loopback-, spezifische oder Wildcard-Bindung;
mehrere Prozesse oder Endpunkte;
unerwarteter Netzwerk-Namespace.

Windows: Prozess eines UDP-Endpunkts bestimmen

LESEND

Get-NetUDPEndpoint `
  -LocalPort 53 |
  ForEach-Object {
    $endpoint = $_
    $process = Get-Process `
      -Id $endpoint.OwningProcess `
      -ErrorAction SilentlyContinue

    [pscustomobject]@{
      LocalAddress = $endpoint.LocalAddress
      LocalPort    = $endpoint.LocalPort
      ProcessId    = $endpoint.OwningProcess
      ProcessName  = $process.ProcessName
      ProcessPath  = $process.Path
    }
  }

Einen bekannten Prozess prüfen:

Get-Process `
  -Id 1234

Einem Windows-Dienst zuordnen:

$processId = 1234

Get-CimInstance `
  -ClassName Win32_Service `
  -Filter "ProcessId = $processId" |
  Select-Object `
    Name,
    DisplayName,
    State,
    StartMode,
    ProcessId,
    PathName

Windows: UDP mit netstat prüfen

LESEND

netstat -ano -p udp

Die Ausgabe zeigt unter anderem:

lokale Adresse;
lokalen Port;
Prozess-ID.

UDP besitzt dabei keinen TCP-Zustand wie LISTENING oder ESTABLISHED.

Numerische Darstellung ist für die erste Diagnose vorzuziehen, damit keine Namensauflösung die Ausgabe verändert oder verzögert.

Windows: UDP-Statistiken prüfen

LESEND

IPv4:

netstat -s -p udp

IPv6:

netstat -s -p udpv6

Verfügbare Leistungsindikatoren:

Get-Counter `
  -ListSet "*UDP*"

Die Namen der Leistungsindikatoren können abhängig von Systemsprache und Windows-Version abweichen.

Kumulative Zähler müssen über ein definiertes Zeitfenster verglichen werden. Ein hoher Gesamtwert seit dem Systemstart beweist keine aktuelle Störung.

Windows: Test-NetConnection ist kein UDP-Porttest

Dieser Befehl:

Test-NetConnection `
  -ComputerName "192.0.2.53" `
  -Port 53

prüft TCP-Port 53.

Er prüft nicht UDP-Port 53.

Folgende Schlussfolgerung ist daher unzulässig:

TcpTestSucceeded = True
also funktioniert UDP-Port 53.

Für UDP muss ein passendes Anwendungsprotokoll verwendet oder der Datenweg mit einer Paketaufzeichnung nachgewiesen werden.

Windows: UDP-Test mit PortQry

PortQry ist ein separat bereitzustellendes Microsoft-Diagnosewerkzeug und nicht auf jedem Windows-System vorinstalliert.

NETZAKTIV

portqry.exe -n 192.0.2.53 -p UDP -e 53

Mögliche Einordnung:

PortQry-Ergebnis	Bedeutung
`LISTENING`	PortQry hat eine verwertbare Protokollantwort erhalten.
`NOT LISTENING`	PortQry hat typischerweise ICMP Port Unreachable erhalten.
`LISTENING OR FILTERED`	Es kam keine eindeutige Antwort; geöffnet und still oder gefiltert sind nicht unterscheidbar.

Für einige bekannte Protokolle sendet PortQry speziell formatierte Anfragen. Bei beliebigen UDP-Diensten bleibt ein fehlendes Ergebnis mehrdeutig.

PortQry darf nur gegen autorisierte Zielsysteme eingesetzt werden.

Linux: UDP-Endpunkte mit ss prüfen

LESEND

Gebundene UDP-Endpunkte:

sudo ss -lunp

Alle UDP-Sockets:

sudo ss -uanp

Bestimmten lokalen Port prüfen:

sudo ss -lunp \
  'sport = :53'

Ausgabe ohne Prozessinformationen:

ss -lun

Wichtige Felder:

lokale Adresse;
lokaler Port;
Prozess;
Empfangswarteschlange;
Sendewarteschlange;
IPv4 oder IPv6.

Prozessinformationen können erhöhte Berechtigungen erfordern.

Linux: Prozess mit lsof bestimmen

LESEND

Alle UDP-Sockets:

sudo lsof \
  -nP \
  -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof \
  -nP \
  -iUDP:53

Prozess prüfen:

ps -fp <PID>

Bei systemd:

systemctl status <Dienstname>

Ein laufender Dienst beweist nicht, dass er den erwarteten UDP-Port im richtigen Netzwerk-Namespace gebunden hat.

Linux: UDP-Zähler prüfen

LESEND

Alle Netzwerkstatistiken:

nstat -az

Ausgewählte UDP-Zähler:

nstat -az UdpInDatagrams

nstat -az UdpNoPorts

nstat -az UdpInErrors

nstat -az UdpRcvbufErrors

nstat -az UdpSndbufErrors

Klassische Übersicht:

netstat -su

Schnittstellenzähler:

ip -s link

Mögliche Hinweise:

Zähler	Mögliche Einordnung
`UdpInDatagrams`	empfangene und zugestellte UDP-Datagramme
`UdpNoPorts`	Datagramme für nicht belegte UDP-Ports
`UdpInErrors`	allgemeine UDP-Empfangsfehler
`UdpRcvbufErrors`	Empfangspuffer konnte Datagramme nicht aufnehmen
`UdpSndbufErrors`	Sendepufferfehler
Schnittstellen-Drops	Verlust an oder nahe der Netzwerkschnittstelle

Die genaue Zählerverfügbarkeit hängt von Kernel und Werkzeugversion ab.

macOS: UDP-Endpunkte prüfen

LESEND

sudo lsof \
  -nP \
  -iUDP

Bestimmten UDP-Port prüfen:

sudo lsof \
  -nP \
  -iUDP:53

Socketübersicht:

netstat -anv -p udp

UDP-Statistiken:

netstat -s -p udp

Netzwerkschnittstellen:

ifconfig

Interaktive Netzwerkansicht:

nettop

lsof ist unter macOS für die Zuordnung eines UDP-Ports zu einem Prozess normalerweise geeigneter als netstat.

Empfangswarteschlange und Anwendungsgeschwindigkeit

Ein Datagramm kann den Host erreichen, aber verloren gehen, bevor die Anwendung es verarbeitet.

Mögliche Ursachen:

Anwendung liest nicht schnell genug;
Empfangspuffer ist voll;
CPU-Überlastung;
Prozess hängt;
Workerpool ist erschöpft;
zu hohe Datagrammrate;
Datagramme sind größer als erwartet;
Kernel- oder Schnittstellenpuffer laufen über;
Container besitzt zu geringe Ressourcen;
Anwendung verwirft ungültige oder unerwartete Nachrichten.

Benötigte Nachweise:

Paketaufzeichnung am Empfänger;
UDP- und Schnittstellenzähler;
Socketwarteschlange;
Prozess-CPU und Speicher;
Anwendungsprotokoll;
Rate und Größe der Datagramme;
Vergleich mit einer Baseline.

Wenn ein Datagramm in der Paketaufzeichnung des Servers sichtbar ist, beweist das noch nicht, dass die Anwendung es aus dem Socket gelesen hat.

ICMP ist nicht nur Ping

ICMP dient zur Übertragung von Kontroll- und Fehlermeldungen für IP.

Ping verwendet:

ICMP Echo Request;
ICMP Echo Reply.

ICMP umfasst jedoch zusätzlich Meldungen wie:

Destination Unreachable;
Port Unreachable;
Time Exceeded;
Fragmentation Needed;
Packet Too Big;
Parameter Problem;
Redirect.

ICMPv4 und ICMPv6 sind nicht identisch. Sie verwenden unterschiedliche Typen, Codes und Protokollmechanismen.

Das vollständige Blockieren von ICMP kann Fehlerdiagnose und Path MTU Discovery beeinträchtigen. Bei IPv6 besitzt ICMPv6 darüber hinaus grundlegende Bedeutung für mehrere IPv6-Funktionen.

ICMP-Fehler einer UDP-Anfrage zuordnen

Eine ICMP-Fehlermeldung enthält Teile des Pakets, das den Fehler ausgelöst hat.

Dadurch können Betriebssystem, Firewall oder Analysewerkzeug die Meldung beispielsweise folgender Kommunikation zuordnen:

192.0.2.100:53124
→ 192.0.2.53:53 UDP

Zu prüfen sind im eingebetteten ursprünglichen Paket:

ursprüngliche Quelladresse;
ursprüngliche Zieladresse;
UDP-Quellport;
UDP-Zielport;
Protokollnummer;
gegebenenfalls weitere Anwendungsdaten.

Bei NAT muss auch die ICMP-Fehlermeldung korrekt zur ursprünglichen internen Kommunikation zurückübersetzt werden.

Häufige ICMPv4-Typen

Typ	Bezeichnung	Typische Bedeutung
`0`	Echo Reply	Antwort auf Echo Request
`3`	Destination Unreachable	Ziel, Protokoll oder Port nicht erreichbar
`5`	Redirect	Hinweis auf einen anderen nächsten Router
`8`	Echo Request	Ping-Anfrage
`11`	Time Exceeded	TTL abgelaufen oder Fragmentwiederherstellung zu langsam
`12`	Parameter Problem	Fehler in einem IP-Headerfeld

ICMP Source Quench ist veraltet und darf nicht als moderner Überlastkontrollmechanismus verwendet werden.

ICMPv4 Destination Unreachable

ICMPv4 verwendet für Destination Unreachable den Typ 3.

Code	Bedeutung
`0`	Network Unreachable
`1`	Host Unreachable
`2`	Protocol Unreachable
`3`	Port Unreachable
`4`	Fragmentation Needed and DF Set
`5`	Source Route Failed
`9`	Network Administratively Prohibited
`10`	Host Administratively Prohibited
`13`	Communication Administratively Prohibited

Nicht jedes Gerät verwendet alle Codes. Firewalls können Fehler außerdem still verwerfen oder andere Meldungen erzeugen.

ICMPv4 Port Unreachable

Typischer Ablauf:

Client → Server:
UDP-Datagramm an Port 9999

Server → Client:
ICMP Destination Unreachable
Type 3, Code 3
Port Unreachable

Mögliche Einordnung:

Zielhost wurde erreicht;
auf dem angesprochenen UDP-Port ist häufig kein passender Endpunkt vorhanden;
eine Firewall oder Zwischenkomponente kann die Meldung erzeugt haben;
NAT- oder Portweiterleitungsziel besitzt keinen passenden UDP-Dienst.

Der genaue Erzeuger muss anhand von Aufzeichnungen und Protokollen bestimmt werden.

ICMPv4 Fragmentation Needed

Typischer Befund:

ICMP Type 3, Code 4
Fragmentation Needed and DF Set

Bedeutung:

ein IPv4-Paket ist für den nächsten Link zu groß;
das Paket darf aufgrund gesetztem DF-Bit nicht fragmentiert werden;
die Meldung kann eine verwendbare MTU enthalten;
der Sender muss die Paketgröße anpassen.

Wenn diese ICMP-Meldung gefiltert wird, kann ein Path-MTU-Black-Hole entstehen:

kleine Datagramme funktionieren
große Datagramme schlagen fehl
keine verwertbare Fehlermeldung erreicht den Sender

ICMPv4 Time Exceeded

ICMPv4 verwendet Typ 11.

Code	Bedeutung
`0`	TTL während der Weiterleitung abgelaufen
`1`	Zeit für Fragmentwiederherstellung abgelaufen

TTL-Ablauf wird unter anderem von Traceroute verwendet, um Zwischenrouter sichtbar zu machen.

Ein Stern in einer Traceroute-Ausgabe beweist nicht, dass der betreffende Router ausgefallen ist. Er kann ICMP-Antworten filtern oder begrenzen und trotzdem normalen Datenverkehr weiterleiten.

Häufige ICMPv6-Typen

Typ	Bezeichnung
`1`	Destination Unreachable
`2`	Packet Too Big
`3`	Time Exceeded
`4`	Parameter Problem
`128`	Echo Request
`129`	Echo Reply

ICMPv6 enthält außerdem wichtige Mechanismen für IPv6. Es darf nicht pauschal wie optionaler Ping-Verkehr behandelt werden.

ICMPv6 Destination Unreachable

ICMPv6 verwendet Typ 1.

Code	Bedeutung
`0`	No Route to Destination
`1`	Communication Administratively Prohibited
`2`	Beyond Scope of Source Address
`3`	Address Unreachable
`4`	Port Unreachable
`5`	Source Address Failed Ingress/Egress Policy
`6`	Reject Route to Destination

Port Unreachable bei IPv6:

ICMPv6 Type 1, Code 4

ICMPv6 Packet Too Big

ICMPv6 verwendet:

Type 2, Code 0

Die Meldung enthält die MTU des nächsten Links.

IPv6-Router fragmentieren weitergeleitete Pakete nicht. Wenn ein Paket zu groß ist, muss der sendende Endpunkt seine Paketgröße anpassen oder selbst geeignete Fragmentierung verwenden.

Das Blockieren von ICMPv6 Packet Too Big kann dazu führen, dass:

kleine UDP-Datagramme funktionieren;
größere Datagramme verschwinden;
Tunnel oder VPN-Pfade betroffen sind;
Anwendungen in Timeouts laufen;
die Ursache fälschlich beim UDP-Dienst gesucht wird.

ICMPv6 Time Exceeded

ICMPv6 verwendet Typ 3.

Code	Bedeutung
`0`	Hop Limit während der Weiterleitung abgelaufen
`1`	Fragment Reassembly Time Exceeded

Das IPv6 Hop Limit entspricht funktional dem IPv4-TTL-Konzept.

ICMPv6 Parameter Problem

ICMPv6 verwendet Typ 4.

Code	Bedeutung
`0`	fehlerhaftes Headerfeld
`1`	unbekannter Next-Header-Typ
`2`	unbekannte IPv6-Option

Die Meldung kann auf das fehlerhafte Feld innerhalb des ursprünglichen Pakets verweisen.

Keine ICMP-Antwort ist mehrdeutig

Wenn auf ein UDP-Datagramm weder eine Anwendungsantwort noch eine ICMP-Fehlermeldung folgt, sind unter anderem möglich:

UDP-Port ist geöffnet, Anwendung antwortet aber nicht auf diese Anfrage;
Anfrage ist ungültig;
Anwendung antwortet grundsätzlich nicht;
Datagramm wurde unterwegs verworfen;
lokale Firewall verwirft es;
Netzwerkfirewall verwirft es;
Zielhost ist nicht erreichbar;
Antwortweg ist fehlerhaft;
ICMP wird gefiltert;
ICMP wird durch Rate Limiting unterdrückt;
NAT-Zustand fehlt;
Server ist überlastet;
Empfangspuffer ist voll;
Anwendung verwirft das Datagramm;
Paketaufzeichnung wurde am falschen Punkt durchgeführt.

Das Ergebnis darf nicht ohne weiteren Nachweis als „Port offen“ oder „Port geschlossen“ dokumentiert werden.

ICMP Rate Limiting berücksichtigen

Hosts und Router können ICMP-Fehlermeldungen begrenzen.

Folgen:

der erste Test liefert ICMP Port Unreachable;
spätere Tests liefern keine Meldung;
nur ein Teil der verlorenen Datagramme erzeugt ICMP;
ein UDP-Scan zeigt uneinheitliche Ergebnisse;
die Abwesenheit von ICMP wird fälschlich als Filterung interpretiert.

Diagnosetests müssen mit geringer, kontrollierter Rate durchgeführt werden.

ICMP-Fehler müssen nicht die Anwendung erreichen

Ob eine Anwendung einen ICMP-Fehler wahrnimmt, hängt ab von:

Betriebssystem;
Socket-API;
verbundenem oder unverbundenem UDP-Socket;
Fehlerwarteschlange;
Anwendungscode;
NAT;
Firewall;
Zuordenbarkeit zum ursprünglichen Datagramm.

Eine Anwendung kann deshalb einen Timeout melden, obwohl in einer Paketaufzeichnung eine ICMP-Fehlermeldung sichtbar ist.

Umgekehrt kann das Betriebssystem einen Socketfehler melden, obwohl die Anwendung selbst keine ICMP-Pakete auswertet.

UDP, MTU und Fragmentierung

Ein UDP-Datagramm bleibt für die Anwendung eine einzelne Nachricht. Auf IP-Ebene kann das zugehörige Paket jedoch fragmentiert werden.

Probleme großer UDP-Datagramme:

Verlust eines Fragments verwirft das gesamte Datagramm;
Firewalls verwerfen Fragmente;
NAT kann Fragmente nicht korrekt zuordnen;
Tunnel reduzieren die nutzbare Path MTU;
Fragmentwiederherstellung läuft in einen Timeout;
ICMP Fragmentation Needed oder Packet Too Big wird blockiert;
Anwendung besitzt keine geeignete Größenanpassung;
unterschiedliche Pfade besitzen unterschiedliche MTUs.

Typischer Befund:

kleine Anfrage funktioniert
kleine Antwort funktioniert
große Antwort schlägt fehl
über VPN tritt der Fehler häufiger auf
Paketaufzeichnung zeigt Fragmente oder ICMP Packet Too Big

IP-Fragmentierung sollte nicht vorsorglich erzwungen werden. Die Anwendung muss geeignete Nachrichtengrößen und Path-MTU-Verfahren verwenden.

UDP und Checksummen diagnostizieren

Eine ungültige UDP-Prüfsumme kann dazu führen, dass ein Datagramm ohne Anwendungsantwort verworfen wird.

Zu prüfen sind:

wird die Prüfsumme in der Aufzeichnung als gültig angezeigt?
stammt die Aufzeichnung vom sendenden Host?
ist Checksum Offloading aktiv?
zeigt eine externe Aufzeichnung denselben Befund?
steigen UDP-Checksum- oder Eingangsfehlerzähler?
tritt der Fehler nur auf einer Schnittstelle auf?

Wie bei TCP kann eine lokal vor der Netzwerkkarte aufgenommene Prüfsumme scheinbar fehlerhaft sein, obwohl sie später durch die Hardware korrekt berechnet wird.

Eine einzelne lokale Anzeige Bad Checksum ist deshalb kein ausreichender Fehlernachweis.

Unicast, Broadcast und Multicast unterscheiden

Kommunikationsart	Ziel
Unicast	genau ein IP-Endpunkt
Broadcast	alle geeigneten IPv4-Teilnehmer eines Broadcastbereichs
Multicast	Mitglieder einer Multicastgruppe

Bei Broadcast und Multicast sind zusätzlich zu prüfen:

richtige Zieladresse;
richtige lokale Schnittstelle;
Broadcastberechtigung des Sockets;
Multicastgruppenmitgliedschaft;
IGMP bei IPv4;
MLD bei IPv6;
Switch-Snooping;
VLAN;
TTL beziehungsweise Hop Limit;
Routerunterstützung;
Firewallregeln;
Anwendung mit mehreren Schnittstellen;
erwartetes Antwortverhalten.

Ein Dienst kann auf Unicast funktionieren und auf Broadcast oder Multicast dennoch fehlschlagen.

IPv6 verwendet keinen Broadcast. Vergleichbare Aufgaben werden dort durch Multicastmechanismen umgesetzt.

Stateful Firewall und UDP

Eine Stateful Firewall kann für UDP einen temporären Zustand anhand des Datenflusses anlegen.

Beispiel:

Client 192.0.2.100:53124
→ Server 192.0.2.53:53

erwartete Antwort:
Server 192.0.2.53:53
→ Client 192.0.2.100:53124

Zu prüfen sind:

Quell- und Zieladresse;
Quell- und Zielport;
UDP-Protokoll;
Richtung des ersten Datagramms;
Zustandstimer;
erwartete Antwortadresse;
erwarteter Antwortport;
NAT-Übersetzung;
asymmetrischer Rückweg;
Rate Limits.

Wenn die Antwort erst nach Ablauf des Firewallzustands eintrifft, kann sie verworfen werden.

NAT und UDP

NAT kann eine interne Kommunikation wie folgt übersetzen:

intern:
192.0.2.100:53124

extern:
203.0.113.10:62000

Ziel:
198.51.100.53:53

Die Antwort muss an die übersetzte Adresse und den übersetzten Port zurückkehren:

198.51.100.53:53
→ 203.0.113.10:62000

Mögliche Fehler:

NAT-Zustand läuft zu früh ab;
Antwort verwendet unerwartete Quelladresse;
Antwort kommt von anderem Serverport;
asymmetrischer Rückweg umgeht die NAT-Instanz;
ICMP-Fehler wird nicht korrekt zurückübersetzt;
mehrere Clients kollidieren durch fehlerhafte Portzuordnung;
Portweiterleitung wurde nur für TCP eingerichtet;
interne und externe UDP-Ports stimmen nicht überein.

TCP- und UDP-Portweiterleitungen müssen getrennt konfiguriert werden.

Load Balancer und UDP

Ein UDP-Load-Balancer kann Datagramme anhand des Flows einem Backend zuordnen.

Zu prüfen sind:

Frontendadresse;
Frontendport;
Protokoll UDP;
Backendport;
Health-Check-Protokoll;
Flow-Hash;
Quellportverhalten;
UDP-Idle-Timeout;
Rückweg über denselben Load Balancer;
Direct Server Return;
Backendzustand;
Antwortquelladresse.

Wenn ein Client bei jedem Datagramm einen anderen Quellport verwendet, kann ein Load Balancer unterschiedliche Backends auswählen.

Ein erfolgreicher Health Check beweist nicht automatisch, dass der produktive UDP-Pfad funktioniert.

Docker: UDP-Veröffentlichung prüfen

Docker-Portveröffentlichungen müssen das Transportprotokoll berücksichtigen.

Beispiel:

53:53/udp

Ohne /udp wird eine Veröffentlichung typischerweise als TCP-Veröffentlichung behandelt.

Laufende Container und Ports:

LESEND

docker ps \
  --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Portzuordnung:

docker port <Containername>

Ausführliche Konfiguration:

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

UDP-Endpunkt im Container:

docker exec \
  <Containername> \
  ss -lunp

Compose-Beispiel:

ports:
  - "53:53/udp"

Zu prüfen sind:

wurde UDP ausdrücklich veröffentlicht?
stimmt der Hostport?
stimmt der Containerport?
lauscht die Anwendung im Container?
ist sie an Loopback oder an die Containeradresse gebunden?
verwendet der Client Hostadresse oder Containeradresse?
blockiert die Hostfirewall?
existiert eine passende NAT-Regel?

EXPOSE 53/udp im Image veröffentlicht den Port nicht automatisch auf dem Host.

Kubernetes: UDP-Service prüfen

Wenn protocol nicht angegeben wird, verwendet ein Kubernetes-Service standardmäßig TCP. Für UDP muss das Protokoll ausdrücklich passen.

Beispiel:

ports:
  - name: dns-udp
    protocol: UDP
    port: 53
    targetPort: 53

Service anzeigen:

kubectl get service \
  <Servicename> \
  -n <Namespace> \
  -o yaml

Service beschreiben:

kubectl describe service \
  <Servicename> \
  -n <Namespace>

EndpointSlices:

kubectl get endpointslice \
  -n <Namespace> \
  -l kubernetes.io/service-name=<Servicename> \
  -o wide

UDP-Endpunkt im Pod:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -- ss -lunp

Bei mehreren Containern:

kubectl exec \
  -n <Namespace> \
  <Podname> \
  -c <Containername> \
  -- ss -lunp

Zu prüfen sind:

protocol: UDP;
Service-port;
targetPort;
Pod-Endpunkt;
Service-Selektor;
EndpointSlices;
Readiness;
NetworkPolicy;
CNI-Implementierung;
NodePort oder Load Balancer;
Rückweg;
UDP-Idle-Timeout.

Ein eingetragener containerPort erzeugt keinen UDP-Endpunkt.

Windows-Paketaufzeichnung mit pktmon

pktmon verändert den Aufzeichnungszustand und erstellt Dateien.

SENSITIV · ÄNDERND

Vorhandene Aufzeichnung stoppen:

pktmon stop

Vorhandene Filter entfernen:

pktmon filter remove

UDP-Port 53 erfassen:

pktmon filter add UDP53 -t UDP -p 53

ICMPv4 ergänzen:

pktmon filter add ICMPv4 -t ICMP

ICMPv6 ergänzen:

pktmon filter add ICMPv6 -t ICMPV6

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\udp53.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

In PCAPNG konvertieren:

pktmon etl2pcap C:\Temp\udp53.etl --out C:\Temp\udp53.pcapng

Filter zurücknehmen:

pktmon filter remove

Das Zielverzeichnis muss vorhanden sein. Aufzeichnung, Filter und erzeugte Dateien müssen nach der Diagnose kontrolliert behandelt werden.

Paketaufzeichnung unter Linux

UDP und ICMP gemeinsam:

SENSITIV · LESEND

sudo tcpdump \
  -ni any \
  '(udp port 53) or icmp or icmp6' \
  -c 200

Auf bestimmte Gegenstelle begrenzen:

sudo tcpdump \
  -ni any \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni any \
  -s 0 \
  -w /tmp/udp53.pcap \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)'

Nach reproduziertem Fehler mit Strg+C beenden.

Paketaufzeichnung unter macOS

Verfügbare Schnittstellen:

tcpdump -D

Auf konkreter Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)' \
  -c 200

In Datei schreiben:

sudo tcpdump \
  -ni en0 \
  -s 0 \
  -w /tmp/udp53.pcap \
  'host 192.0.2.53 and ((udp port 53) or icmp or icmp6)'

Bei lokalem Verkehr muss gegebenenfalls lo0 statt der physischen Schnittstelle verwendet werden.

Wireshark-Filter für UDP und ICMP

Alle UDP-Pakete:

udp

Bestimmter UDP-Port:

udp.port == 53

Bestimmte Adresse und Port:

ip.addr == 192.0.2.53 && udp.port == 53

ICMPv4:

icmp

ICMPv6:

icmpv6

ICMPv4 Destination Unreachable:

icmp.type == 3

ICMPv4 Port Unreachable:

icmp.type == 3 && icmp.code == 3

ICMPv4 Fragmentation Needed:

icmp.type == 3 && icmp.code == 4

ICMPv4 Time Exceeded:

icmp.type == 11

ICMPv6 Port Unreachable:

icmpv6.type == 1 && icmpv6.code == 4

ICMPv6 Packet Too Big:

icmpv6.type == 2

ICMPv6 Time Exceeded:

icmpv6.type == 3

UDP und beide ICMP-Versionen:

udp || icmp || icmpv6

Eine ICMP-Meldung muss zusammen mit dem darin eingebetteten ursprünglichen Paket ausgewertet werden.

Client- und Serveraufzeichnung vergleichen

Clientaufzeichnung	Serveraufzeichnung	Mögliche Einordnung
UDP-Anfrage sichtbar	Anfrage nicht sichtbar	Verlust oder Filterung vor dem Server
Anfrage sichtbar	Anfrage sichtbar	Hinweg bis zum Aufzeichnungspunkt funktioniert
keine Antwort	Anwendung protokolliert Anfrage nicht	Socket, lokaler Filter oder Anwendungsverarbeitung
keine Antwort	Anwendung protokolliert Anfrage	Anwendung erzeugt keine oder verspätete Antwort
Antwort verlässt Server	Antwort erreicht Client nicht	Rückweg, NAT oder Firewall
ICMP Port Unreachable am Client	Server erzeugt ICMP	Zielport wahrscheinlich nicht gebunden
ICMP nur am Client sichtbar	Server zeigt keine Meldung	Zwischenkomponente als Erzeuger möglich
ICMP verlässt Server	Client erhält es nicht	Rückweg oder ICMP-Filterung
kleine Datagramme funktionieren	große erreichen Server nicht	MTU, Fragmentierung oder Filterung
Anfrage und Antwort sichtbar	Anwendung meldet Timeout	Socketzuordnung, Frist oder Anwendungslogik

Typische UDP-Paketfolgen

Erfolgreiche Anfrage mit Antwort

Client → Server  UDP-Anfrage
Server → Client  UDP-Antwort

Geschlossener UDP-Port

Client → Server  UDP-Anfrage
Server → Client  ICMP Port Unreachable

Stilles Verwerfen

Client → Server  UDP-Anfrage
keine Antwort
keine ICMP-Meldung

Server verarbeitet Anfrage nicht

Client → Server  UDP-Anfrage
Anfrage erreicht Serverschnittstelle
keine Anwendungsantwort

Rückwegfehler

Client → Server  UDP-Anfrage
Server → Client  UDP-Antwort
Antwort erreicht Client nicht

Path-MTU-Problem

kleine UDP-Datagramme funktionieren
großes UDP-Datagramm wird verworfen
ICMP Fragmentation Needed oder Packet Too Big

Traceroute und ICMP Time Exceeded

Traceroute nutzt schrittweise erhöhte TTL- beziehungsweise Hop-Limit-Werte. Zwischenrouter können darauf mit ICMP Time Exceeded antworten.

Linux mit UDP-Probes:

NETZAKTIV

traceroute \
  -U \
  -p 33434 \
  192.0.2.53

IPv6:

traceroute \
  -6 \
  2001:db8::53

Die genaue Standardmethode von Traceroute hängt von Betriebssystem und Implementierung ab.

Ein unvollständiger Traceroute beweist keinen vollständigen Pfadausfall. Router können:

ICMP-Antworten filtern;
Antworten begrenzen;
nur Datenverkehr weiterleiten;
für Antwort und Weiterleitung unterschiedliche Richtlinien verwenden;
auf einem asymmetrischen Rückweg antworten.

Hypothese und Gegenbeweis

Beispiel für einen geschlossenen UDP-Port:

Hypothese:
Auf dem Server ist kein UDP-Endpunkt an Port 9999 gebunden.

Erwarteter Befund:
Die lokale Socketliste zeigt keinen UDP-Endpunkt auf Port 9999.
Die Serveraufzeichnung zeigt die eingehende UDP-Anfrage.
Der Server sendet ICMP Port Unreachable zurück.

Gegenbeweis:
Ein Prozess besitzt UDP-Port 9999 und protokolliert die eingehende Anfrage.

Testmethode:
Socketliste, Prozesszuordnung und korrelierte Paketaufzeichnung.

Risiko:
Die Anfrage erzeugt Netzwerkverkehr und muss dem erwarteten Protokoll entsprechen.

Beispiel für einen Rückwegfehler:

Hypothese:
Die UDP-Antwort verlässt den Server, wird aber durch eine Firewall
auf dem Rückweg verworfen.

Erwarteter Befund:
Die Serveraufzeichnung zeigt die ausgehende Antwort.
Die Clientaufzeichnung zeigt diese Antwort nicht.
Die Firewall protokolliert einen Drop für den Antwortflow.

Gegenbeweis:
Die Clientaufzeichnung zeigt die Antwort vollständig.

Testmethode:
Zeitgleiche Aufzeichnung auf Client und Server sowie Firewallprotokoll.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko
UDP-Endpunkt starten oder Bindung korrigieren	fehlender Endpunkt bestätigt	geänderte Erreichbarkeit
Firewallregel für UDP korrigieren	UDP-Drop nachgewiesen	unbeabsichtigte Freigabe
ICMP-Regel korrigieren	benötigte Fehlermeldung wird nachweislich blockiert	zusätzliche Kontrollmeldungen werden zugelassen
NAT-Regel um UDP ergänzen	nur TCP oder falsches Protokoll bestätigt	öffentliche Erreichbarkeit ändert sich
UDP-Idle-Timeout abstimmen	ablaufender Sitzungszustand bestätigt	mehr Zustands- und Speicherverbrauch
Antwortquelladresse korrigieren	falsche Quelladresse bestätigt	Routing und Dienstbindung ändern sich
Datagrammgröße reduzieren	MTU- oder Fragmentierungsproblem bestätigt	Protokollverhalten oder Leistung ändert sich
Receive Buffer anpassen	Pufferüberlauf nachgewiesen	höherer Speicherverbrauch
Anwendungsgeschwindigkeit verbessern	Empfangsverlust durch Verarbeitung bestätigt	Anwendungsänderung erforderlich
Docker-Publish auf `/udp` korrigieren	fehlende UDP-Veröffentlichung bestätigt	Container muss eventuell neu erstellt werden
Kubernetes-Service auf UDP korrigieren	falsches Serviceprotokoll bestätigt	produktiver Servicepfad ändert sich
Multicastmitgliedschaft korrigieren	fehlende Gruppenmitgliedschaft bestätigt	zusätzlicher Multicastempfang
Rate Limit anpassen	legitimer Verkehr wird nachweislich begrenzt	Überlastungs- und Missbrauchsrisiko

Vor jeder Änderung sind Ausgangszustand, Risiko, Rückweg und Erfolgskriterium zu dokumentieren.

Systematischer Diagnoseablauf

Exakte Fehlermeldung und Zeitpunkt aufnehmen.
Anwendung und Protokoll bestimmen.
Bestätigen, dass tatsächlich UDP verwendet wird.
Quell- und Zieladresse dokumentieren.
Quell- und Zielport dokumentieren.
IPv4 und IPv6 unterscheiden.
Unicast, Broadcast oder Multicast bestimmen.
Erwartete Anfrage und Antwort beschreiben.
Lokalen UDP-Endpunkt auf dem Server prüfen.
Besitzenden Prozess bestimmen.
Richtige Bindungsadresse prüfen.
Host-, Container- und Pod-Namespace unterscheiden.
Anwendungsprotokolle auf dem Server prüfen.
Protokollspezifischen Test vom Client durchführen.
UDP-Anfrage auf dem Client erfassen.
Prüfen, ob die Anfrage den Server erreicht.
Prüfen, ob die Anwendung die Anfrage verarbeitet.
Prüfen, ob eine Antwort erzeugt wird.
Prüfen, ob die Antwort den Client erreicht.
Quelladresse und Quellport der Antwort prüfen.
ICMPv4- und ICMPv6-Meldungen auswerten.
ICMP-Erzeuger und eingebettetes Originalpaket prüfen.
Stateful Firewall und UDP-Zustand prüfen.
NAT-Übersetzung und Rückweg prüfen.
Idle-Timeouts berücksichtigen.
UDP- und Schnittstellenzähler vergleichen.
Empfangspuffer und Anwendungsleistung prüfen.
Kleine und große gültige Datagramme vergleichen.
MTU, Fragmentierung und Tunnel berücksichtigen.
Bei Multicast Gruppenmitgliedschaft und Switch prüfen.
Hypothese und Gegenbeweis formulieren.
Genau eine kontrollierte Maßnahme durchführen.
Identischen Test wiederholen.
Anwendung und mehrere Versuche verifizieren.
Temporäre Aufzeichnung und Filter zurücknehmen.
Ursache und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
kein lokaler UDP-Endpunkt	Dienst fehlt oder falscher Namespace	Prozess und Dienststart prüfen
Endpunkt nur auf Loopback	nur lokale Erreichbarkeit	Sollbindung prüfen
Endpunkt vorhanden, Anfrage erreicht Server nicht	Netzwerk oder Firewall	Client- und Zwischenaufzeichnung
Anfrage erreicht Server, Anwendung sieht sie nicht	Socket, Firewall oder Puffer	Prozesslog und UDP-Zähler
Anwendung sieht Anfrage, antwortet nicht	Protokoll oder Anwendung	Anwendungslogik prüfen
Antwort verlässt Server, erreicht Client nicht	Rückweg, NAT oder Firewall	Client- und Firewallaufzeichnung
ICMP Port Unreachable	Zielport nicht gebunden oder aktive Ablehnung	lokale Socketliste
ICMP Administratively Prohibited	Richtlinie blockiert	Firewall- oder Routerkonfiguration
keine Antwort und kein ICMP	geöffnet/still oder gefiltert	serverseitige Aufzeichnung
kleine Datagramme funktionieren	Basispfad funktioniert	größere gültige Nachricht testen
große Datagramme scheitern	MTU, Fragmentierung oder Puffer	ICMP und Fragmente erfassen
ICMP Fragmentation Needed	IPv4-Paket zu groß und DF gesetzt	Path MTU prüfen
ICMPv6 Packet Too Big	IPv6-Paket überschreitet Path MTU	gemeldete MTU auswerten
`UdpNoPorts` steigt	Datagramme erreichen ungebundene Ports	Zielport und Dienst prüfen
`UdpRcvbufErrors` steigt	Empfangspuffer überlastet	Datenrate und Anwendung prüfen
nur nach Inaktivität fehlerhaft	UDP-Zustand abgelaufen	Firewall-/NAT-Timeout
neue Anfrage funktioniert sofort	alter Pseudo-Sitzungszustand fehlerhaft	Flow und Quellport vergleichen
Docker zeigt nur TCP-Publish	UDP nicht veröffentlicht	Portkonfiguration prüfen
Kubernetes-Service nutzt TCP	falsches Serviceprotokoll	Manifest korrigieren
Service hat keine Endpunkte	Selektor oder Readiness	Pods und EndpointSlices
Multicast nur auf einem Host fehlerhaft	Gruppenmitgliedschaft oder Schnittstelle	IGMP/MLD und Socket prüfen
Wireshark zeigt Bad Checksum nur lokal	Checksum Offloading möglich	externe Aufzeichnung
PortQry meldet `LISTENING OR FILTERED`	Ergebnis nicht eindeutig	gültiger Protokolltest und Servertrace

Typische Diagnosefehler

TCP- und UDP-Port mit derselben Nummer gleichsetzen.
Test-NetConnection -Port als UDP-Test verwenden.
Einen erfolgreichen Ping als UDP-Nachweis bewerten.
Einen UDP-Endpunkt als vollständigen Funktionsnachweis behandeln.
Von einem erfolgreichen send-Aufruf auf die Zustellung schließen.
nc -u als eindeutigen Porttest verwenden.
Eine ungültige Testnachricht an einen Dienst senden.
Aus fehlender Antwort auf einen geschlossenen oder gefilterten Port schließen.
LISTENING OR FILTERED als sicher geöffnet interpretieren.
ICMP ausschließlich mit Ping gleichsetzen.
Alle ICMP-Meldungen blockieren.
ICMPv4 und ICMPv6 verwechseln.
ICMP Port Unreachable nicht dem eingebetteten Paket zuordnen.
ICMP-Quelladresse ohne weiteren Nachweis als Erzeuger behandeln.
ICMP Rate Limiting ignorieren.
Nur auf dem Client aufzeichnen.
Antwortquelladresse und Antwortport nicht prüfen.
Stateful Firewallzustand bei UDP ignorieren.
UDP-Idle-Timeout nicht berücksichtigen.
TCP-Portweiterleitung als UDP-Portweiterleitung betrachten.
/udp bei Docker-Portveröffentlichung vergessen.
Kubernetes-protocol nicht prüfen.
containerPort als echten Endpunkt bewerten.
Container- und Host-Namespace verwechseln.
kleine und große Datagramme nicht vergleichen.
Fragmentierung und Tunnel-MTU ignorieren.
eine lokale Bad-Checksum-Anzeige ungeprüft als Fehler bewerten.
Empfangspuffer und Anwendungsleistung ignorieren.
Unicast, Broadcast und Multicast nicht unterscheiden.
Multicastgruppenmitgliedschaft nicht prüfen.
Netzwerkaufzeichnungen unbegrenzt laufen lassen.
UDP-Tests mit hoher Rate durchführen.
Firewall vorsorglich vollständig deaktivieren.
mehrere Variablen gleichzeitig verändern.
nur einen einzelnen erfolgreichen Antwortversuch verifizieren.

Verifikation

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

der richtige UDP-Endpunkt ist vorhanden;
der richtige Prozess besitzt den Port;
richtige Bindungsadresse wird verwendet;
IPv4 funktioniert, sofern vorgesehen;
IPv6 funktioniert, sofern vorgesehen;
der Client verwendet den richtigen Zielport;
die Anfrage verlässt den Client;
die Anfrage erreicht den Server;
die Anwendung verarbeitet die Anfrage;
die Anwendung erzeugt die erwartete Antwort;
die Antwort verwendet die richtige Quelladresse;
die Antwort verwendet den richtigen Quellport;
die Antwort erreicht den Client;
keine unerwarteten ICMP-Fehler entstehen;
ICMP Fragmentation Needed oder Packet Too Big funktioniert;
kleine und repräsentativ große Datagramme funktionieren;
keine UDP-Empfangspufferfehler entstehen;
Firewallzustand bleibt ausreichend lange bestehen;
NAT übersetzt Anfrage, Antwort und ICMP korrekt;
Docker veröffentlicht ausdrücklich UDP;
Kubernetes-Service verwendet protocol: UDP;
port und targetPort stimmen;
EndpointSlices enthalten die vorgesehenen Pods;
Broadcast oder Multicast funktioniert, sofern erforderlich;
mehrere aufeinanderfolgende Versuche funktionieren;
ursprüngliche Anwendung funktioniert;
weitere repräsentative Clients funktionieren;
temporäre Filter wurden entfernt;
Aufzeichnungen wurden geschützt oder kontrolliert gelöscht;
Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine einzelne sichtbare UDP-Antwort ist keine ausreichende Verifikation für alle Clients, Paketgrößen und Netzwerkpfade.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Anwendung:
<Dienst oder Protokoll>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Adressfamilie:
<IPv4 oder IPv6>

Kommunikationsart:
<Unicast, Broadcast oder Multicast>

Quellport:
<Port>

Zielport:
<Port>

Erwartete Anfrage:
<Protokollnachricht>

Erwartete Antwort:
<Antwort oder keine Antwort vorgesehen>

UDP-Endpunkt:
<Adresse, Port, Prozess und PID>

Clientaufzeichnung:
<Anfrage gesendet, Antwort oder ICMP>

Serveraufzeichnung:
<Anfrage empfangen und Antwort gesendet>

ICMP-Befund:
<Typ, Code, Absender und eingebettetes Paket>

Paketgröße:
<UDP- und IP-Größe>

Fragmentierung:
<ja, nein oder unbekannt>

Firewallzustand:
<Befund>

NAT-Zuordnung:
<interne und externe Adressen und Ports>

Timeout:
<gemessene Dauer und verantwortliche Komponente>

UDP-Zähler:
<relevante Differenzen>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

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

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendung und weitere Clients>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Befehl oder Filter
Windows-UDP-Endpunkte	`Get-NetUDPEndpoint`
Windows-UDP-Port	`Get-NetUDPEndpoint -LocalPort <Port>`
Windows-UDP-netstat	`netstat -ano -p udp`
Windows-UDP-Statistik	`netstat -s -p udp`
Windows-UDP-PortQry	`portqry.exe -n <Ziel> -p UDP -e <Port>`
Windows-Paketmonitor	`pktmon`
Windows-DNS-UDP-Test	`Resolve-DnsName -Name <Name> -Server <DNS-IP> -DnsOnly`
Linux-UDP-Endpunkte	`sudo ss -lunp`
Linux-alle UDP-Sockets	`sudo ss -uanp`
Linux-UDP-Port	`sudo ss -lunp 'sport = :<Port>'`
Linux-Prozess zu UDP-Port	`sudo lsof -nP -iUDP:<Port>`
Linux-UDP-Zähler	`nstat -az`
Linux-Schnittstellenzähler	`ip -s link`
macOS-UDP-Sockets	`sudo lsof -nP -iUDP`
macOS-UDP-netstat	`netstat -anv -p udp`
macOS-UDP-Statistik	`netstat -s -p udp`
DNS-UDP-Test	`dig @<DNS-IP> <Name> <Typ>`
DNS-TCP-Vergleich	`dig @<DNS-IP> <Name> <Typ> +tcp`
Linux-Aufzeichnung	`sudo tcpdump -ni any '(udp port <Port>) or icmp or icmp6' -c 200`
macOS-Aufzeichnung	`sudo tcpdump -ni <Interface> '(udp port <Port>) or icmp or icmp6' -c 200`
Wireshark UDP-Port	`udp.port == <Port>`
Wireshark ICMPv4	`icmp`
Wireshark ICMPv6	`icmpv6`
ICMPv4 Port Unreachable	`icmp.type == 3 && icmp.code == 3`
ICMPv4 Fragmentation Needed	`icmp.type == 3 && icmp.code == 4`
ICMPv4 Time Exceeded	`icmp.type == 11`
ICMPv6 Port Unreachable	`icmpv6.type == 1 && icmpv6.code == 4`
ICMPv6 Packet Too Big	`icmpv6.type == 2`
ICMPv6 Time Exceeded	`icmpv6.type == 3`

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Stop-Process
taskkill
Stop-Service
Restart-Service
Set-NetFirewallRule
New-NetFirewallRule
Deaktivieren der Windows-Firewall
netsh int ip reset
netsh winsock reset
kill
kill -9
systemctl stop
systemctl restart
sysctl -w
iptables
nft
ufw disable
firewall-cmd --permanent
docker restart
docker stop
kubectl delete
kubectl rollout restart
unkontrollierte UDP-Portscans
UDP-Lasttests ohne Freigabe
ungefilterte Broadcasts
ungefilterte Multicasttests
pauschales Zulassen aller ICMP-Typen
vollständiges Blockieren von ICMP oder ICMPv6
willkürliche Erhöhung von Socketpuffern
unkontrollierte Änderung von UDP-Idle-Timeouts

Ein Neustart kann Socketzustände, Zähler, NAT-Zuordnungen und den für die Diagnose wichtigen Ausgangszustand zerstören.

Quellen

Standards

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Wireshark-Dokumentation

Offizielle Containerdokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9.4 Lokale Host-Firewall prüfen

Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose einer lokalen Host-Firewall unter Windows, Linux und macOS sowie ihre Abgrenzung von:

fehlenden Listenern;
falschen Bindungsadressen;
Netzwerkfirewalls;
Access Control Lists;
NAT und Portweiterleitungen;
Proxys und Load Balancern;
Container- und Kubernetes-Regeln;
VPN- und Endpoint-Security-Filtern;
Anwendungsfehlern.

Nach der Bearbeitung muss nachvollziehbar geprüft werden können:

welche lokale Firewalltechnik tatsächlich aktiv ist;
welches Netzwerkprofil, welche Zone oder welche Schnittstelle gilt;
welche eingehende und ausgehende Standardaktion verwendet wird;
welche Regel den betroffenen Datenverkehr erlaubt oder blockiert;
aus welcher Richtlinienquelle die wirksame Regel stammt;
ob TCP, UDP, ICMPv4 und ICMPv6 getrennt berücksichtigt wurden;
ob ein Paket den Host erreicht;
ob es durch die Host-Firewall verworfen wird;
ob ein Prozess oder Dienst trotz passender Regel nicht lauscht;
ob Container-, Hypervisor- oder Endpoint-Security-Filter beteiligt sind;
wie eine Änderung sicher vorbereitet und verifiziert wird.

Eine Host-Firewall darf nicht vorsorglich vollständig deaktiviert werden. Zuerst müssen der betroffene Datenfluss und die tatsächlich wirksame Regel nachgewiesen werden.

Sicherheits- und Wirkungsklassen

Kennzeichnung	Bedeutung
LESEND	Erfasst ausschließlich vorhandene Zustände.
NETZAKTIV	Erzeugt Netzwerkverkehr zum geprüften Ziel.
SENSITIV	Kann interne Regeln, Adressen, Programme oder Kommunikationsbeziehungen sichtbar machen.
ÄNDERND	Verändert Firewallkonfiguration oder Protokollierung.
AUSFALLRISIKO	Kann bestehende Verbindungen, Verwaltung oder Dienste beeinträchtigen.

Firewallregeln und Protokolle können sicherheitsrelevante Informationen enthalten:

interne Netze;
Verwaltungsports;
erlaubte Quelladressen;
Anwendungspfade;
Dienstnamen;
Benutzer- und Gruppenbezüge;
VPN-Schnittstellen;
Sicherheitsprodukte;
Cloud- und Containerbereiche.

Diese Informationen müssen geschützt gespeichert und weitergegeben werden.

Aufgabe einer lokalen Host-Firewall

Eine lokale Host-Firewall filtert Netzwerkverkehr direkt auf einem Endgerät oder Server.

Abhängig vom Betriebssystem kann sie prüfen:

eingehenden Verkehr zum lokalen Host;
ausgehenden Verkehr des lokalen Hosts;
weitergeleiteten Verkehr;
Transportprotokoll;
lokale und entfernte Adressen;
lokale und entfernte Ports;
Netzwerkprofil oder Zone;
Schnittstelle;
Programm;
Dienst;
Benutzer;
Paket- oder Verbindungszustand;
IPsec-Authentifizierung;
Container- oder VM-Netzwerkpfade.

Eine Host-Firewall ersetzt keine Netzwerkfirewall. Beide Ebenen können gleichzeitig filtern.

Datenpfad vereinfachen

Eingehender Datenverkehr:

Client
→ Netzwerkfirewall
→ Servernetzwerkschnittstelle
→ lokale Host-Firewall
→ lokaler Socket
→ Anwendung

Ausgehender Datenverkehr:

Anwendung
→ lokaler Socket
→ lokale Host-Firewall
→ Servernetzwerkschnittstelle
→ Netzwerkfirewall
→ Ziel

Container- oder VM-Verkehr kann zusätzlich einen Weiterleitungspfad verwenden:

Client
→ Hostnetzwerkschnittstelle
→ Host-Firewall oder NAT
→ virtuelle Bridge
→ Container- oder VM-Firewall
→ Anwendung

Jede Ebene muss getrennt nachgewiesen werden.

Host-Firewall, Listener und Anwendung unterscheiden

Befund	Aussage
Dienst läuft	Prozessstatus ist vorhanden
Listener vorhanden	Socket wurde gebunden
lokale Verbindung funktioniert	lokaler Netzwerkpfad funktioniert
entfernte Verbindung funktioniert	der getestete Ende-zu-Ende-Pfad funktioniert
Firewallregel vorhanden	eine konfigurierte Regel existiert
Firewallregel wirksam	Regel gilt für den konkreten Datenfluss
Paket wird geloggt	Paket wurde an einem bestimmten Filterpunkt erfasst
Anwendung antwortet	Transport und Anwendung funktionieren für den Test

Eine vorhandene Allow-Regel beweist nicht, dass:

das richtige Profil aktiv ist;
die Regel aktiviert ist;
Protokoll und Port stimmen;
die Quelladresse zum Regelbereich gehört;
das richtige Programm verwendet wird;
keine Blockregel Vorrang hat;
eine zentral verwaltete Richtlinie die Regel überschreibt;
der Dienst tatsächlich lauscht.

Prüfdaten des betroffenen Flows

Vor der Regelsuche muss der Datenfluss exakt dokumentiert werden.

Richtung:
<eingehend oder ausgehend>

Transportprotokoll:
<TCP, UDP, ICMPv4, ICMPv6 oder anderes>

Quelladresse:
<IP-Adresse oder Netz>

Quellport:
<Port oder dynamischer Bereich>

Zieladresse:
<IP-Adresse>

Zielport:
<Port>

Lokales Programm:
<vollständiger Pfad>

Lokaler Dienst:
<Dienstname>

Schnittstelle:
<Ethernet, WLAN, VPN, Loopback oder virtuell>

Netzwerkprofil oder Zone:
<Domain, Private, Public oder Linux-Zone>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Ohne diese Angaben kann nicht sicher entschieden werden, ob eine Firewallregel zum Fehler passt.

Eingehend, ausgehend und weitergeleitet

Richtung	Bedeutung
eingehend	Verkehr ist an den lokalen Host adressiert
ausgehend	Verkehr wird durch einen lokalen Prozess erzeugt
weitergeleitet	Verkehr durchquert den Host zu einem anderen Endpunkt

Unter Linux entsprechen diese Pfade häufig den Netfilter-Hooks beziehungsweise Basischains:

input
output
forward

Ein Paket für einen Container oder eine virtuelle Maschine kann den Hostpfad forward verwenden, obwohl der Client den Hostport anspricht.

Eine Regel im lokalen input-Pfad muss deshalb nicht für weitergeleiteten Containerverkehr gelten.

Loopback ist kein vollständiger Firewalltest

Ein Test gegen:

127.0.0.1
::1
localhost

prüft den Loopbackpfad.

Dieser Test bildet nicht zwingend ab:

die physische Netzwerkschnittstelle;
das aktive Firewallprofil;
die externe Quelladresse;
eine VPN-Schnittstelle;
NAT oder Portweiterleitung;
eine Netzwerkfirewall;
den Container-Weiterleitungspfad.

Auch ein Test gegen die eigene LAN-Adresse vom selben Host kann lokal geroutet werden und muss nicht denselben Pfad wie ein entfernter Client verwenden.

Für eine vollständige Prüfung ist ein repräsentativer externer Client erforderlich.

Firewallzustände richtig interpretieren

Aktion	Typisches Verhalten
Allow oder Accept	passender Verkehr darf den Filterpunkt passieren
Drop	Paket wird ohne aktive Fehlermeldung verworfen
Reject	Paket wird verworfen und es kann eine Ablehnung zurückgesendet werden
Log	Ereignis wird protokolliert; allein keine Allow- oder Blockaktion
Default Deny	nicht ausdrücklich erlaubter Verkehr wird blockiert
Default Allow	nicht ausdrücklich blockierter Verkehr wird erlaubt

Ein TCP-Reset kann entstehen durch:

geschlossenen TCP-Port;
Anwendung;
lokale Firewall mit Reject-Verhalten;
Netzwerkfirewall;
Proxy;
Load Balancer.

Ein Timeout kann durch stilles Drop-Verhalten entstehen, beweist aber nicht automatisch eine Firewallblockierung.

Wirksame Richtlinie statt nur Konfigurationsdatei prüfen

Firewallregeln können stammen aus:

lokaler Konfiguration;
Gruppenrichtlinie;
MDM;
Sicherheitsbaseline;
Endpoint-Security-Software;
Cloudmanagement;
Containerplattform;
Hypervisor;
VPN-Client;
Service Manager;
temporärer Laufzeitkonfiguration.

Entscheidend ist die tatsächlich aktive Richtlinie.

Eine Konfigurationsdatei oder GUI kann vom wirksamen Kernelzustand abweichen, wenn:

Änderungen noch nicht geladen wurden;
Laufzeit- und permanente Konfiguration unterschiedlich sind;
eine zentrale Richtlinie Vorrang besitzt;
ein anderer Firewallmanager verwendet wird;
Containerwerkzeuge eigene Regeln erzeugt haben;
ein Sicherheitsprodukt zusätzliche Filter installiert hat.

Windows-Firewallprofile

Windows verwendet drei Firewallprofile:

Profil	Typische Verwendung
`Domain`	Netzwerk mit erkannter und authentifizierter Active-Directory-Domäne
`Private`	als vertrauenswürdig eingestuftes privates Netzwerk
`Public`	nicht vertrauenswürdiges oder öffentliches Netzwerk

Regeln können für ein oder mehrere Profile gelten.

Ein häufiger Fehler ist:

Allow-Regel gilt nur für Domain oder Private.
Die aktive Schnittstelle verwendet jedoch Public.

Windows kann unterschiedliche Profile gleichzeitig für unterschiedliche Schnittstellen verwenden.

Windows: aktive Netzwerkprofile prüfen

LESEND

Get-NetConnectionProfile |
  Select-Object `
    InterfaceAlias,
    InterfaceIndex,
    Name,
    NetworkCategory,
    IPv4Connectivity,
    IPv6Connectivity

Zu prüfen sind:

richtige Schnittstelle;
aktive Netzwerkkategorie;
VPN-Adapter;
virtuelle Adapter;
unerwartetes Public-Profil;
mehrere gleichzeitig aktive Profile;
IPv4- und IPv6-Konnektivität.

Das Domainprofil darf nicht manuell als Ersatz für eine fehlerhafte Domänenerkennung erzwungen werden. Zuerst müssen DNS, Erreichbarkeit, Authentifizierung und Netzwerkidentifikation geprüft werden.

Windows: Firewallprofile prüfen

LESEND

Get-NetFirewallProfile |
  Select-Object `
    Name,
    Enabled,
    DefaultInboundAction,
    DefaultOutboundAction,
    AllowInboundRules,
    AllowLocalFirewallRules,
    AllowLocalIPsecRules,
    NotifyOnListen,
    LogFileName,
    LogMaxSizeKilobytes,
    LogAllowed,
    LogBlocked

Wirksame Profile aus dem aktiven Richtlinienspeicher:

Get-NetFirewallProfile `
  -PolicyStore ActiveStore |
  Format-List *

Zu dokumentieren sind:

ist das Profil aktiviert?
welche Standardaktion gilt eingehend?
welche Standardaktion gilt ausgehend?
sind lokale Regeln zulässig?
sind lokal konfigurierte IPsec-Regeln zulässig?
werden blockierte Pakete protokolliert?
wo liegt die Protokolldatei?
welche maximale Größe besitzt sie?

Die Standardaktionen dürfen nicht ungeprüft als Block beziehungsweise Allow angenommen werden.

Windows: aktive Regeln erfassen

LESEND

Alle wirksamen Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore

Aktivierte Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True

Aktivierte eingehende Allow-Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Inbound `
  -Action Allow

Aktivierte eingehende Blockregeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Inbound `
  -Action Block

Aktivierte ausgehende Blockregeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True `
  -Direction Outbound `
  -Action Block

Herkunft der Regeln:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Enabled True |
  Select-Object `
    Name,
    DisplayName,
    Direction,
    Action,
    Profile,
    PolicyStoreSourceType,
    PolicyStoreSource

ActiveStore stellt die zusammengeführte aktive Richtlinie der auf das System wirkenden Policy Stores dar. Eine Abfrage ohne -PolicyStore ActiveStore kann eine andere Sicht liefern.

Windows: vollständige Regeldarstellung

LESEND

Show-NetFirewallRule `
  -PolicyStore ActiveStore

Für eine bekannte Regel:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Format-List *

Die eigentlichen Port-, Adress-, Programm- und Dienstbedingungen werden in zugeordneten Filterobjekten verwaltet.

Windows: Portfilter prüfen

LESEND

Alle Portfilter:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore

Regeln für lokalen Port 443 suchen:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore |
  Where-Object LocalPort -eq "443" |
  Get-NetFirewallRule |
  Select-Object `
    Name,
    DisplayName,
    Enabled,
    Direction,
    Action,
    Profile,
    PolicyStoreSourceType,
    PolicyStoreSource

Regeln für entfernten Port 443:

Get-NetFirewallPortFilter `
  -PolicyStore ActiveStore |
  Where-Object RemotePort -eq "443" |
  Get-NetFirewallRule |
  Select-Object `
    Name,
    DisplayName,
    Enabled,
    Direction,
    Action,
    Profile

Danach muss der vollständige Portfilter der gefundenen Regel geprüft werden:

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallPortFilter |
  Format-List *

Zu prüfen sind:

TCP oder UDP;
lokaler Port;
entfernter Port;
ICMP-Typ;
dynamische Schlüsselwörter;
Any oder konkreter Wert.

Windows: Adressfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallAddressFilter |
  Format-List *

Zu prüfen sind:

LocalAddress;
RemoteAddress;
einzelne Hosts;
Subnetze;
Any;
lokale Subnetze;
IPv4 oder IPv6;
dynamische oder richtlinienbasierte Bereiche.

Eine Allow-Regel für:

RemoteAddress = 192.0.2.0/24

gilt nicht für einen Client aus:

198.51.100.0/24

Windows: Programmfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallApplicationFilter |
  Format-List *

Zu prüfen sind:

vollständiger Programmpfad;
aktuell gestartete ausführbare Datei;
geänderter Installationspfad;
neue Programmversion;
32-Bit- oder 64-Bit-Pfad;
symbolische Verknüpfungen;
Launcher und eigentlicher Serverprozess;
Any oder konkretes Programm.

Eine Regel für einen alten Anwendungspfad gilt nicht automatisch für eine neue Programmdatei.

Windows: Dienstfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallServiceFilter |
  Format-List *

Zu prüfen sind:

konkreter Windows-Dienst;
Dienstname statt Anzeigename;
gemeinsam verwendeter Prozess;
Service Hardening;
Any oder konkreter Dienst.

Eine Regel kann für einen Dienst gelten, obwohl mehrere Dienste denselben Prozess wie svchost.exe verwenden.

Windows: Schnittstellenfilter prüfen

LESEND

Get-NetFirewallRule `
  -PolicyStore ActiveStore `
  -Name "<Regelname>" |
  Get-NetFirewallInterfaceFilter |
  Format-List *

Zu prüfen sind:

konkrete Schnittstelle;
Schnittstellentyp;
LAN;
WLAN;
Remote Access;
VPN;
virtuelle Schnittstelle.

Eine Regel für LAN muss nicht für einen VPN- oder WLAN-Pfad gelten.

Windows: Regelbedingungen vollständig dokumentieren

Für eine gefundene Regel müssen mindestens folgende Informationen zusammengeführt werden:

Name:
<Regelname>

Status:
<aktiviert oder deaktiviert>

Richtung:
<eingehend oder ausgehend>

Aktion:
<Allow oder Block>

Profile:
<Domain, Private, Public>

Protokoll:
<TCP, UDP, ICMPv4 oder ICMPv6>

Lokaler Port:
<Port>

Entfernter Port:
<Port>

Lokale Adresse:
<Adresse oder Netz>

Entfernte Adresse:
<Adresse oder Netz>

Programm:
<Pfad>

Dienst:
<Dienstname>

Schnittstelle:
<Filter>

Richtlinienquelle:
<Local, Group Policy, MDM oder andere>

Erst der Vergleich aller Bedingungen mit dem konkreten Datenfluss zeigt, ob die Regel tatsächlich passt.

Windows-Regelvorrang

Für Windows-Firewallregeln gilt unter anderem:

eine ausdrücklich definierte Allow-Regel kann die eingehende Standardblockierung übersteuern;
eine ausdrücklich definierte Blockregel besitzt Vorrang vor einer widersprechenden Allow-Regel;
spezifischere Regeln können gegenüber weniger spezifischen Regeln maßgeblich sein;
zentrale Richtlinien können lokale Konfigurationsmöglichkeiten begrenzen;
Service-Hardening- und IPsec-Anforderungen können zusätzlich wirken.

Windows-Firewallregeln dürfen nicht wie eine einfache von oben nach unten abgearbeitete ACL-Liste interpretiert werden.

Windows: Gruppenrichtlinienbezug prüfen

LESEND

Zusammenfassung der angewendeten Computerrichtlinien:

gpresult /scope computer /r

Wirksame Firewallregeln enthalten zusätzlich:

PolicyStoreSourceType
PolicyStoreSource

Zu prüfen sind:

stammt die Regel aus lokaler Konfiguration?
stammt sie aus einer Domänenrichtlinie?
dürfen lokale Firewallregeln zusammengeführt werden?
wurde die erwartete GPO angewendet?
existiert eine Blockregel aus einer anderen Richtlinie?
wird die Einstellung durch MDM verwaltet?
erscheint eine lokale Änderung nach Richtlinienaktualisierung erneut oder verschwindet sie?

Eine zentral verwaltete Regel darf nicht durch eine lokale Parallelregel umgangen werden.

Windows: Firewallprotokoll prüfen

Der Protokollpfad kann je Profil abweichen und muss über Get-NetFirewallProfile bestimmt werden.

Typischer Standardpfad:

%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log

Letzte Einträge:

LESEND · SENSITIV

Get-Content `
  "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Tail 100

Nach Adresse oder Port suchen:

Get-Content `
  "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Tail 1000 |
  Select-String "192.0.2.100|443"

Zu korrelieren sind:

Aktion;
Datum und Uhrzeit;
Protokoll;
Quell- und Zieladresse;
Quell- und Zielport;
Richtung beziehungsweise Pfad;
betroffene Schnittstelle;
identischer Testzeitpunkt.

Fehlende Einträge beweisen nicht, dass die Firewall nicht beteiligt ist. Protokollierung kann deaktiviert, begrenzt oder an einem anderen Pfad konfiguriert sein.

Windows: temporäre Protokollierung

Vor einer Änderung müssen die vorhandenen Profilwerte dokumentiert werden.

Aktuellen Zustand sichern:

Get-NetFirewallProfile |
  Select-Object `
    Name,
    LogFileName,
    LogMaxSizeKilobytes,
    LogAllowed,
    LogBlocked

Blockprotokollierung für ein bestimmtes Profil aktivieren:

ÄNDERND · SENSITIV

Set-NetFirewallProfile `
  -Profile Domain `
  -LogBlocked True

Die Änderung muss:

autorisiert sein;
auf das betroffene Profil begrenzt werden;
hinsichtlich Speicherbedarf überwacht werden;
nach dem Test auf den dokumentierten Ausgangswert zurückgesetzt werden.

Das Aktivieren der Protokollierung für erlaubte Verbindungen kann sehr große Datenmengen erzeugen.

Windows Filtering Platform prüfen

Windows Filtering Platform, kurz WFP, bildet die Filterplattform für Windows-Firewall, IPsec und weitere Filterkomponenten.

Relevante Security-Ereignisse können sein:

Ereignis-ID	Bedeutung
`5152`	WFP hat ein Paket blockiert.
`5154`	Anwendung oder Dienst durfte auf eingehende Verbindungen lauschen.
`5155`	Anwendung oder Dienst wurde am Lauschen gehindert.
`5156`	WFP hat eine Verbindung erlaubt.
`5157`	WFP hat eine Verbindung blockiert.
`5158`	Bindung an einen lokalen Port wurde erlaubt.
`5159`	Bindung an einen lokalen Port wurde blockiert.

Blockereignisse lesen:

LESEND · SENSITIV

Get-WinEvent `
  -FilterHashtable @{
    LogName = "Security"
    Id      = 5152, 5155, 5157, 5159
  } `
  -MaxEvents 100

Diese Ereignisse stehen nur zur Verfügung, wenn die entsprechenden Überwachungsrichtlinien aktiv waren.

Zu prüfen sind:

Application Name;
Process ID;
Direction;
Source Address;
Source Port;
Destination Address;
Destination Port;
Protocol;
Filter Run-Time ID;
Layer Name;
Zeitpunkt.

Sehr umfangreiche WFP-Überwachung kann viele Ereignisse erzeugen und muss gezielt eingesetzt werden.

Windows: netsh als ergänzende Sicht

LESEND

Profile:

netsh advfirewall show allprofiles

Regeln:

netsh advfirewall firewall show rule name=all verbose

Überwachungszustand:

netsh advfirewall monitor show firewall

Der ältere Kontext:

netsh firewall

sollte nicht mehr für die aktuelle Verwaltung verwendet werden. Für moderne Systeme sind PowerShell-NetSecurity-Cmdlets und netsh advfirewall vorgesehen.

Windows: Drittanbieterfilter berücksichtigen

Verkehr kann blockiert werden, obwohl keine passende Windows-Firewall-Blockregel sichtbar ist.

Mögliche zusätzliche Filter:

Endpoint Detection and Response;
Antiviren-Netzwerkfilter;
Data Loss Prevention;
VPN-Client;
Webfilter;
Network-Extension- oder WFP-Callout-Treiber;
Zero-Trust-Agent;
Hypervisorfilter;
Cloud-Sicherheitsagent.

Hinweise:

Fehler beginnt nach Installation oder Update eines Sicherheitsprodukts;
WFP-Ereignis verweist auf einen fremden Filter;
Windows-Firewallprotokoll zeigt keinen Drop;
Paket erreicht die Schnittstelle, aber nicht die Anwendung;
nur ein bestimmter Prozess ist betroffen;
eine andere Anwendung auf demselben Portpfad funktioniert.

Sicherheitssoftware darf nicht ohne Freigabe beendet oder deinstalliert werden.

Windows: Hyper-V, WSL und Container

Verkehr zu einer VM, WSL-Instanz oder einem Container kann zusätzliche Filterebenen durchlaufen.

Zu unterscheiden sind:

Windows-Host-Firewall;
Hyper-V-Firewall;
virtueller Switch;
Host Network Service;
Container-NAT;
Gastbetriebssystem-Firewall;
Kubernetes- oder CNI-Regeln.

Verfügbare Hyper-V-Firewall-Cmdlets prüfen:

Get-Command `
  -Name "*NetFirewallHyperV*" `
  -ErrorAction SilentlyContinue

Wenn entsprechende Cmdlets vorhanden sind, müssen Hyper-V-Profile und Regeln zusätzlich geprüft werden.

Eine Allow-Regel im normalen Hostprofil beweist nicht automatisch, dass Verkehr zu einer VM oder WSL-Instanz erlaubt wird.

Linux: verwendetes Firewall-Backend bestimmen

Auf Linux-Systemen können mehrere Werkzeuge vorhanden sein:

nftables;
iptables-legacy;
iptables-nft;
firewalld;
UFW;
Container- oder Kuberneteskomponenten;
eBPF-, XDP- oder tc-Filter.

Zuerst muss bestimmt werden, welches System die aktive Richtlinie verwaltet.

Versionen prüfen:

LESEND

nft --version

iptables --version

Eine iptables-Ausgabe kann auf ein Backend hinweisen:

iptables vX.Y.Z (nf_tables)

oder:

iptables vX.Y.Z (legacy)

Aktive Manager:

systemctl is-active firewalld

systemctl is-active ufw

Die Installation oder Aktivität eines Managers beweist nicht, dass keine weiteren Regeln existieren.

Linux: nftables-Regelsatz prüfen

LESEND · SENSITIV

sudo nft list ruleset

Mit Regel-Handles:

sudo nft -a list ruleset

Zu prüfen sind:

Tabellenfamilie;
Tabellenname;
Basischains;
Hook;
Priorität;
Chain Policy;
Sprünge in weitere Chains;
Regeln;
Sets;
Maps;
Protokoll;
Adressen;
Ports;
Schnittstellen;
Verbindungszustände;
Counter;
Log-Aktionen;
accept, drop oder reject.

Wichtige Tabellenfamilien:

Familie	Bedeutung
`inet`	gemeinsame Verarbeitung von IPv4 und IPv6
`ip`	IPv4
`ip6`	IPv6
`bridge`	Bridgeverkehr
`arp`	ARP
`netdev`	früher Paketpfad an Netzgeräten

Eine Regel in inet kann sowohl IPv4 als auch IPv6 betreffen. Separate ip- und ip6-Regeln müssen getrennt geprüft werden.

Linux: nftables-Hooks prüfen

Typische Hooks:

Hook	Datenpfad
`input`	Verkehr zum lokalen Host
`output`	lokal erzeugter Verkehr
`forward`	weitergeleiteter Verkehr
`prerouting`	vor der Routingentscheidung
`postrouting`	nach der Routingentscheidung
`ingress`	früher Eingangspfad

Der Name einer Chain muss nicht ihrem Hook entsprechen. Entscheidend ist die tatsächliche Chain-Definition.

Beispiel:

chain host_in {
    type filter hook input priority filter;
    policy drop;
}

Eine frei benannte Chain ohne Hook wirkt nur, wenn eine andere Regel in sie springt.

Linux: nftables-Counter auswerten

Regeln können Zähler für Pakete und Bytes enthalten.

Beispielausgabe:

counter packets 42 bytes 3360 drop

Für einen kontrollierten Test:

aktuellen Zählerstand dokumentieren;
genau einen Test ausführen;
Regelsatz erneut lesen;
Zählerdifferenz prüfen;
Quelladresse, Zielport und Protokoll abgleichen.

Ein unveränderter Zähler beweist nicht automatisch, dass die Regel nicht betroffen ist:

die Regel besitzt eventuell keinen Counter;
eine frühere Regel beendet die Verarbeitung;
der Datenfluss verwendet eine andere Chain;
die Aufzeichnung erfolgt in einem anderen Namespace;
ein XDP- oder tc-Filter verwirft früher.

Zähler dürfen nicht vorsorglich zurückgesetzt werden, weil dadurch Beweisdaten verloren gehen.

Linux: iptables-Regeln prüfen

LESEND · SENSITIV

IPv4:

sudo iptables \
  -L \
  -n \
  -v \
  --line-numbers

IPv6:

sudo ip6tables \
  -L \
  -n \
  -v \
  --line-numbers

Vollständiger IPv4-Regelsatz mit Countern:

sudo iptables-save \
  -c

Vollständiger IPv6-Regelsatz:

sudo ip6tables-save \
  -c

Wichtige Optionen:

Option	Bedeutung
`-L`	Chains und Regeln anzeigen
`-n`	numerische Adressen und Ports
`-v`	ausführliche Anzeige und Counter
`--line-numbers`	Regelpositionen anzeigen
`-c` bei `iptables-save`	Counter mit ausgeben

iptables -L allein bildet nicht immer alle Tabellen und benutzerdefinierten Zusammenhänge ausreichend ab. iptables-save liefert eine vollständigere Regelsatzdarstellung.

Linux: INPUT, OUTPUT und FORWARD unterscheiden

Typische Bedeutung:

INPUT:
Paket ist an den Linux-Host selbst adressiert.

OUTPUT:
Paket wurde auf dem Linux-Host erzeugt.

FORWARD:
Paket wird durch den Linux-Host weitergeleitet.

Containerverkehr kann beispielsweise durchlaufen:

PREROUTING
→ FORWARD
→ POSTROUTING

Eine Allow-Regel in INPUT hilft in diesem Fall nicht zwingend.

Linux: firewalld-Zustand prüfen

LESEND

Dienstzustand:

firewall-cmd --state

Aktive Zonen und Zuordnungen:

firewall-cmd --get-active-zones

Standardzone:

firewall-cmd --get-default-zone

Alle Zonen:

firewall-cmd --list-all-zones

Bestimmte aktive Zone:

firewall-cmd \
  --zone=<Zone> \
  --list-all

Rich Rules:

firewall-cmd \
  --zone=<Zone> \
  --list-rich-rules

Richtlinienobjekte:

firewall-cmd --get-policies

firewall-cmd --list-all-policies

Zu prüfen sind:

welche Schnittstelle gehört zu welcher Zone?
existiert eine Quelladresszuordnung?
welche Services sind erlaubt?
welche Ports sind erlaubt?
welche Protokolle sind erlaubt?
existieren Rich Rules?
existieren ICMP-Blocks?
existieren aktive Policy Objects?
welches Zielverhalten besitzt die Zone?

Die Standardzone ist nicht automatisch die tatsächlich für jede Schnittstelle wirksame Zone.

Linux: firewalld-Laufzeit und permanente Konfiguration

firewalld unterscheidet:

Konfiguration	Wirkung
Runtime	aktuell aktiv, geht ohne Übernahme bei Reload oder Neustart verloren
Permanent	gespeichert, wird bei Reload oder Start zur Runtime-Konfiguration

Runtime-Konfiguration einer Zone:

firewall-cmd \
  --zone=<Zone> \
  --list-all

Permanente Konfiguration:

firewall-cmd \
  --permanent \
  --zone=<Zone> \
  --list-all

Beide Ausgaben müssen verglichen werden.

Mögliche Fehler:

Regel ist permanent gespeichert, aber noch nicht geladen;
Regel existiert nur zur Laufzeit und verschwindet nach Neustart;
Reload hat eine Diagnosefreigabe entfernt;
falsche Zone wurde geändert;
Schnittstelle wechselte die Zone;
Quelladressbindung besitzt eine andere Wirkung als erwartet.

Ein firewall-cmd --reload ist eine Änderung und darf nicht als erster Diagnoseschritt verwendet werden.

Linux: bestimmten firewalld-Port prüfen

Runtime:

firewall-cmd \
  --zone=<Zone> \
  --query-port=443/tcp

Service:

firewall-cmd \
  --zone=<Zone> \
  --query-service=https

Permanent:

firewall-cmd \
  --permanent \
  --zone=<Zone> \
  --query-port=443/tcp

Ein positives Ergebnis beweist nur, dass Port oder Service in dieser Zone konfiguriert ist. Es beweist nicht:

dass die Schnittstelle zu dieser Zone gehört;
dass keine Rich Rule blockiert;
dass der Dienst lauscht;
dass eine vorgelagerte Firewall erlaubt;
dass der Client aus dem passenden Quellbereich kommt.

Linux: UFW prüfen

LESEND

Status und Standardrichtlinien:

sudo ufw status verbose

Nummerierte Regeln:

sudo ufw status numbered

Von UFW verwaltete hinzugefügte Regeln:

sudo ufw show added

Vollständigere Netfilter-Sicht:

sudo ufw show raw

Zu prüfen sind:

aktiv oder inaktiv;
eingehende Standardaktion;
ausgehende Standardaktion;
IPv4- und IPv6-Regeln;
Quelladressen;
Ports;
Protokolle;
Schnittstellen;
Reihenfolge;
gerouteter Verkehr.

ufw status zeigt nicht zwingend alle Regeln, die außerhalb von UFW erzeugt wurden. Ein Status inactive beweist deshalb nicht, dass im Kernel keine anderen Netfilterregeln aktiv sind.

Linux: vorhandene Firewallprotokolle prüfen

Kernelmeldungen im betroffenen Zeitraum:

LESEND · SENSITIV

journalctl \
  -k \
  --since "15 minutes ago"

firewalld-Dienstmeldungen:

journalctl \
  -u firewalld \
  --since "15 minutes ago"

UFW-Dienstmeldungen:

journalctl \
  -u ufw \
  --since "15 minutes ago"

Zu beachten:

Dienstmeldungen sind nicht automatisch Paketlogs;
eine Regel muss eine Log-Aktion besitzen, damit sie Paketdetails erzeugt;
Logziele können Journal, Kernelringpuffer, Syslog oder NFLOG sein;
Logpräfixe müssen zum Datenfluss passen;
umfangreiche Paketprotokollierung kann Systeme und Datenträger belasten.

Neue Logregeln dürfen nur gezielt, rate-limitiert und zeitlich begrenzt erstellt werden.

Linux: eBPF-, XDP- und tc-Filter berücksichtigen

Pakete können vor oder außerhalb der erwarteten nftables- oder iptables-Regel verworfen werden.

Schnittstellendetails:

ip \
  -details \
  link show \
  dev <Schnittstelle>

tc-Ingressfilter:

sudo tc \
  filter show \
  dev <Schnittstelle> \
  ingress

tc-Egressfilter:

sudo tc \
  filter show \
  dev <Schnittstelle> \
  egress

Falls bpftool vorhanden ist:

sudo bpftool net

Mögliche Verursacher:

CNI-Plugin;
Kubernetes NetworkPolicy;
Sicherheitsagent;
DDoS-Schutz;
Service Mesh;
XDP-Programm;
Traffic Control;
Cloud- oder Hostingagent.

Diese Filter dürfen nicht ohne Kenntnis ihres Besitzers entfernt werden.

macOS: zwei Firewallbereiche unterscheiden

Unter macOS müssen mindestens zwei unterschiedliche Mechanismen getrennt betrachtet werden:

Mechanismus	Aufgabe
Application Layer Firewall	steuert eingehende Verbindungen anhand von Apps und Diensten
Packet Filter `pf`	paket- und regelbasierte Filterung auf Netzwerkebene

Zusätzlich können vorhanden sein:

Network Extensions;
Endpoint-Security-Produkte;
VPN-Filter;
Content Filter;
DNS-Proxy;
Drittanbieter-Firewall;
MDM-Konfigurationsprofile.

Die macOS Application Firewall wird nicht primär als frei konfigurierbare Portfirewall verwaltet. Apple beschreibt sie als anwendungsbezogene Firewall.

macOS: Application Firewall in der Oberfläche prüfen

Aktueller Pfad:

Apple-Menü
→ Systemeinstellungen
→ Netzwerk
→ Firewall

Zu prüfen sind:

Firewall aktiviert oder deaktiviert;
„Alle eingehenden Verbindungen blockieren“;
Liste zugelassener und blockierter Apps;
automatisch zugelassene integrierte Software;
automatisch zugelassene signierte Software;
Tarnmodus;
MDM-Verwaltung.

Die genaue Darstellung kann je nach macOS-Version und Geräteverwaltung abweichen.

macOS: Application Firewall im Terminal prüfen

LESEND

Gesamtstatus:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getglobalstate

Block-All-Zustand:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getblockall

Tarnmodus:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --getstealthmode

Anwendungsliste:

sudo /usr/libexec/ApplicationFirewall/socketfilterfw \
  --listapps

Lokale Hilfe und verfügbare Optionen:

/usr/libexec/ApplicationFirewall/socketfilterfw \
  --help

Zusammenfassung über System Profiler:

system_profiler SPFirewallDataType

Zu prüfen sind:

richtiger Anwendungspfad;
signierte oder integrierte Anwendung;
Allow- oder Blockstatus;
globales Blockieren;
MDM-Vorgabe;
geänderte App nach Update;
Launcher und tatsächlicher Listenerprozess.

macOS: pf-Zustand prüfen

LESEND · SENSITIV

Status:

sudo pfctl -s info

Filterregeln:

sudo pfctl -sr

NAT-Regeln:

sudo pfctl -sn

Zustandstabelle:

sudo pfctl -ss

Gesamtübersicht:

sudo pfctl -sa

Zu prüfen sind:

ist pf aktiviert?
welche Regeln und Anchors sind geladen?
existieren Block- oder Pass-Regeln?
welche Schnittstellen werden verwendet?
existieren NAT- oder Redirect-Regeln?
passt ein State zum betroffenen Datenfluss?
verwaltet ein Systemdienst oder Sicherheitsprodukt den Anchor?

Apple weist darauf hin, dass Packet Filter keine unterstützte API für die Integration eigener Softwareprodukte ist. Systembestandteile können die Regeln verwalten und verändern. Die Diagnose vorhandener Zustände ist deshalb von einer dauerhaften eigenen Produktintegration zu unterscheiden.

macOS: Network Extensions und Sicherheitsfilter

Installierte System Extensions:

LESEND

systemextensionsctl list

Mögliche Filterkomponenten:

Content Filter;
Packet Tunnel;
App Proxy;
DNS Proxy;
Endpoint Security;
Hersteller-VPN;
Zero-Trust-Agent.

Eine deaktivierte Application Firewall beweist nicht, dass keine Network Extension den Verkehr filtert.

Sicherheits- oder VPN-Erweiterungen dürfen nicht ohne Freigabe entfernt oder deaktiviert werden.

Docker und Host-Firewall

Docker kann auf dem Host eigene iptables- oder nftables-Regeln erzeugen, um:

Bridge-Netzwerke zu isolieren;
veröffentlichte Ports weiterzuleiten;
NAT und Masquerading umzusetzen;
DNS-Verkehr in Netzwerk-Namespaces zu behandeln.

Zu prüfen sind:

docker info

docker network ls

docker ps \
  --format 'table {{.Names}}\t{{.Ports}}'

docker inspect \
  <Containername> \
  --format '{{json .NetworkSettings.Ports}}'

Wichtige Punkte:

veröffentlichter Containerverkehr kann den Forward-Pfad verwenden;
Docker kann eigene Chains oder nftables-Tabellen erzeugen;
Docker-Regeln dürfen nicht vorsorglich gelöscht werden;
das Abschalten der Docker-Firewallverwaltung kann Containerkommunikation beschädigen;
UFW-, firewalld-, iptables- und Docker-Sichten müssen zusammen betrachtet werden;
Backend und Docker-Version müssen berücksichtigt werden.

Ein freigegebener Hostport beweist nicht, dass die Anwendung im Container lauscht.

Kubernetes und lokale Host-Firewall

Auf einem Kubernetes-Knoten können zusätzlich wirken:

kube-proxy;
CNI-Plugin;
NetworkPolicy;
eBPF-Regeln;
NodePort;
Service;
Ingress;
Host-Firewall des Knotens;
Cloud-Sicherheitsgruppe.

NetworkPolicy ist nicht dasselbe wie die allgemeine Host-Firewall.

Zu prüfen sind:

kubectl get networkpolicy \
  --all-namespaces

kubectl get service \
  --all-namespaces

kubectl get pods \
  --all-namespaces \
  -o wide

kubectl get endpointslice \
  --all-namespaces

Bei hostnahen Problemen müssen zusätzlich CNI- und Knotenkonfiguration berücksichtigt werden.

TCP-Fehlerbilder einer lokalen Firewall

Paketbefund	Mögliche Einordnung
SYN erreicht Host nicht	vorgelagerter Pfad oder falsche Zieladresse
SYN erreicht Host, Firewall loggt Drop	lokale Host-Firewall bestätigt
SYN erreicht Host, kein Listener	Betriebssystem kann RST senden
SYN erreicht Host, Listener vorhanden, keine Antwort	lokale Filterung, Prozess oder Überlastung
Host sendet SYN/ACK, Client erhält es nicht	ausgehender Filter oder Rückweg
Verbindung wird sofort zurückgesetzt	Reject, fehlender Listener oder Anwendung
lokaler Test funktioniert, externer nicht	Bindung, Profil, Host-Firewall oder Netzwerkpfad
nur ein Quellnetz fehlerhaft	RemoteAddress- oder Zonenregel
nur IPv6 fehlerhaft	fehlende IPv6-Regel oder ICMPv6-Problem
nur nach VPN-Verbindung fehlerhaft	Profil-, Schnittstellen- oder VPN-Filter

UDP-Fehlerbilder einer lokalen Firewall

Paketbefund	Mögliche Einordnung
UDP-Anfrage erreicht Host nicht	vorgelagerter Pfad
Anfrage erreicht Host, Drop wird geloggt	lokale Host-Firewall
Anfrage erreicht Host und Prozess nicht	Hostfilter, Namespace oder Puffer
Anwendung antwortet, Antwort verlässt Host nicht	ausgehende Hostfilterung
keine Antwort und kein ICMP	geöffnet/still oder Drop
ICMP Port Unreachable	kein passender UDP-Endpunkt oder aktive Ablehnung
nur große Datagramme scheitern	Fragment-, MTU- oder ICMP-Filterung
Broadcast oder Multicast scheitert	Schnittstellen-, Zonen- oder Gruppenregel

Ein allgemeiner TCP-Porttest ist kein Nachweis für UDP.

ICMP und ICMPv6 prüfen

Firewallregeln müssen ICMPv4 und ICMPv6 getrennt betrachten.

Zu prüfen sind:

Echo Request und Echo Reply;
Destination Unreachable;
Port Unreachable;
Time Exceeded;
Fragmentation Needed;
Packet Too Big;
Parameter Problem;
notwendige IPv6-Kontrollmeldungen.

Das Blockieren von Ping beweist nicht, dass TCP oder UDP blockiert wird.

Umgekehrt kann Ping funktionieren, während ein TCP- oder UDP-Port blockiert ist.

Das vollständige Blockieren von ICMP oder ICMPv6 kann Path MTU Discovery und Diagnose beeinträchtigen.

Paketaufzeichnung und Firewallprotokoll kombinieren

Eine Paketaufzeichnung allein zeigt nicht immer, ob ein Paket alle lokalen Filterstufen passiert hat. Der Aufzeichnungspunkt kann vor oder nach bestimmten Filtern liegen.

Belastbarer Nachweis:

Testzeitpunkt genau dokumentieren.
Paketaufzeichnung auf dem Host starten.
Firewallcounter oder Protokoll erfassen.
Genau einen Test ausführen.
Listener und Prozesszustand erfassen.
Firewallprotokoll mit dem Flow abgleichen.
Paketaufzeichnung und Regelcounter vergleichen.
Test vom repräsentativen Client wiederholen.

Windows-Paketaufzeichnung mit pktmon

pktmon kann Paketerfassung und Drop-Erkennung innerhalb des Windows-Netzwerkstacks unterstützen.

Filter zurücksetzen:

SENSITIV · ÄNDERND

pktmon stop

pktmon filter remove

Filter für TCP-Port 443:

pktmon filter add TCP443 -t TCP -p 443

Aufzeichnung starten:

pktmon start --capture --pkt-size 0 --file-name C:\Temp\firewall443.etl

Nach reproduziertem Fehler stoppen:

pktmon stop

Konvertieren:

pktmon etl2pcap C:\Temp\firewall443.etl --out C:\Temp\firewall443.pcapng

Filter entfernen:

pktmon filter remove

Das Zielverzeichnis muss vorhanden sein. Aufzeichnung und Filter müssen anschließend zurückgenommen werden.

Linux-Paketaufzeichnung

LESEND · SENSITIV

TCP-Port 443:

sudo tcpdump \
  -ni any \
  'tcp port 443' \
  -c 200

UDP-Port 53 und ICMP:

sudo tcpdump \
  -ni any \
  '(udp port 53) or icmp or icmp6' \
  -c 200

Bestimmte Schnittstelle und Gegenstelle:

sudo tcpdump \
  -ni <Schnittstelle> \
  'host 192.0.2.100 and tcp port 443' \
  -c 200

Eine sichtbare eingehende Anfrage beweist, dass sie den Capturepunkt erreicht hat. Ob sie die Anwendung erreicht, muss zusätzlich mit Firewallcounter, Socket- und Anwendungsbefund geprüft werden.

macOS-Paketaufzeichnung

Verfügbare Schnittstellen:

tcpdump -D

Bestimmte Schnittstelle:

sudo tcpdump \
  -ni en0 \
  'host 192.0.2.100 and tcp port 443' \
  -c 200

Loopback:

sudo tcpdump \
  -ni lo0 \
  'tcp port 8080' \
  -c 200

Application Firewall, pf, Network Extension und Anwendung müssen getrennt ausgewertet werden.

Lokalen und entfernten Test vergleichen

Windows:

NETZAKTIV

Test-NetConnection `
  -ComputerName "127.0.0.1" `
  -Port 443

Test-NetConnection `
  -ComputerName "192.0.2.25" `
  -Port 443

Von einem entfernten Client:

Test-NetConnection `
  -ComputerName "app.example.test" `
  -Port 443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 127.0.0.1 443

nc -vz 192.0.2.25 443

Von einem entfernten Client:

nc -vz app.example.test 443

Auswertung:

lokaler Test	entfernter Test	Mögliche Einordnung
erfolgreich	erfolgreich	getesteter TCP-Pfad funktioniert
erfolgreich	fehlerhaft	Bindung, Host-Firewall oder Netzwerkpfad
fehlerhaft	fehlerhaft	Listener, Dienst, Port oder lokale Filterung
Loopback erfolgreich, LAN-IP fehlerhaft	Bindung oder schnittstellenbezogene Regel
IPv4 erfolgreich, IPv6 fehlerhaft	IPv6-Bindung oder IPv6-Firewall
ohne VPN erfolgreich, mit VPN fehlerhaft	Profil-, Schnittstellen- oder VPN-Regel

Host-Firewall von Netzwerkfirewall abgrenzen

Nachweis	Einordnung
Paket erreicht Serverschnittstelle nicht	Problem vor dem Server
Paket erreicht Host und Host-Firewall loggt Drop	lokale Host-Firewall bestätigt
Paket erreicht Host, kein Drop, kein Listener	Dienst- oder Bindungsproblem
Paket erreicht Host, Listener vorhanden, Anwendung loggt nichts	lokaler Filter, Endpoint Security oder Anwendung
Antwort verlässt Serverschnittstelle	lokaler ausgehender Pfad wahrscheinlich passiert
Antwort verlässt Host nicht und Outbound-Drop wird geloggt	lokale ausgehende Firewall
Client- und Serveraufzeichnung unterscheiden sich	Verlust oder Filterung im Zwischenpfad
anderer Server im selben Netz funktioniert	hostspezifische Konfiguration wahrscheinlich

Eine Paketaufzeichnung an nur einem Punkt reicht häufig nicht zur eindeutigen Abgrenzung.

Hypothese und Gegenbeweis

Beispiel:

Hypothese:
Die aktive Windows-Firewall blockiert eingehende TCP-Verbindungen auf
Port 443, weil die Allow-Regel nur für das Domainprofil gilt, die
aktive Schnittstelle aber dem Public-Profil zugeordnet ist.

Erwarteter Befund:
Get-NetConnectionProfile zeigt Public.
Die Regel gilt nur für Domain.
Der lokale Listener auf Port 443 ist vorhanden.
Der lokale Test funktioniert.
Der entfernte Test schlägt fehl.
Das Firewallprotokoll zeigt einen Drop für den Testflow.

Gegenbeweis:
Die Schnittstelle verwendet Domain und eine wirksame Allow-Regel
passt vollständig zu Protokoll, Port, Quelladresse und Programm.

Testmethode:
Profil-, Regel-, Listener-, Protokoll- und Paketprüfung.

Risiko:
Die lesenden Prüfungen verändern den Firewallzustand nicht.

Linux-Beispiel:

Hypothese:
Die Netzwerkschnittstelle befindet sich in der firewalld-Zone public,
aber die Freigabe wurde in der Zone internal angelegt.

Erwarteter Befund:
firewall-cmd --get-active-zones ordnet die Schnittstelle public zu.
Port 443 ist in public nicht erlaubt, in internal jedoch vorhanden.
Der Listener existiert und ein externer Test schlägt fehl.

Gegenbeweis:
Die Schnittstelle ist internal zugeordnet oder eine andere wirksame
Regel erlaubt den konkreten Flow.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko
vorhandene passende Regel aktivieren	Regel ist geprüft und nur deaktiviert	Dienst wird erreichbar
Profilzuordnung korrigieren	falsche Netzwerkkategorie nachgewiesen	Vertrauensniveau des Netzwerks ändert sich
gezielte Allow-Regel erstellen	konkreter legitimer Flow bestätigt	zusätzliche Angriffsfläche
zu breite Regel einschränken	unnötiger Geltungsbereich bestätigt	legitime Clients können ausfallen
falsche Blockregel korrigieren	Blockregel als Ursache nachgewiesen	Schutzwirkung kann reduziert werden
Programmpfad aktualisieren	Anwendungspfad hat sich nachweislich geändert	falsches Programm könnte freigegeben werden
RemoteAddress-Bereich korrigieren	Quellnetz stimmt nachweislich nicht	weitere Quellen können Zugriff erhalten
TCP-/UDP-Protokoll korrigieren	Protokollverwechslung bestätigt	zusätzlicher Transportweg wird geöffnet
IPv6-Regel ergänzen	Dienst soll IPv6 nutzen und Block ist bestätigt	zusätzliche IPv6-Erreichbarkeit
firewalld-Runtime und Permanent angleichen	Abweichung bestätigt	Wirkung über Neustart hinaus
Container-Weiterleitungsregel korrigieren	Forward-Pfad bestätigt	mehrere Container können betroffen sein
Endpoint-Security-Ausnahme beantragen	Produktfilter als Ursache bestätigt	zentrale Sicherheitswirkung
Logging zeitlich begrenzt aktivieren	vorhandene Daten reichen nicht	Speicher- und Datenschutzrisiko

Vor jeder Änderung müssen dokumentiert werden:

genaue Regel;
Richtlinienquelle;
betroffener Flow;
Sicherheitsauswirkung;
verantwortlicher Besitzer;
Freigabe;
Ausgangszustand;
Rückweg;
Erfolgskriterium;
vorgesehenes Testverfahren.

Systematischer Diagnoseablauf

Exakte Fehlermeldung aufnehmen.
Zeitpunkt und Zeitzone dokumentieren.
Client, Server und Anwendung bestimmen.
TCP, UDP, ICMPv4 oder ICMPv6 bestimmen.
Quell- und Zieladressen dokumentieren.
Quell- und Zielports dokumentieren.
Listener und Bindungsadresse prüfen.
Besitzenden Prozess bestimmen.
lokalen Loopbacktest durchführen.
konkrete lokale Schnittstellenadresse testen.
Test von einem repräsentativen entfernten Client durchführen.
Paketfluss eingehend, ausgehend oder weitergeleitet bestimmen.
aktive Firewalltechnik bestimmen.
aktives Profil, aktive Zone oder Schnittstelle bestimmen.
Standardaktionen prüfen.
wirksame Regeln erfassen.
Allow- und Blockregeln prüfen.
Protokoll- und Portfilter vergleichen.
Adressbereiche vergleichen.
Programm- und Dienstfilter vergleichen.
Schnittstellenfilter vergleichen.
Richtlinienquelle bestimmen.
zentrale Richtlinien und lokale Zusammenführung prüfen.
Firewallcounter und vorhandene Protokolle auswerten.
bei Bedarf zeitlich begrenzte Protokollierung aktivieren.
Paketaufzeichnung am Host durchführen.
Paketaufzeichnung mit einem zweiten Punkt vergleichen.
Container-, VM- und Namespacepfade berücksichtigen.
Endpoint Security, VPN und zusätzliche Filter berücksichtigen.
Hypothese und Gegenbeweis formulieren.
Genau eine kontrollierte Änderung durchführen.
identischen Test wiederholen.
Anwendung statt nur Porttest verifizieren.
weitere repräsentative Clients prüfen.
temporäre Protokollierung und Filter zurücknehmen.
Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
kein Listener	kein Firewallproblem nachgewiesen	Dienst und Bindung prüfen
lokaler Test funktioniert, remote nicht	Firewall, Bindung oder Netzwerkpfad	Serveraufzeichnung
Paket erreicht Server nicht	vorgelagerter Pfad	Netzwerkfirewall und Routing
Paket erreicht Server, Drop wird geloggt	lokale Host-Firewall	passende Regel bestimmen
Paket erreicht Server, kein Drop, kein App-Log	Endpoint Filter oder Anwendung	Prozess- und WFP/eBPF-Befund
Allow-Regel vorhanden, falsches Profil	Regel nicht wirksam	aktive Profilzuordnung
Allow-Regel vorhanden, falsche Zone	Regel nicht wirksam	firewalld-Zuordnung
Allow-Regel vorhanden, falsches Protokoll	TCP-/UDP-Verwechslung	Portfilter
Allow-Regel vorhanden, falsche Quelladresse	Scope passt nicht	Adressfilter
Allow-Regel vorhanden, alter Programmpfad	App-Filter passt nicht	Prozesspfad
Blockregel und Allow-Regel treffen zu	Blockregel kann Vorrang besitzen	vollständige Regelbedingungen
lokale Regel verschwindet	zentrale Verwaltung	PolicyStoreSource oder MDM
UFW inaktiv, Verkehr blockiert	andere Netfilterregeln	`nft list ruleset`
firewalld-Port permanent, nicht runtime	noch nicht wirksam	Runtime vergleichen
firewalld-Port runtime, nicht permanent	verschwindet bei Reload	Permanent vergleichen
nft-Counter steigt an Drop-Regel	Regel trifft den Flow	Zeit und 5-Tupel prüfen
iptables-Counter bleibt unverändert	anderer Pfad oder Backend	nftables und Namespace prüfen
Application Firewall erlaubt App, trotzdem blockiert	`pf`, Network Extension oder VPN	weitere Filter prüfen
Docker-Port veröffentlicht, Hostzugriff scheitert	Forward-/Docker-Regel oder Container	Docker-Regeln und Listener
Hostdienst funktioniert, Container nicht	Namespace oder Forward-Pfad	Container-Socket und NAT
nur IPv6 blockiert	fehlende IPv6-Regel	`ip6`, `inet` oder ICMPv6
nur VPN betroffen	Schnittstellen-, Profil- oder VPN-Filter	Zustand mit und ohne VPN
Antwort verlässt Host, Client sieht sie nicht	Problem nach dem Host	Rückweg und Netzwerkfirewall

Typische Diagnosefehler

Firewall prüfen, bevor der Listener geprüft wurde.
Dienststatus mit Listener gleichsetzen.
lokalen Loopbacktest als externen Nachweis verwenden.
nur die GUI prüfen.
persistente Konfiguration statt aktiver Richtlinie prüfen.
Windows PersistentStore mit ActiveStore verwechseln.
nur nach einer Allow-Regel suchen.
Blockregeln nicht berücksichtigen.
Windows-Regeln wie eine einfache ACL-Liste interpretieren.
aktives Windows-Profil nicht prüfen.
VPN- und virtuelle Schnittstellen ignorieren.
Programmpfad und Dienstfilter nicht prüfen.
Quelladressbereich nicht prüfen.
TCP und UDP verwechseln.
IPv4- und IPv6-Regeln nicht getrennt prüfen.
Ping als vollständigen Firewalltest verwenden.
ICMPv6 vollständig blockieren.
firewalld-Standardzone mit aktiver Zone gleichsetzen.
firewalld-Runtime und Permanent nicht vergleichen.
UFW-Status als vollständigen Netfilterzustand bewerten.
iptables und nftables unkontrolliert parallel verändern.
Chain-Hooks und Policies nicht prüfen.
Regelcounter ohne Vorher-Nachher-Vergleich bewerten.
Containerverkehr im INPUT- statt FORWARD-Pfad suchen.
Docker-Regeln vorsorglich löschen.
Kubernetes NetworkPolicy mit Host-Firewall gleichsetzen.
macOS Application Firewall mit pf gleichsetzen.
Network Extensions und Endpoint Security ignorieren.
Paketaufzeichnung allein als Nachweis der Firewallaktion verwenden.
Firewallprotokollierung dauerhaft und unbegrenzt aktivieren.
die Firewall vollständig deaktivieren.
Sicherheitssoftware beenden oder deinstallieren.
mehrere Regeln gleichzeitig ändern.
keine Rückfallmöglichkeit dokumentieren.
nur einen einzelnen erfolgreichen Test durchführen.
temporäre Diagnosefreigaben aktiv lassen.

Verifikation

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

der erwartete Listener ist vorhanden;
richtige Adresse und richtiger Port sind gebunden;
der richtige Prozess besitzt den Socket;
das richtige Firewallprofil ist aktiv;
die richtige Linux-Zone ist aktiv;
richtige Schnittstelle ist zugeordnet;
wirksame Standardaktionen entsprechen dem Sollzustand;
die vorgesehene Regel ist aktiviert;
Regelrichtung stimmt;
TCP, UDP, ICMPv4 oder ICMPv6 stimmt;
lokale und entfernte Ports stimmen;
lokale und entfernte Adressbereiche stimmen;
Programm- und Dienstfilter stimmen;
Profil- beziehungsweise Zonenumfang stimmt;
keine widersprechende Blockregel greift;
Richtlinienquelle ist dokumentiert;
lokaler Test funktioniert;
Test über die konkrete Schnittstellenadresse funktioniert;
entfernter Test funktioniert;
ursprüngliche Anwendung funktioniert;
IPv4 funktioniert, sofern vorgesehen;
IPv6 funktioniert, sofern vorgesehen;
UDP funktioniert, sofern vorgesehen;
notwendige ICMP- und ICMPv6-Meldungen funktionieren;
Container- oder VM-Pfad funktioniert;
Firewallcounter zeigen den erwarteten Pfad;
keine neuen unerwarteten Drops entstehen;
Sicherheitsumfang wurde nicht unnötig erweitert;
temporäre Regeln wurden entfernt;
temporäre Protokollierung wurde zurückgesetzt;
mehrere repräsentative Clients funktionieren;
Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine vollständig deaktivierte Firewall ist keine gültige Verifikation einer sicheren Lösung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum, Uhrzeit und Zeitzone>

Client:
<Hostname und IP-Adresse>

Server:
<Hostname und IP-Adresse>

Anwendung:
<Dienst und Prozess>

Richtung:
<eingehend, ausgehend oder weitergeleitet>

Transportprotokoll:
<TCP, UDP, ICMPv4 oder ICMPv6>

Quelladresse und Port:
<Adresse und Port>

Zieladresse und Port:
<Adresse und Port>

Listener:
<Adresse, Port, Prozess und PID>

Schnittstelle:
<Name und Typ>

Firewalltechnik:
<Windows Firewall, nftables, firewalld, UFW, pf oder andere>

Aktives Profil oder Zone:
<Wert>

Standardaktion:
<eingehend und ausgehend>

Wirksame Regel:
<Name, Aktion und Bedingungen>

Richtlinienquelle:
<lokal, GPO, MDM oder anderes>

Portfilter:
<Befund>

Adressfilter:
<Befund>

Programm- oder Dienstfilter:
<Befund>

Firewallprotokoll:
<Zeitpunkt und Aktion>

Paketaufzeichnung:
<eingehender und ausgehender Befund>

Zusätzliche Filter:
<Endpoint Security, VPN, Container oder Hypervisor>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

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

Sicherheitsauswirkung:
<Beschreibung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendung und weitere Systeme>

Prävention:
<Monitoring oder Konfigurationsverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Befehl
Windows-Netzwerkprofil	`Get-NetConnectionProfile`
Windows-Firewallprofile	`Get-NetFirewallProfile`
wirksame Windows-Regeln	`Get-NetFirewallRule -PolicyStore ActiveStore`
aktivierte Windows-Regeln	`Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True`
Windows-Blockregeln	`Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Action Block`
Windows-Portfilter	`Get-NetFirewallPortFilter -PolicyStore ActiveStore`
Windows-Adressfilter	`Get-NetFirewallAddressFilter -PolicyStore ActiveStore`
Windows-Programmfilter	`Get-NetFirewallApplicationFilter -PolicyStore ActiveStore`
Windows-Dienstfilter	`Get-NetFirewallServiceFilter -PolicyStore ActiveStore`
vollständige Windows-Regeln	`Show-NetFirewallRule -PolicyStore ActiveStore`
Windows-Firewallprotokoll	`Get-Content "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" -Tail 100`
Windows-WFP-Blockereignisse	`Get-WinEvent -FilterHashtable @{LogName="Security"; Id=5152,5155,5157,5159}`
Windows-netsh-Profile	`netsh advfirewall show allprofiles`
Windows-netsh-Regeln	`netsh advfirewall firewall show rule name=all verbose`
nftables-Regelsatz	`sudo nft list ruleset`
nftables mit Handles	`sudo nft -a list ruleset`
iptables-Regeln	`sudo iptables -L -n -v --line-numbers`
IPv6-iptables	`sudo ip6tables -L -n -v --line-numbers`
iptables-Gesamtsicht	`sudo iptables-save -c`
firewalld-Zustand	`firewall-cmd --state`
aktive firewalld-Zonen	`firewall-cmd --get-active-zones`
firewalld-Zone	`firewall-cmd --zone=<Zone> --list-all`
permanente firewalld-Zone	`firewall-cmd --permanent --zone=<Zone> --list-all`
firewalld-Port prüfen	`firewall-cmd --zone=<Zone> --query-port=<Port>/<Protokoll>`
UFW-Status	`sudo ufw status verbose`
nummerierte UFW-Regeln	`sudo ufw status numbered`
vollständige UFW-Sicht	`sudo ufw show raw`
Kernelprotokoll	`journalctl -k --since "15 minutes ago"`
macOS-Firewallstatus	`sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate`
macOS-App-Liste	`sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps`
macOS-Firewallübersicht	`system_profiler SPFirewallDataType`
macOS-pf-Status	`sudo pfctl -s info`
macOS-pf-Regeln	`sudo pfctl -sr`
macOS-pf-States	`sudo pfctl -ss`
macOS-System-Extensions	`systemextensionsctl list`
Windows-TCP-Test	`Test-NetConnection -ComputerName <Ziel> -Port <Port>`
Linux/macOS-TCP-Test	`nc -vz <Ziel> <Port>`
Linux-Aufzeichnung	`sudo tcpdump -ni any 'tcp port <Port>' -c 200`

Befehle und Maßnahmen, die nicht unkontrolliert als erste Diagnose verwendet werden dürfen

Set-NetFirewallProfile -Enabled False
netsh advfirewall set allprofiles state off
Disable-NetFirewallRule ohne exakte Regelbegrenzung
Enable-NetFirewallRule ohne exakte Regelbegrenzung
Remove-NetFirewallRule
New-NetFirewallRule ohne dokumentierten Scope
netsh int ip reset
netsh winsock reset
nft flush ruleset
iptables -F
iptables -X
ip6tables -F
ufw disable
ufw reset
firewall-cmd --reload
firewall-cmd --complete-reload
systemctl stop firewalld
systemctl restart firewalld
pfctl -d
pfctl -F all
Änderung oder Entfernen von Docker-Regeln
Deaktivieren der Docker-Firewallverwaltung
Entfernen von Kubernetes- oder CNI-Regeln
Deaktivieren eines VPN-Filters
Beenden oder Deinstallieren von Endpoint Security
dauerhafte ungefilterte Paketprotokollierung

Ein vollständiges Deaktivieren der Firewall verändert den Sicherheitszustand, kann Richtlinien verletzen und liefert keinen präzisen Nachweis darüber, welche Regel den ursprünglichen Fehler verursacht hat.

Quellen

Offizielle Microsoft-Dokumentation

Offizielle Netfilter- und Linux-Dokumentation

Offizielle firewalld- und Ubuntu-Dokumentation

Offizielle Apple-Dokumentation

Offizielle Containerdokumentation

Für diese Seite wurden keine Community-Berichte oder Social-Media-Aussagen als technische Nachweise verwendet.

9.5 Netzwerkfirewall, ACL-Reihenfolge und Stateful Inspection

Eine Netzwerkfirewall kontrolliert den Datenverkehr zwischen Netzen, Sicherheitszonen, Standorten, Cloud-Umgebungen oder einzelnen Netzsegmenten. Eine vorhandene Freigaberegel beweist jedoch noch nicht, dass der Datenverkehr tatsächlich erlaubt wird. Entscheidend sind unter anderem:

die tatsächlich durchlaufene Firewall;
die Eingangs- und Ausgangsschnittstelle;
Quell- und Zielzone;
Quell- und Zieladresse;
Quell- und Zielport;
Protokoll;
Regelreihenfolge und Priorität;
NAT-Verarbeitung;
Routingentscheidung;
bestehender Sitzungszustand;
zusätzliche Sicherheitsprofile;
Rückweg;
Hochverfügbarkeitszustand;
verwendeter virtueller Firewallkontext;
Zeitpunkt und Konfigurationsversion.

Diese Seite behandelt Netzwerkfirewalls und zentrale Netzwerk-ACLs. Die lokale Firewall eines Endgeräts oder Servers wurde bereits unter 9.4 Lokale Host-Firewall prüfen behandelt.

Ziele

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

ob der betroffene Datenverkehr die vorgesehene Firewall durchläuft;
welche Regel tatsächlich angewendet wird;
ob eine allgemeinere Regel eine spezifische Regel überschattet;
ob ein implizites Verbot greift;
ob die Firewall zustandsbehaftet oder zustandslos arbeitet;
ob eine vorhandene Sitzung den aktuellen Test beeinflusst;
ob der Rückverkehr einer bestehenden Sitzung zugeordnet wird;
ob NAT, Routing oder Zonenwahl die Regelzuordnung verändern;
ob ein Sicherheitsprofil trotz erlaubender Netzwerkregel blockiert;
ob die Störung an der Firewall oder an einem anderen Netzabschnitt liegt;
wie eine Änderung kontrolliert und anschließend verifiziert wird.

Sicherheits- und Änderungsgrundsätze

Eine Netzwerkfirewall ist häufig ein zentraler Sicherheits- und Verfügbarkeitsbestandteil. Unkontrollierte Änderungen können viele Systeme gleichzeitig betreffen.

Vor jeder Änderung sind mindestens festzuhalten:

betroffene Anwendung;
Quelle und Ziel;
benötigtes Protokoll;
benötigte Ports;
Datenflussrichtung;
betroffene Sicherheitszonen;
aktuell passende Regel;
aktuelle Konfigurationsversion;
zuständige Freigabe;
Risiko;
Rückweg;
Erfolgskriterium;
vorgesehenes Testverfahren;
Wartungs- oder Änderungsfenster.

Nicht als erste Diagnosemaßnahme geeignet sind:

Firewall deaktivieren;
eine allgemeine any-zu-any-Freigabe erstellen;
Regelwerk vollständig neu laden;
produktive Regeln ungeprüft verschieben;
Sitzungs- oder Verbindungstabellen vollständig löschen;
NAT-Tabellen vollständig leeren;
Hochverfügbarkeitsumschaltung erzwingen;
Sicherheitsprofile pauschal deaktivieren;
Intrusion Prevention abschalten;
TLS-Inspektion global ausschalten;
Paketfilterung durch eine direkte Umgehungsroute umgehen;
Firewall oder Cluster vorsorglich neu starten;
Zähler vor der Beweissicherung zurücksetzen.

Eine kurzfristige Testregel muss genauso präzise wie eine dauerhafte Regel begrenzt werden. Sie benötigt:

eindeutigen Namen;
dokumentierten Zweck;
exakte Quelle;
exaktes Ziel;
erforderliches Protokoll;
erforderlichen Zielport;
Protokollierung;
verantwortliche Person;
Ablaufzeitpunkt;
dokumentierte Entfernung.

Netzwerkfirewall und Host-Firewall unterscheiden

Merkmal	Netzwerkfirewall	Host-Firewall
Standort	zwischen Netzen oder Sicherheitszonen	direkt auf dem Endgerät oder Server
Sichtbarer Datenverkehr	nur Verkehr, der die Firewall tatsächlich durchläuft	ein- und ausgehender Verkehr des lokalen Systems
Typische Regeln	Zonen, Netze, Adressen, Dienste, Anwendungen	Programme, Dienste, Profile, lokale Ports, Benutzer
Zustandsverwaltung	zentrale Sitzungstabelle	lokale Verbindungstabelle
Protokollierung	zentrale Firewall- und Sicherheitsprotokolle	lokales Betriebssystemprotokoll
Häufige Fehlerquelle	falsche Zone, Regelreihenfolge, NAT, Route, Sitzung	falsches Profil, Dienstregel, Programmpfad
Umgehungsmöglichkeit	lokales Routing oder direkter Pfad zwischen Systemen	normalerweise nicht für lokalen Netzwerkverkehr

Eine Netzwerkfirewall kann nur Datenverkehr prüfen, der tatsächlich über sie geleitet wird. Befinden sich Quelle und Ziel beispielsweise im selben VLAN, kann der Verkehr die zentrale Firewall vollständig umgehen.

Vereinfachter Datenfluss

Ein typischer Datenfluss kann folgende Verarbeitungsschritte enthalten:

Paket trifft auf einer Eingangsschnittstelle ein.
Eingangszone oder Sicherheitskontext wird bestimmt.
Vorhandene Sitzung wird gesucht.
NAT- und Routingregeln werden ausgewertet.
Ausgangsschnittstelle und Ausgangszone werden bestimmt.
Sicherheitsregel wird ermittelt.
Zusätzliche Prüfungen werden ausgeführt.
Paket wird weitergeleitet oder verworfen.
Eine neue Sitzung wird angelegt oder eine vorhandene aktualisiert.
Rückverkehr wird einer Sitzung zugeordnet.
Ereignisse, Zähler und Sitzungsdaten werden protokolliert.

Die genaue Reihenfolge von NAT, Routing, Sicherheitsrichtlinie, Anwendungserkennung und Inhaltsprüfung ist produktspezifisch. Sie muss für das eingesetzte Firewallprodukt und die verwendete Softwareversion geprüft werden.

Einen Datenfluss eindeutig beschreiben

Vor der Regelprüfung muss der betroffene Datenfluss vollständig beschrieben werden.

Beispiel:

Zeitpunkt:
2026-08-02 10:15:32 Europe/Berlin

Quelle:
192.0.2.100

Quellzone:
CLIENTS

Quellport:
53124

Ziel:
198.51.100.25

Zielzone:
SERVER

Zielport:
443

Protokoll:
TCP

Anwendung:
HTTPS-Zugriff auf app.example.test

Erwarteter Pfad:
CLIENTS -> FW-CLUSTER-01 -> SERVER

Erwartete Regel:
ALLOW-CLIENTS-APP-HTTPS

Erwartete NAT-Verarbeitung:
keine

Bei TCP und UDP wird ein Datenfluss typischerweise über das Fünf-Tupel beschrieben:

Quelladresse
Quellport
Zieladresse
Zielport
IP-Protokoll

Für die Firewalldiagnose kommen weitere Merkmale hinzu:

Eingangsschnittstelle;
Ausgangsschnittstelle;
Quellzone;
Zielzone;
Mandant oder virtueller Kontext;
Benutzeridentität;
erkannte Anwendung;
NAT-Adressen und NAT-Ports;
Zeitplan;
Sicherheitsprofil;
VPN- oder Tunnelzuordnung;
Regel-ID;
Sitzungs-ID.

Quellport und Zielport nicht verwechseln

Bei einer üblichen Clientverbindung verwendet der Client einen dynamischen Quellport und der Server einen bekannten Zielport.

Beispiel:

192.0.2.100:53124 -> 198.51.100.25:443/TCP

Dabei gilt:

Feld	Bedeutung
`192.0.2.100`	Clientadresse
`53124`	dynamischer Quellport des Clients
`198.51.100.25`	Serveradresse
`443`	Zielport des HTTPS-Dienstes

Eine Freigabe, die irrtümlich den Quellport 443 statt des Zielports 443 prüft, passt normalerweise nicht auf diesen Verbindungsaufbau.

Der Rückverkehr besitzt vertauschte Adressen und Ports:

198.51.100.25:443 -> 192.0.2.100:53124/TCP

Bei einer zustandsbehafteten Firewall wird dieser Rückverkehr üblicherweise über den bestehenden Sitzungszustand erlaubt. Bei einer zustandslosen ACL muss der Rückverkehr ausdrücklich berücksichtigt werden.

Eingehend und ausgehend richtig einordnen

Inbound, ingress, outbound und egress beziehen sich auf eine bestimmte Schnittstelle, Zone oder Ressource. Die Begriffe dürfen nicht ohne diesen Bezug verwendet werden.

Beispiel:

Clientnetz -> Firewall -> Servernetz

Aus Sicht der Firewall:

auf der Client-Schnittstelle trifft der Verbindungsaufbau eingehend ein;
zur Server-Schnittstelle verlässt er die Firewall ausgehend;
der Rückverkehr trifft auf der Server-Schnittstelle eingehend ein;
zum Clientnetz verlässt er die Firewall ausgehend.

Bei Cloud-ACLs kann sich inbound oder outbound auf ein Subnetz, eine Netzwerkschnittstelle oder eine virtuelle Maschine beziehen. Deshalb müssen Ressource und Richtung immer gemeinsam dokumentiert werden.

Arten der Filterung

Verfahren	Auswertung	Sitzungszustand	Typische Eigenschaft
zustandslose ACL	jedes Paket einzeln	nein	Rückverkehr benötigt eigene passende Regel
Stateful Inspection	Paket und bestehende Sitzung	ja	Rückverkehr bestehender Sitzungen wird zugeordnet
Proxy-Firewall	beendet und vermittelt die Verbindung	ja	Client und Ziel kommunizieren nicht direkt miteinander
Application Firewall	Anwendung oder Protokollinhalt	ja	Entscheidung kann von erkannter Anwendung abhängen
Next-Generation Firewall	Netzwerk-, Sitzungs-, Benutzer- und Anwendungsdaten	ja	zusätzliche URL-, Malware-, IPS- oder TLS-Prüfung
Cloud Security Group	ressourcenbezogene Regeln	häufig ja	Verhalten unterscheidet sich von Subnetz-ACLs
Cloud Network ACL	subnetzbezogene Paketfilterung	häufig nein	Priorität und Rückregeln sind besonders wichtig

Die Produktbezeichnung allein reicht nicht zur Bewertung. Es muss geprüft werden, welche Regelkomponente den betroffenen Datenfluss tatsächlich verarbeitet.

ACL-Reihenfolge

Viele Netzwerkfirewalls und Router prüfen Regeln in einer definierten Reihenfolge. Häufig gilt:

Regeln werden von oben nach unten oder nach Priorität geprüft.
Die erste vollständig passende Regel bestimmt die Aktion.
Nach einem Treffer werden nachfolgende Regeln nicht mehr geprüft.
Trifft keine Regel zu, greift häufig eine implizite Standardaktion.

Dieses Verhalten ist verbreitet, aber nicht für jedes Produkt und jede Regelart identisch. Zu prüfen sind:

globale Regeln;
lokale Regeln;
geerbte Regeln;
Schnittstellen-ACLs;
Zonenregeln;
Vorregeln und Nachregeln;
Parent- und Child-Policies;
Regelgruppen;
Sicherheitsprofile;
herstellerspezifische Ausnahme- und Standardregeln.

Beispiel für eine sinnvolle Reihenfolge

Anforderung:

Host 192.0.2.66 darf den Server nicht erreichen.
Andere Clients aus 192.0.2.0/24 dürfen HTTPS verwenden.
Nicht ausdrücklich erlaubter Verkehr wird protokolliert verworfen.

Vereinfachte Regelreihenfolge:

10 deny   tcp 192.0.2.66/32  -> 198.51.100.25/32 port 443 log
20 permit tcp 192.0.2.0/24   -> 198.51.100.25/32 port 443 log
90 deny   ip  any            -> any                    log

Die spezifische Sperre steht vor der allgemeineren Freigabe.

Fehlerhafte Reihenfolge:

10 permit tcp 192.0.2.0/24   -> 198.51.100.25/32 port 443 log
20 deny   tcp 192.0.2.66/32  -> 198.51.100.25/32 port 443 log
90 deny   ip  any            -> any                    log

Wenn das Produkt nach dem ersten Treffer beendet, wird Host 192.0.2.66 bereits durch Regel 10 erlaubt. Regel 20 ist für diesen Datenfluss nicht erreichbar.

Überschattete, redundante und widersprüchliche Regeln

Regelproblem	Beschreibung	Auswirkung
überschattete Regel	frühere allgemeinere Regel deckt alle Treffer der späteren Regel ab	spätere Regel wird nie verwendet
teilweise überschattete Regel	frühere Regel deckt einen Teil des späteren Bereichs ab	Regel wirkt nur für den verbleibenden Teil
redundante Regel	Regel erlaubt oder verbietet bereits identisch behandelten Verkehr	unnötige Komplexität
widersprüchliche Regel	gleiche oder überlappende Kriterien besitzen andere Aktion	Ergebnis hängt von Reihenfolge ab
veraltete Regel	zugehöriger Dienst oder Eigentümer existiert nicht mehr	unnötige Angriffsfläche
ungebundene ACL	ACL ist definiert, aber keiner Schnittstelle oder Zone zugeordnet	keine Wirkung
falscher Kontext	Regel liegt in anderem Mandanten oder virtuellen System	keine Wirkung auf den betroffenen Verkehr
falsche Richtung	Regel ist für Gegenrichtung angelegt	erwarteter Verbindungsaufbau bleibt blockiert
falsche Adressphase	Regel verwendet falsche NAT-Adresse	kein Treffer
falsche Regelart	Netzwerkregel statt Anwendungsregel oder umgekehrt	unerwartete Verarbeitung

Regelanalysen des Herstellers können bei der Erkennung helfen. Das Ergebnis muss trotzdem mit realen Trefferzählern, Protokollen und einem kontrollierten Verbindungstest bestätigt werden.

Implizite Standardaktion

Viele ACL- und Firewallregelwerke besitzen am Ende eine implizite Verweigerung. Diese Regel ist möglicherweise nicht als normale Konfigurationszeile sichtbar.

Vereinfachtes Modell:

permit <ausdrücklich erlaubter Verkehr>
deny   <ausdrücklich gesperrter Verkehr>
deny   any any <implizit>

Ein explizites abschließendes Verbot mit Protokollierung kann die Diagnose erleichtern:

deny any any log

Ob eine solche Regel sinnvoll und zulässig ist, hängt vom Produkt und der Protokollierungsleistung ab. Eine stark ausgelastete abschließende Protokollregel kann sehr viele Ereignisse erzeugen.

Zu prüfen sind:

existiert eine implizite Verweigerung?
welche Regelart besitzt sie?
gilt sie pro Schnittstelle, Zone, Regelgruppe oder Kontext?
wird ein Treffer protokolliert?
existieren Ausnahmen für System- oder Verwaltungsverkehr?
greifen vorher noch globale oder geerbte Regeln?
existiert eine vom Hersteller bereitgestellte Standardregel?

Ein fehlender sichtbarer deny-Eintrag beweist nicht, dass nicht passender Verkehr erlaubt wird.

Regelkriterien vollständig prüfen

Eine moderne Firewall kann deutlich mehr als nur IP-Adresse und Port auswerten.

Kriterium	Zu prüfender Punkt
Quellzone	stimmt die Zone der tatsächlichen Eingangsschnittstelle?
Zielzone	entspricht sie der durch Routing bestimmten Ausgangszone?
Quelladresse	Originaladresse, NAT-Adresse oder Adressobjekt?
Zieladresse	Originalziel oder übersetztes Ziel?
Quellport	dynamischer Port oder fest definierter Dienstport?
Zielport	tatsächlich verwendeter Dienstport?
Protokoll	TCP, UDP, ICMP, ESP, GRE oder anderes IP-Protokoll?
Anwendung	bereits erkannt, noch unbekannt oder verschlüsselt?
Dienst	fest definierter Port oder anwendungsabhängiger Standardport?
Benutzer	konnte die Firewall die Identität ermitteln?
Gerät	passt die Geräte- oder Endpunktklassifizierung?
Zeitplan	ist die Regel zum Fehlerzeitpunkt aktiv?
URL-Kategorie	wird das Ziel einer anderen Kategorie zugeordnet?
FQDN-Objekt	auf welche Adressen wurde der Name aufgelöst?
Sicherheitsprofil	Malware-, IPS-, Datei- oder URL-Prüfung aktiv?
Mandant	richtiger virtueller Router oder Firewallkontext?
VPN	gilt eine zusätzliche VPN- oder Tunnelregel?

Eine Regel kann auf Netzwerkebene allow ergeben und anschließend trotzdem durch ein Sicherheitsprofil blockiert werden.

Adress- und Dienstobjekte prüfen

Regeln verwenden häufig Objekte statt direkt eingetragener IP-Adressen und Ports.

Zu prüfen sind:

aktueller Objektinhalt;
CIDR-Präfix;
IPv4- oder IPv6-Zuordnung;
einzelne Adresse oder gesamtes Netz;
verschachtelte Objektgruppen;
doppelte Gruppenmitgliedschaften;
dynamische Gruppen;
Cloud-Tags;
FQDN-Auflösung;
Aktualisierungszeitpunkt;
Portbereich;
TCP- oder UDP-Zuordnung;
deaktivierte oder abgelaufene Objekte;
Synchronisation zwischen Clusterknoten.

Beispiel für eine häufige Netzmaskenverwechslung:

192.0.2.0/24

umfasst:

192.0.2.0 bis 192.0.2.255

Dagegen umfasst:

192.0.2.100/32

nur die einzelne Adresse:

192.0.2.100

Bei Produkten mit Wildcard-Masken ist die Schreibweise nicht mit einer normalen Subnetzmaske gleichzusetzen.

FQDN- und dynamische Objekte

Ein FQDN-Objekt kann von der Firewall regelmäßig in eine oder mehrere IP-Adressen aufgelöst werden.

Zu prüfen sind:

welcher DNS-Server von der Firewall verwendet wird;
ob die DNS-Auflösung erfolgreich ist;
welche A- und AAAA-Adressen gespeichert sind;
TTL und Aktualisierungszeitpunkt;
unterschiedliche Antworten durch Geo-DNS oder CDN;
Erreichbarkeit über IPv4 und IPv6;
maximale Anzahl unterstützter Adressen;
Verhalten bei fehlgeschlagener Aktualisierung;
Synchronisation im Cluster.

Ein Client und eine Firewall können denselben FQDN zu unterschiedlichen Zieladressen auflösen. Dann kann eine scheinbar passende FQDN-Regel den tatsächlichen Clientverkehr verfehlen.

Stateful Inspection

Eine zustandsbehaftete Firewall bewertet nicht jedes Paket vollständig unabhängig. Sie führt eine Sitzungstabelle und ordnet weitere Pakete einem bekannten Datenfluss zu.

Vereinfachter TCP-Ablauf:

Client sendet SYN.
Firewall findet keine vorhandene Sitzung.
Firewall prüft Route, Zone, NAT und Richtlinie.
Bei Erlaubnis wird ein Sitzungseintrag angelegt.
Server sendet SYN, ACK.
Firewall ordnet das Paket der bestehenden Sitzung zu.
Client sendet ACK.
Sitzung wechselt in den etablierten Zustand.
Weitere Pakete werden anhand der Sitzung verarbeitet.
FIN, RST oder Timeout beendet die Sitzung.

Eine zustandsbehaftete Firewall kann Pakete verwerfen, wenn diese nicht zum erwarteten Zustand passen, beispielsweise:

ACK ohne bekannte Sitzung;
unerwartete TCP-Flags;
Rückverkehr mit abweichenden Adressen oder Ports;
Sequenznummer außerhalb des akzeptierten Fensters;
verspäteter Rückverkehr nach Sitzungsablauf;
Rückverkehr über einen anderen nicht synchronisierten Firewallknoten;
fragmentierter Verkehr, der nicht korrekt zugeordnet werden kann.

Typische Daten eines Sitzungseintrags

Ein Sitzungseintrag kann unter anderem enthalten:

Sitzungs-ID
Protokoll
Quellzone
Zielzone
Eingangsschnittstelle
Ausgangsschnittstelle
Original-Quelladresse
Original-Quellport
Original-Zieladresse
Original-Zielport
übersetzte Quelladresse
übersetzter Quellport
übersetzte Zieladresse
übersetzter Zielport
passende Regel
Anwendung
TCP-Zustand
Startzeit
letzte Aktivität
Timeout
gesendete Pakete
empfangene Pakete
gesendete Bytes
empfangene Bytes
Sitzungsendgrund
Clusterbesitzer

Die Sitzungstabelle ist ein wichtiger Nachweis, ersetzt aber nicht die Prüfung der tatsächlichen Anwendung.

Eine vorhandene Sitzung beweist nur, dass die Firewall einen Zustand führt. Sie beweist nicht automatisch:

dass der Serverprozess korrekt antwortet;
dass TLS funktioniert;
dass die Anwendung ein gültiges Ergebnis liefert;
dass Nutzdaten in beide Richtungen übertragen werden;
dass die Sitzung nicht bereits festhängt;
dass alle weiteren Sicherheitsprüfungen erfolgreich sind.

Zustandslos und zustandsbehaftet vergleichen

Prüfpunkt	Zustandslose ACL	Stateful Firewall
Verarbeitung	jedes Paket einzeln	Paket plus Sitzungszustand
Rückverkehr	benötigt passende Gegenregel	bestehender Sitzung zugeordnet
TCP-Zustand	normalerweise nicht vollständig verfolgt	Handshake und Status werden verfolgt
UDP	jedes Datagramm nach Regel	häufig zeitlich begrenzte Pseudositzung
ICMP	eigene Regeln pro Richtung erforderlich	kann Anfrage und Antwort zuordnen
Asymmetrischer Pfad	Regel kann trotzdem passen	häufig Sitzungsproblem
Ressourcenverbrauch	geringer	Sitzungstabelle benötigt Speicher
Timeoutwirkung	keine Sitzung	Rückverkehr kann nach Ablauf verworfen werden
Regeländerung	wirkt auf folgende Pakete	bestehende Sitzungen können abweichend behandelt werden

Das Verhalten bei Regeländerungen und bestehenden Sitzungen ist produktspezifisch. Einige Systeme prüfen bestehende Sitzungen nicht sofort erneut, andere beenden betroffene Sitzungen oder bewerten bestimmte Eigenschaften erneut.

TCP-Verkehr prüfen

Bei TCP sind mindestens folgende Punkte zu unterscheiden:

erreicht das SYN die Firewall?
welche Regel trifft auf das SYN?
verlässt das SYN die Firewall?
erreicht das SYN den Server?
sendet der Server ein SYN, ACK oder RST?
erreicht die Antwort dieselbe Firewallinstanz?
wird die Antwort der Sitzung zugeordnet?
erreicht die Antwort den Client?
wird der Handshake vollständig abgeschlossen?
endet die Sitzung durch FIN, RST, Timeout oder Richtlinie?

Befundbeispiele:

Paketfolge	Mögliche Einordnung
wiederholte `SYN`, keine Antwort	Paketverlust, Firewall-Drop, falsche Route oder Server antwortet nicht
`SYN`, danach sofortiges `RST`	Ziel lehnt aktiv ab oder Zwischenkomponente erzeugt Reset
`SYN`, `SYN-ACK`, anschließend kein `ACK`	Rückweg zum Client oder Clientseite prüfen
vollständiger Handshake, danach sofortiger `RST`	Anwendung, Proxy, Sicherheitsprofil oder Protokollproblem
Daten nur in eine Richtung	Rückweg, asymmetrischer Pfad oder Sicherheitsprüfung
Sitzung in Firewall vorhanden, keine Serverantwort	Zielsystem, nachgelagerte Firewall oder Route prüfen

UDP-Verkehr prüfen

UDP besitzt keinen TCP-Handshake. Stateful Firewalls führen deshalb häufig eine zeitlich begrenzte Pseudositzung.

Beispiel:

192.0.2.100:54000 -> 198.51.100.53:53/UDP

Die Firewall kann anschließend eine passende Antwort erlauben:

198.51.100.53:53 -> 192.0.2.100:54000/UDP

Zu prüfen sind:

wurde das erste Datagramm durch eine Regel erlaubt?
wurde eine Pseudositzung angelegt?
trifft die Antwort vor Ablauf des UDP-Timeouts ein?
stimmen Antwortadresse und Antwortport mit dem erwarteten Datenfluss überein?
verwendet die Anwendung mehrere Zieladressen oder Ports?
wechselt das Protokoll von UDP zu TCP?
wird ICMP Destination Unreachable zurückgegeben?
blockiert eine zustandslose Gegen-ACL den Rückverkehr?

Ein vorhandener UDP-Sitzungseintrag beweist keine erfolgreiche Anwendungskommunikation.

ICMP und ICMPv6 prüfen

ICMP transportiert nicht nur Echo-Anfrage und Echo-Antwort, sondern auch wichtige Fehlermeldungen.

Beispiele:

Ziel nicht erreichbar;
Port nicht erreichbar;
Fragmentierung erforderlich;
Time Exceeded;
Parameter Problem;
Packet Too Big bei IPv6.

Zu prüfen sind:

ICMP-Typ und ICMP-Code;
Richtung;
Quell- und Zieladresse;
Zuordnung zu einer ursprünglichen Sitzung;
separate ICMP-Regeln;
ICMP-Inspektionsfunktion;
IPv4- und IPv6-Regeln;
Rate Limits;
vorgeschaltete Router-ACLs.

Das pauschale Blockieren von ICMP kann Diagnose, Path-MTU-Discovery und besonders IPv6-Funktionen beeinträchtigen.

Sitzungstimeouts

Stateful Firewalls entfernen inaktive Sitzungen nach definierten Zeiträumen.

Zu prüfen sind:

TCP-Handshake-Timeout;
TCP-Idle-Timeout;
TCP-Time-Wait- oder Closing-Timeout;
UDP-Timeout;
ICMP-Timeout;
anwendungsspezifischer Timeout;
halb offene Verbindungen;
Langzeitverbindungen;
Keepalive-Verhalten;
maximale Sitzungsdauer;
benutzerdefinierte Timeoutprofile;
Sitzungslast und Tabellenfüllstand.

Typische Symptome eines Timeoutproblems:

kurze Verbindungen funktionieren;
lange Leerlaufphasen beenden die Verbindung;
Anwendung meldet nach einer festen Zeit einen Abbruch;
die nächste Übertragung nach Inaktivität schlägt fehl;
eine neue Verbindung funktioniert sofort wieder;
Client und Server halten die Sitzung unterschiedlich lange für gültig.

Ein Timeout sollte nur geändert werden, wenn der zeitliche Zusammenhang nachgewiesen wurde. Eine pauschale Erhöhung kann den Speicherverbrauch und die Anzahl gleichzeitig geführter Sitzungen vergrößern.

Bestehende Sitzungen bei Regeländerungen

Nach einer Regeländerung sind neue und bestehende Verbindungen getrennt zu prüfen.

Mögliche produktabhängige Verhaltensweisen:

neue Sitzungen verwenden die neue Regel;
vorhandene Sitzungen laufen nach alter Entscheidung weiter;
vorhandene Sitzungen werden neu bewertet;
verweigernde Änderung beendet passende Sitzungen;
NAT-Änderung wirkt erst auf neue Sitzungen;
Anwendungserkennung ändert die verwendete Regel während der Sitzung;
Clusterknoten besitzen vorübergehend unterschiedliche Zustände.

Deshalb muss ein Test dokumentieren:

Test A:
bereits vor der Änderung bestehende Verbindung

Test B:
nach der Änderung vollständig neu aufgebaute Verbindung

Wenn ein neuer Test erforderlich ist, sollte nur die einzelne betroffene Anwendungssitzung kontrolliert beendet werden. Das vollständige Löschen der Sitzungstabelle ist unverhältnismäßig und kann viele produktive Verbindungen unterbrechen.

Routing und Zielzone

Die Zielzone wird bei vielen Firewalls anhand der Ausgangsschnittstelle oder Routingentscheidung bestimmt.

Zu prüfen sind:

aktive Route zur Zieladresse;
Präfixlänge;
nächster Hop;
Routinginstanz oder VRF;
Policy-Based Routing;
ECMP;
Tunnelroute;
dynamisches Routing;
Failoverroute;
Ausgangsschnittstelle;
daraus resultierende Zielzone.

Eine Sicherheitsregel kann inhaltlich korrekt aussehen, aber nicht passen, wenn die Firewall aufgrund einer falschen Route eine andere Zielzone bestimmt.

Beispiel:

Erwartet:
CLIENTS -> SERVER

Tatsächlich:
CLIENTS -> WAN

In diesem Fall ist nicht zuerst die Regel CLIENTS -> SERVER zu verändern. Zunächst muss geklärt werden, warum die Route zur falschen Ausgangszone führt.

NAT und Sicherheitsrichtlinie

NAT kann Adressen und Ports verändern.

Beispiel einer Zielübersetzung:

Original:
203.0.113.40:55000 -> 198.51.100.10:443

Nach DNAT:
203.0.113.40:55000 -> 10.20.30.40:8443

Beispiel einer Quellübersetzung:

Original:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Für die Diagnose sind beide Ansichten zu dokumentieren:

Merkmal	Vor NAT	Nach NAT
Quelladresse	ursprünglicher Absender	übersetzte Quelladresse
Quellport	ursprünglicher Quellport	übersetzter Quellport
Zieladresse	aufgerufene Zieladresse	internes oder übersetztes Ziel
Zielport	aufgerufener Zielport	übersetzter Zielport

Je nach Hersteller, Regelart und Richtung kann die Sicherheitsrichtlinie vor oder nach einer bestimmten NAT-Verarbeitung ausgewertet werden. Es darf nicht angenommen werden, dass eine Firewallregel immer die öffentliche oder immer die private Adresse verwenden muss.

Zu prüfen sind:

NAT-Regel;
Sicherheitsregel;
Reihenfolge der Verarbeitung;
Original- und Übersetzungsadresse;
Original- und Übersetzungsport;
NAT-Ausnahme;
Hairpin- oder U-Turn-NAT;
doppelte NAT-Regeln;
Proxy-ARP;
Rückroute;
NAT-Sitzung;
Porterschöpfung;
Clusterzustand.

Eine passende Sicherheitsregel kann durch eine falsche NAT-Regel wirkungslos bleiben.

Zonen und virtuelle Kontexte

Viele Firewalls besitzen:

Sicherheitszonen;
virtuelle Router;
virtuelle Systeme;
Mandanten;
Security Contexts;
Routinginstanzen;
Verwaltungs- und Datenebenen;
zentrale und lokale Richtlinien.

Zu prüfen sind:

richtige Firewall;
aktiver Clusterknoten;
richtiger Mandant;
richtiger virtueller Kontext;
richtige Routinginstanz;
richtige Policy-Version;
richtige Eingangszone;
richtige Ausgangszone;
globale oder geerbte Regeln;
lokale Ausnahmen;
zentral verwaltete und lokal definierte Regeln.

Eine Regel in einem anderen virtuellen Kontext kann denselben Namen besitzen, aber für den betroffenen Datenverkehr vollständig wirkungslos sein.

Zusätzliche Sicherheitsprüfungen

Eine Regel mit der Aktion allow bedeutet bei modernen Firewalls häufig nur, dass der Datenfluss weiter geprüft werden darf.

Weitere mögliche Prüfungen:

Intrusion Prevention;
Malware-Erkennung;
Antivirus;
Dateitypprüfung;
URL-Filterung;
DNS-Sicherheitsprüfung;
Anwendungskontrolle;
Benutzeridentifikation;
Data Loss Prevention;
Botnet-Erkennung;
TLS-Entschlüsselung;
Zertifikatsprüfung;
Protokolldekodierung;
Geo-IP-Regel;
Reputationsprüfung;
Threat-Intelligence-Regel;
DoS-Schutz;
Zone Protection;
Flood Protection.

Deshalb sind mindestens zwei Entscheidungen zu unterscheiden:

Netzwerkregel:
allow

Sicherheitsprofil:
block

Im Protokoll können dafür mehrere Einträge entstehen. Ein allow-Ereignis darf nicht isoliert als Nachweis einer erfolgreichen Verbindung bewertet werden.

Application-Awareness

Eine anwendungsbasierte Firewall kann eine Sitzung zunächst anhand des Ports behandeln und später die erkannte Anwendung berücksichtigen.

Zu prüfen sind:

erkannte Anwendung;
Zeitpunkt der Erkennung;
unbekannte oder unvollständige Anwendung;
abweichender Port;
verschlüsselter Datenverkehr;
SNI;
HTTP-Hostheader;
ALPN;
QUIC;
Portwechsel;
abhängige Anwendungen;
benötigte Grundanwendung;
Regel mit application-default;
TLS-Entschlüsselungsstatus.

Beispiel:

TCP-Port:
443

Erkannte Anwendung:
quic

Erwartete Anwendung:
ssl/web-browsing

Eine reine Portfreigabe sagt nicht aus, welche Anwendung tatsächlich transportiert wird.

Regelbindung prüfen

Eine definierte ACL oder Policy wirkt nur, wenn sie an der richtigen Stelle eingebunden ist.

Zu prüfen sind:

Schnittstelle;
Richtung;
Sicherheitszone;
Regelgruppe;
Policy-Paket;
virtueller Kontext;
Mandant;
Gerätegruppe;
Zielgerät;
aktive Konfiguration;
erfolgreicher Commit;
erfolgreicher Deploymentstatus;
Synchronisation im Cluster;
zentrale Vererbung.

Beispielbefund:

ACL:
WEB-IN

Konfiguriert:
ja

Gebunden an:
DMZ-Schnittstelle eingehend

Tatsächlicher Verkehr:
tritt an WAN-Schnittstelle ein

Ergebnis:
ACL WEB-IN verarbeitet diesen Datenfluss nicht

Aktive und gespeicherte Konfiguration unterscheiden

Je nach Produkt können unterschiedliche Konfigurationsstände existieren:

bearbeitete Konfiguration;
Kandidatenkonfiguration;
gespeicherte Startkonfiguration;
laufende Konfiguration;
zuletzt erfolgreich ausgerollte Richtlinie;
zentral vorgesehene Richtlinie;
lokale Gerätekonfiguration;
Konfiguration des aktiven Knotens;
Konfiguration des passiven Knotens.

Zu prüfen sind:

wurde die Änderung gespeichert?
wurde sie erfolgreich geprüft?
wurde sie committed?
wurde sie auf das richtige Gerät ausgerollt?
ist das Deployment abgeschlossen?
existieren Warnungen oder Fehler?
verwenden alle Clusterknoten dieselbe Version?
wurde eine lokale Änderung durch zentrale Verwaltung überschrieben?

Eine im Managementsystem sichtbare Regel beweist nicht, dass sie bereits auf der Datenebene aktiv ist.

Hochverfügbarkeit und Cluster

Bei einem Firewallcluster sind zusätzlich zu prüfen:

aktiver und passiver Knoten;
Clusterzustand;
Konfigurationssynchronisation;
Sitzungssynchronisation;
NAT-Synchronisation;
Routingzustand;
Linkstatus;
Split-Brain-Schutz;
Eigentümer der Sitzung;
Datenpfad des Hinverkehrs;
Datenpfad des Rückverkehrs;
Zustand nach Failover;
Zeitstempel der letzten Umschaltung.

Typischer Fehler:

Hinverkehr:
FW-A

Rückverkehr:
FW-B

Sitzungssynchronisation:
fehlerhaft

FW-B kennt die durch FW-A aufgebaute Sitzung möglicherweise nicht und verwirft den Rückverkehr als ungültig.

Asymmetrische Pfade und Connection Tracking werden in 9.6 Asymmetrische Pfade, Sessiontabellen und Connection Tracking weiter vertieft.

Cloud-Firewalls und Cloud-ACLs

Cloud-Plattformen können mehrere Filterebenen kombinieren:

Security Group an der Netzwerkschnittstelle;
Subnetz-ACL;
zentrale Cloud-Firewall;
Load Balancer;
Web Application Firewall;
Kubernetes Network Policy;
Plattformdienst-Firewall;
lokaler Hostfilter;
On-Premises-Firewall;
Routing- und Transitkomponente.

Diese Ebenen müssen einzeln geprüft werden.

AWS Security Groups und Network ACLs

Merkmal	AWS Security Group	AWS Network ACL
Zuordnung	Netzwerkschnittstelle oder Ressource	Subnetz
Zustand	stateful	stateless
Regeln	Freigaberegeln	Erlauben und Verweigern
Rückverkehr	für verfolgte Verbindung automatisch berücksichtigt	muss durch Gegenregel erlaubt werden
Reihenfolge	keine klassische First-Match-Reihenfolge der Freigaberegeln	nach Regelnummer
Diagnosefokus	tatsächlich zugeordnete Gruppen	tatsächlich zugeordnete Subnetz-ACL
Ephemeral Ports	Rückverkehr durch Zustand	ausdrücklich berücksichtigen

Bei einer AWS Network ACL muss beispielsweise für eine eingehend erlaubte TCP-Verbindung auch der ausgehende Rückverkehr zum dynamischen Clientport erlaubt sein.

Vereinfachtes Beispiel:

Inbound:
TCP von 192.0.2.0/24 zu Zielport 443 erlauben

Outbound:
TCP zu 192.0.2.0/24 und benötigtem dynamischem Clientportbereich erlauben

Der tatsächlich verwendete Portbereich hängt vom Clientbetriebssystem, der Anwendung und gegebenenfalls weiteren NAT-Komponenten ab.

Azure Network Security Groups

Azure Network Security Groups arbeiten zustandsbehaftet und verwenden Regeln mit Prioritätswerten.

Grundprinzip:

kleinere Prioritätszahl = höhere Priorität

Beispiel:

Priorität 100:
Deny TCP 192.0.2.66 -> 10.20.30.40:443

Priorität 200:
Allow TCP 192.0.2.0/24 -> 10.20.30.40:443

Zu prüfen sind:

NSG am Subnetz;
NSG an der Netzwerkschnittstelle;
effektive Sicherheitsregeln;
Priorität;
Standardregeln;
Service Tags;
Application Security Groups;
NAT-Bezug;
Azure Firewall;
User Defined Routes;
Load Balancer;
Network Watcher Flow Logs;
tatsächlich verwendete private Zieladresse.

Bei eingehendem Verkehr verarbeitet eine Azure NSG die Regeln nach der Übersetzung einer öffentlichen in eine private IP-Adresse. Bei ausgehendem Verkehr erfolgt die NSG-Verarbeitung vor der Übersetzung einer privaten in eine öffentliche Adresse.

Netzwerkregel und Anwendungsfirewall unterscheiden

Eine Netzwerkfirewall prüft typischerweise IP-Adressen, Ports, Protokolle, Sitzungen und gegebenenfalls Anwendungen.

Eine Web Application Firewall prüft dagegen HTTP- oder HTTPS-Anfragen auf Anwendungsebene.

Beispiel:

Netzwerkfirewall:
TCP 443 erlaubt

Web Application Firewall:
HTTP-Anfrage wegen Regelverletzung blockiert

Ein erfolgreicher TCP-Handshake bis zum Reverse Proxy beweist daher nicht, dass die Webanwendung die Anfrage akzeptiert.

Ausgangszustand erfassen

Vor Veränderungen sind folgende Informationen zu sichern:

Datum und Uhrzeit
Zeitzone
Clientname und Clientadresse
Servername und Serveradresse
Quellport
Zielport
Protokoll
Anwendung
exakte Fehlermeldung
betroffener Benutzer
Eingangs- und Ausgangszone
erwarteter Firewallpfad
aktiver Firewallknoten
Regelname und Regel-ID
NAT-Regel
Sitzungs-ID
Policy-Version
Logeinträge
Trefferzähler
Paketaufzeichnungen

Die Uhren von Client, Server, Firewall und zentralem Protokollsystem müssen ausreichend synchronisiert sein. Andernfalls können zusammengehörige Ereignisse falsch zugeordnet werden.

Fehlerumfang bestimmen

Zu klären ist:

betrifft die Störung nur einen Client?
betrifft sie ein gesamtes Quellnetz?
betrifft sie nur eine Zieladresse?
betrifft sie alle Ziele einer Zone?
betrifft sie nur einen Port?
betrifft sie TCP, UDP oder ICMP?
betrifft sie IPv4, IPv6 oder beide?
tritt sie nur über VPN auf?
tritt sie nur über einen Standort auf?
betrifft sie neue oder auch bestehende Sitzungen?
tritt sie erst seit einer Regeländerung auf?
betrifft sie nur einen Clusterknoten?
tritt sie nur zu bestimmten Uhrzeiten auf?
betrifft sie nur eine erkannte Anwendung?
ist sie von der Nutzlastgröße abhängig?

Ein präzise begrenzter Fehlerumfang verhindert unnötig weitreichende Regeländerungen.

Firewallpfad nachweisen

Der vorgesehene Firewallpfad darf nicht nur aus dem Netzplan abgeleitet werden.

Mögliche Nachweise:

Traceroute;
Routingtabellen;
Flow Logs;
NetFlow oder IPFIX;
Firewall-Sitzungstabelle;
Eingangs- und Ausgangsaufzeichnung;
Schnittstellenzähler;
MAC- und ARP-Tabellen;
Cloud Network Watcher;
zentrale SD-WAN- oder Transitprotokolle;
Logeintrag mit Eingangs- und Ausgangszone.

Zu beachten ist, dass Traceroute nicht jede Firewall sichtbar macht. Eine transparente Firewall oder ein Gerät, das TTL-Abläufe nicht beantwortet, kann im Traceroute fehlen.

Regelwerk zunächst nur lesend prüfen

Zu erfassen sind:

Name der aktiven Policy;
Regel-ID;
Regelname;
Position oder Priorität;
Quelle;
Ziel;
Zonen;
Protokoll;
Quellport;
Zielport;
Anwendung;
Aktion;
Sicherheitsprofile;
Zeitplan;
Protokollierung;
Trefferzähler;
letztes Trefferdatum;
Ersteller;
Änderungsreferenz;
Objektinhalte;
Standardaktion.

Ein Screenshot allein ist kein idealer technischer Nachweis. Wenn möglich, sollten zusätzlich exportierbare Text- oder Konfigurationsdaten mit Zeitstempel gesichert werden. Dabei sind Zugangsdaten, Schlüssel und andere schützenswerte Informationen zu entfernen.

Trefferzähler richtig auswerten

Ein Trefferzähler kann zeigen, dass Verkehr eine Regel erreicht hat. Er muss jedoch vorsichtig interpretiert werden.

Zu beachten sind:

einige Produkte zählen nur den ersten Paket- oder Sitzungsaufbau;
andere zählen alle passenden Pakete;
Hardware-Offloading kann separate Zähler verwenden;
Zähler können pro Clusterknoten geführt werden;
zentrale Ansicht kann verzögert sein;
ein breites Regelobjekt kann Verkehr vieler Systeme zählen;
alte Treffer beweisen keinen Treffer beim aktuellen Test;
Zähler können nach Neustart oder Deployment zurückgesetzt sein;
ein Zähleranstieg bei einer allow-Regel beweist keine erfolgreiche Anwendung;
ein Zählerstand von null kann auf falschen Pfad, falsche Regel oder falschen Kontext hinweisen.

Belastbarer Ablauf:

aktuellen Zählerstand mit Uhrzeit dokumentieren;
genau einen kontrollierten Test ausführen;
Zähler erneut ablesen;
Differenz bewerten;
gleichzeitig Firewallprotokoll und Anwendungsergebnis prüfen.

Zähler dürfen erst nach der Beweissicherung und nur mit Freigabe zurückgesetzt werden.

Firewallprotokolle auswerten

Ein brauchbarer Protokolleintrag enthält möglichst:

Ereigniszeit;
Firewallname;
Clusterknoten;
virtuellen Kontext;
Eingangszone;
Ausgangszone;
Eingangs- und Ausgangsschnittstelle;
Quelladresse;
Quellport;
Zieladresse;
Zielport;
Protokoll;
NAT-Adressen und NAT-Ports;
Regelname;
Regel-ID;
Aktion;
erkannte Anwendung;
Sicherheitsprofil;
Sitzungs-ID;
Pakete und Bytes je Richtung;
Sitzungsendgrund;
Drop-Grund.

Nach exakt diesen Merkmalen sollte gefiltert werden:

source = 192.0.2.100
destination = 198.51.100.25
destination_port = 443
protocol = TCP
time = 2026-08-02 10:15:00 bis 10:16:00

Ein fehlender Logeintrag beweist nicht automatisch, dass die Firewall den Datenfluss nicht gesehen hat. Mögliche Gründe:

Protokollierung ist für die Regel deaktiviert;
nur Sitzungsende wird protokolliert;
Sitzung läuft noch;
Ereignisse werden verzögert übertragen;
falscher Clusterknoten wurde geprüft;
falscher Mandant wurde geprüft;
Protokolle werden gefiltert oder begrenzt;
Datenfluss verwendet einen anderen Pfad;
Paket wird vor der normalen Sicherheitsregel verworfen;
Hardware-Offload verwendet andere Diagnosezähler;
Rate Limiting unterdrückt Ereignisse.

Erlaubt-, Verworfen- und Sitzungsendgründe unterscheiden

Mögliche Aktionen und Endgründe:

Befund	Mögliche Bedeutung
`allow`	Netzwerkregel hat den Datenfluss zugelassen
`deny`	Sicherheitsregel hat den Datenfluss verworfen
`drop`	Paket wurde ohne aktive Ablehnungsantwort verworfen
`reject`	Firewall sendet eine aktive Ablehnungsantwort
`reset-client`	Firewall sendet TCP-RST zum Client
`reset-server`	Firewall sendet TCP-RST zum Server
`aged-out`	Sitzung ist durch Timeout abgelaufen
`tcp-rst-from-client`	Client hat die Sitzung beendet
`tcp-rst-from-server`	Server hat die Sitzung beendet
`policy-deny`	Richtlinie hat den Aufbau blockiert
`threat` oder `ips-drop`	Sicherheitsprofil hat blockiert
`decrypt-error`	TLS-Entschlüsselung ist fehlgeschlagen
`resources-unavailable`	Kapazitäts- oder Ressourcengrenze
`invalid-state`	Paket passt nicht zum erwarteten Sitzungszustand
`no-route`	keine verwendbare Route
`nat-failure`	NAT-Verarbeitung ist fehlgeschlagen

Die genaue Benennung ist herstellerspezifisch.

Policy-Match- und Packet-Tracer-Werkzeuge

Viele Hersteller bieten Werkzeuge an, die einen hypothetischen Datenfluss gegen die aktuelle Konfiguration prüfen.

Benötigte Eingaben:

Eingangsschnittstelle
Quellzone
Quelladresse
Quellport
Zieladresse
Zielport
Protokoll
Benutzer oder Anwendung, sofern erforderlich

Solche Werkzeuge können unter anderem zeigen:

Routingentscheidung;
NAT-Regel;
Sicherheitsregel;
Ausgangsschnittstelle;
Zielzone;
zulassende oder verweigernde Phase;
implizite Standardaktion.

Ein Simulationsergebnis beweist nicht:

dass das reale Paket die Firewall erreicht;
dass die physische Schnittstelle funktioniert;
dass der Server erreichbar ist;
dass der Rückweg stimmt;
dass die Anwendung antwortet;
dass eine nachgelagerte Firewall erlaubt;
dass ein Sicherheitsprofil den realen Inhalt akzeptiert;
dass derselbe Clusterknoten den realen Datenfluss verarbeitet.

Die Simulation muss mit einem realen Test, Protokollen und gegebenenfalls Paketaufzeichnungen kombiniert werden.

Cisco IOS ACLs lesend prüfen

Beispielbefehle:

show ip access-lists

show ip access-lists <ACL-Name-oder-Nummer>

show running-config | section access-list

show running-config | include ip access-group

show ip interface

Zu prüfen sind:

Reihenfolge der Einträge;
permit oder deny;
Trefferzähler;
implizites Verbot;
Schnittstellenbindung;
Richtung in oder out;
Wildcard-Masken;
Protokoll;
Quell- und Zielport;
IPv4- oder IPv6-ACL.

Die genaue Syntax hängt von Plattform und Softwareversion ab.

Cisco Secure Firewall ASA lesend prüfen

ACLs und Bindungen:

show access-list

show access-group

Verbindungen und NAT:

show conn

show conn address 192.0.2.100

show xlate

Routing:

show route

Simulation eines TCP-Pakets:

packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed

Drop-Zähler:

show asp drop

show asp drop liefert interne Drop-Zähler und ist für gezielte Fehleranalysen vorgesehen. Die Ausgabe ist umfangreich und muss zeitlich mit einem kontrollierten Test korreliert werden.

Bei Cisco ASA verwenden normale Zugriffsregeln für NAT-Verkehr die reale Adresse des Ziels. Dieses Verhalten darf nicht ungeprüft auf andere Firewallprodukte übertragen werden.

Juniper SRX lesend prüfen

Beispielbefehle:

show security policies

show security policies hit-count

show security flow session

show security flow session source-prefix 192.0.2.100

show security flow session destination-prefix 198.51.100.25

show route 198.51.100.25

Für eine Richtlinienzuordnung kann abhängig von Junos-Version und Konfiguration show security match-policies verwendet werden. Die vollständige lokale Syntax ist mit der CLI-Hilfe zu prüfen.

Juniper-Sicherheitsrichtlinien werden innerhalb des zutreffenden Zonenkontexts in Reihenfolge ausgewertet. Die erste passende Richtlinie bestimmt die Aktion.

Palo Alto Networks lesend prüfen

Sitzungssuche:

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

Routingprüfung:

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

Policy-Match-Tests und genaue Filteroptionen sind versionsabhängig. Vor der Ausführung ist die lokale CLI-Hilfe zu verwenden:

test security-policy-match ?

show session all filter ?

Bei der Auswertung sind unter anderem zu prüfen:

Regelname;
Quell- und Zielzone;
Anwendung;
Dienst;
NAT-Regel;
Sicherheitsprofile;
Sitzungsendgrund;
Pakete und Bytes je Richtung.

Palo-Alto-Sicherheitsregeln werden innerhalb der Regelbasis von oben nach unten ausgewertet. Die erste passende Regel wird angewendet. Spezifische Regeln müssen daher vor allgemeineren Regeln stehen.

Linux als Netzwerkfirewall lesend prüfen

Wenn ein Linux-System als Router oder Firewall eingesetzt wird, können abhängig von der Konfiguration folgende Prüfungen relevant sein.

Aktives nftables-Regelwerk:

sudo nft list ruleset

Regelwerk mit Handles:

sudo nft -a list ruleset

Routing:

ip route show

ip -6 route show

Weiterleitungseinstellung:

sysctl net.ipv4.ip_forward

sysctl net.ipv6.conf.all.forwarding

Connection Tracking, sofern das Werkzeug vorhanden ist:

sudo conntrack -L

Gezielte Suche:

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

Zu beachten sind:

richtige Chain;
Hook;
Priorität;
Tabelle;
Familie ip, ip6 oder inet;
Eingangs- und Ausgangsschnittstelle;
Default Policy;
NAT-Chain;
Connection-Tracking-Zustand;
Paketzähler;
Weiterleitung im Kernel.

Das Löschen von Conntrack-Einträgen ist eine verändernde Maßnahme und darf nicht als erster Diagnoseschritt erfolgen.

Paketaufzeichnung an der Firewall

Eine Paketaufzeichnung ist sinnvoll, wenn nicht eindeutig ist:

ob das Paket die Firewall erreicht;
ob es die Firewall wieder verlässt;
ob die Antwort zurückkommt;
ob NAT wie vorgesehen angewendet wird;
ob ein Reset erzeugt wird;
ob Pakete wiederholt werden;
ob nur eine Richtung sichtbar ist;
ob Fragmentierung auftritt;
ob der Datenfluss einen anderen Ausgang verwendet.

Idealer Vergleich:

Aufzeichnung A:
Eingangsschnittstelle

Aufzeichnung B:
Ausgangsschnittstelle

Befundbeispiele:

Eingang	Ausgang	Einordnung
Paket nicht sichtbar	Paket nicht sichtbar	Pfad vor der Firewall prüfen
Paket sichtbar	Paket nicht sichtbar	Firewallverarbeitung, Regel, NAT oder Route prüfen
Paket mit übersetztem Ziel sichtbar	Paket erreicht Server	Firewall hat Hinverkehr weitergeleitet
Serverantwort am Ausgangsnetz sichtbar	Antwort nicht zum Clientnetz	Firewallzustand, NAT oder Rückroute prüfen
vollständiger Verkehr auf beiden Seiten	Client meldet trotzdem Fehler	Host, Anwendung, Proxy oder TLS prüfen

Bei Hardware-Offloading kann eine allgemeine Paketaufzeichnung möglicherweise nicht alle weitergeleiteten Pakete zeigen. Dann sind herstellerspezifische Capture-Funktionen, Dataplane-Diagnosen oder ein externer SPAN/TAP erforderlich.

Aufzeichnungen müssen:

zeitlich begrenzt;
auf Quelle und Ziel gefiltert;
vor unberechtigtem Zugriff geschützt;
nach der Auswertung kontrolliert gelöscht oder archiviert;
datenschutzrechtlich und organisatorisch freigegeben

werden.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Die allgemeine Freigaberegel mit Priorität 100 erlaubt das gesamte
Clientnetz und überschattet die nachfolgende Sperrregel für
192.0.2.66.

Erwarteter Befund:
Ein Policy-Match-Test für 192.0.2.66 -> 198.51.100.25:443 nennt
die allgemeine Freigaberegel. Der Trefferzähler der Sperrregel
ändert sich beim Test nicht.

Gegenbeweis:
Der reale Datenfluss trifft nachweislich die Sperrregel und wird
durch diese verworfen.

Testmethode:
Policy-Match, kontrollierter Verbindungsversuch, Regelzähler und
Firewallprotokoll zeitlich korrelieren.

Risiko:
Nur lesende Diagnose; keine Auswirkung auf Produktivverkehr.

Erfolgskriterium:
Tatsächlich angewendete Regel ist mit Regel-ID und Logeintrag
eindeutig nachgewiesen.

Weitere mögliche Hypothesen:

Datenverkehr durchläuft eine andere Firewall.
Falsche Route führt zur falschen Zielzone.
Firewallregel verwendet die öffentliche statt der intern ausgewerteten Adresse.
Eine vorgelagerte globale Regel blockiert vor der lokalen Regel.
Bestehende Sitzung verwendet noch den alten Richtlinienzustand.
Sicherheitsprofil blockiert nach einer erlaubenden Netzwerkregel.
Rückverkehr erreicht einen anderen Clusterknoten.
Eine zustandslose Cloud-ACL blockiert den dynamischen Rückport.
FQDN-Objekt enthält nicht die vom Client verwendete Zieladresse.
IPv4 ist erlaubt, IPv6 jedoch nicht.
Die Regel ist konfiguriert, aber nicht ausgerollt.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko	Rückweg
Regelreihenfolge korrigieren	Überschattung nachgewiesen	andere Datenflüsse können anders behandelt werden	vorherige Reihenfolge wiederherstellen
spezifische Freigabe ergänzen	fehlende Freigabe bestätigt	zusätzliche Angriffsfläche	neue Regel deaktivieren oder entfernen
Adressobjekt korrigieren	Objektinhalt nachweislich falsch	alle Regeln mit diesem Objekt betroffen	vorherigen Objektstand wiederherstellen
Dienstobjekt korrigieren	Port oder Protokoll falsch	weitere Anwendungen können betroffen sein	vorherige Definition wiederherstellen
Zonenbezug korrigieren	tatsächlicher Pfad nachgewiesen	Segmentierungswirkung ändert sich	vorherige Zonenregel wiederherstellen
NAT-Regel korrigieren	Übersetzungsfehler bestätigt	Erreichbarkeit und Rückweg ändern sich	vorherige NAT-Regel aktivieren
Route korrigieren	falsche Ausgangszone oder falscher Next Hop	viele Ziele können betroffen sein	vorherige Route wiederherstellen
Logging aktivieren	fehlende Beweisdaten	zusätzliche Last und Datenmenge	Logging zurücknehmen
einzelne Sitzung beenden	alte Sitzung beeinflusst Test	eine produktive Verbindung wird unterbrochen	Anwendung baut neue Sitzung auf
Timeout anpassen	zeitabhängiger Sitzungsabbruch nachgewiesen	höhere Sitzungsanzahl und Ressourcennutzung	alten Timeoutwert wiederherstellen
Sicherheitsprofil korrigieren	Fehlklassifizierung nachgewiesen	Schutzwirkung kann sinken	vorheriges Profil wiederherstellen
Cluster-Synchronisation reparieren	Zustandsabweichung nachgewiesen	Failover- und Sitzungsrisiko	herstellerspezifischer Rückfallplan

Eine allgemeine Testfreigabe ist kein geeigneter Ersatz für eine präzise Ursachenanalyse.

Vollständiger Diagnoseablauf

Exakte Fehlermeldung, Anwendung, Client, Benutzer und Uhrzeit dokumentieren.
Quelladresse und tatsächlichen Quellport bestimmen.
Zieladresse, Zielport und Protokoll bestimmen.
IPv4 und IPv6 unterscheiden.
Erwarteten Datenfluss und Sollzustand dokumentieren.
Umfang der Störung bestimmen.
Host-Firewalls als eigene Filterebenen berücksichtigen.
Direkte Erreichbarkeit und Dienstzustand prüfen.
Erwarteten Netzwerkpfad dokumentieren.
Tatsächlichen Firewallpfad nachweisen.
Aktiven Firewall- oder Clusterknoten bestimmen.
Richtigen Mandanten und virtuellen Kontext bestimmen.
Eingangs- und Ausgangsschnittstelle bestimmen.
Quell- und Zielzone bestimmen.
Route zur Zieladresse prüfen.
Policy-Based Routing, VRF und Tunnel berücksichtigen.
Originaladressen und Originalports dokumentieren.
NAT-Adressen und NAT-Ports dokumentieren.
Aktive NAT-Regel bestimmen.
Aktive Sicherheitsrichtlinie bestimmen.
Regelreihenfolge und Prioritäten prüfen.
Globale, geerbte und lokale Regeln berücksichtigen.
Implizite Standardaktion bestimmen.
Adress-, Dienst- und FQDN-Objekte auflösen.
Zeitpläne und Identitätskriterien prüfen.
Anwendungs- und Sicherheitsprofile prüfen.
Policy-Match- oder Packet-Tracer-Test durchführen.
Ergebnis nicht mit realem Durchsatz gleichsetzen.
Regelzähler mit Ausgangswert dokumentieren.
Genau einen kontrollierten Verbindungstest ausführen.
Zähleränderung und Protokolle auswerten.
Sitzungstabelle prüfen.
TCP-, UDP- oder ICMP-Zustand auswerten.
Pakete und Bytes je Richtung vergleichen.
Sitzungsendgrund auswerten.
Bestehende und neue Sitzung unterscheiden.
Bei Bedarf Eingangs- und Ausgangsaufzeichnung durchführen.
Hin- und Rückverkehr vergleichen.
Cluster- und Zustandssynchronisation prüfen.
Weitere Cloud- oder Subnetz-ACLs prüfen.
Hypothese, erwarteten Befund und Gegenbeweis formulieren.
Genau eine kontrollierte Maßnahme vorbereiten.
Risiko, Rückweg und Erfolgskriterium dokumentieren.
Maßnahme freigeben und umsetzen.
Neue Verbindung mit identischen Parametern testen.
Regel, Sitzung, Pakete, Bytes und Anwendungsergebnis verifizieren.
Repräsentative weitere Datenflüsse auf Nebenwirkungen prüfen.
Temporäre Logging- und Testregeln zurücknehmen.
Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
kein Firewalllog	falscher Pfad, Logging deaktiviert oder früher Drop	Route, Capture und Regelprotokollierung prüfen
`deny` durch erwartete Regel	Freigabe fehlt oder Regelinhalt falsch	Regelkriterien und Sollzustand vergleichen
`deny` durch andere Regel	Überschattung oder falscher Kontext	Reihenfolge und Priorität prüfen
implizites `deny`	keine ausdrückliche Regel passt	Zonen, Adressen, Protokoll und Ports prüfen
Allow-Regel hat Zähler null	Verkehr trifft Regel nicht	Pfad, Bindung, Kontext und Objekte prüfen
Allow-Regel zählt, Anwendung scheitert	späterer Filter, Rückweg oder Anwendung	Sitzungsende, Sicherheitsprofil und Capture
nur Hinpakete gezählt	Rückweg oder Serverantwort fehlt	Serverseite und Rückroute prüfen
Pakete in beide Richtungen, null Nutzdaten	Handshake- oder Anwendungsproblem	TCP-Flags, TLS und Anwendung prüfen
Sitzung `aged-out`	keine Antwort oder Idle-Timeout	Paketfluss und Timeoutdauer prüfen
Sitzung endet mit Server-RST	Server oder Zwischenkomponente lehnt ab	servernahe Aufzeichnung und Dienstprotokoll
Sitzung endet mit Client-RST	Client oder Anwendung beendet	Clientaufzeichnung und Anwendungsprotokoll
Policy-Test erlaubt, reales Paket fehlt	Firewall wird nicht erreicht	vorgelagertes Routing und Filter prüfen
Policy-Test erlaubt, reales Paket wird verworfen	zusätzliche Prüfung oder Zustand	Drop-Grund und Sicherheitsprofil
Zielzone unerwartet	Route oder VRF falsch	Routingentscheidung prüfen
NAT-Ziel unerwartet	falsche oder frühere NAT-Regel	NAT-Reihenfolge und Übersetzungstabelle
neue Verbindung scheitert, alte funktioniert	neue Richtlinie oder NAT-Entscheidung	alte und neue Sitzung vergleichen
alte Verbindung scheitert, neue funktioniert	veralteter Sitzungszustand	gezielt einzelne Sitzung untersuchen
nur UDP-Rückverkehr fehlt	stateless ACL oder Timeout	Gegenrichtung und UDP-Sitzung prüfen
nur große Pakete scheitern	MTU, Fragmentierung oder ICMP-Block	Paketgröße und ICMP-Fehler prüfen
nur IPv6 scheitert	fehlende IPv6-Regel oder Route	IPv6-Regelwerk und `ip -6 route`
nur ein Clusterknoten betroffen	Konfigurations- oder Zustandsabweichung	Knoten direkt vergleichen
AWS Security Group erlaubt, Verkehr scheitert	NACL, Route, Hostfilter oder Dienst	alle Filterebenen prüfen
AWS NACL erlaubt Hinweg, Rückweg fehlt	zustandslose Rückregel fehlt	dynamischen Rückportbereich prüfen
Azure NSG-Regel vorhanden, trifft nicht	Priorität oder andere NSG	effektive Regeln an NIC und Subnetz
`allow`, danach Threat-Drop	Sicherheitsprofil blockiert	Bedrohungs- oder IPS-Protokoll
FQDN-Regel trifft nicht	andere DNS-Auflösung	Firewall- und Clientauflösung vergleichen
nur bestimmte Uhrzeit betroffen	Regelzeitplan oder automatisches Deployment	Zeitplan und Änderungsprotokoll
nur nach Failover betroffen	Sitzungs- oder NAT-Synchronisation	HA-Status und neue Sitzung prüfen

Typische Diagnosefehler

Netzwerkfirewall und Host-Firewall verwechseln.
Nur den vorgesehenen und nicht den tatsächlichen Netzwerkpfad betrachten.
Von einer vorhandenen Regel auf eine wirksame Regel schließen.
Quellport und Zielport verwechseln.
Eingehend oder ausgehend ohne Bezug auf Schnittstelle oder Ressource angeben.
Sicherheitszonen nicht dokumentieren.
Regelreihenfolge ignorieren.
Implizite Verweigerung übersehen.
Globale oder geerbte Regeln nicht berücksichtigen.
Regel in falschem Mandanten oder Kontext prüfen.
Definierte, aber nicht gebundene ACL übersehen.
Bearbeitete und aktive Konfiguration verwechseln.
Fehlerhaftes Deployment nicht prüfen.
Adressobjekte nur nach Namen bewerten.
Verschachtelte Objektgruppen nicht auflösen.
Wildcard-Maske als Subnetzmaske lesen.
IPv4-Freigabe als IPv6-Freigabe interpretieren.
FQDN-Auflösung der Firewall nicht mit der Clientauflösung vergleichen.
Öffentliche und private NAT-Adresse verwechseln.
Herstellerabhängige NAT-Reihenfolge annehmen.
Falsche Route durch eine zusätzliche Firewallfreigabe verdecken.
Eine allow-Aktion als vollständigen Erfolgsnachweis bewerten.
Sicherheitsprofile und Anwendungserkennung ignorieren.
Policy-Simulation als Nachweis realer Weiterleitung verwenden.
Nur einen Clusterknoten prüfen.
Sitzungszähler ohne Zeitbezug auswerten.
Regelzähler vor der Beweissicherung zurücksetzen.
Alte und neue Sitzungen nicht unterscheiden.
Sitzungstabelle vollständig löschen.
UDP wie TCP diagnostizieren.
Bei zustandsloser ACL den Rückverkehr vergessen.
ICMP pauschal sperren.
Nur Echo-Anfragen als ICMP betrachten.
Pro Verbindungstest mehrere Variablen ändern.
Paketaufzeichnung ohne präzisen Filter starten.
Nur die Eingangsschnittstelle aufzeichnen.
Hardware-Offloading bei Captures ignorieren.
Firewall vorsorglich neu starten.
Allgemeine any any-Regel als Test erstellen.
Temporäre Freigaben oder Protokollierungen aktiv lassen.
Nur das Diagnosewerkzeug und nicht die ursprüngliche Anwendung testen.
Ursache und Präventionsmaßnahme nicht dokumentieren.

Verifikation

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

Client verwendet die erwartete Quelladresse;
Zieladresse entspricht dem Sollzustand;
Protokoll und Zielport sind korrekt;
der Datenfluss durchläuft die vorgesehene Firewall;
richtiger Clusterknoten und Kontext werden verwendet;
Eingangs- und Ausgangszone sind korrekt;
Routingentscheidung ist korrekt;
NAT verwendet die erwarteten Adressen und Ports;
die vorgesehene Sicherheitsregel trifft;
keine allgemeinere Regel überschattet sie;
Regelzähler steigt beim kontrollierten Test;
Firewallprotokoll enthält die erwartete Aktion;
keine nachgelagerte Sicherheitsprüfung blockiert;
Sitzung wird korrekt angelegt;
TCP-Handshake wird vollständig abgeschlossen;
UDP-Antwort wird der Sitzung zugeordnet;
benötigte ICMP-Fehlermeldungen werden transportiert;
Pakete und Bytes sind in beiden Richtungen plausibel;
Sitzungsendgrund ist erwartungsgemäß;
neue Verbindung funktioniert;
bestehende Verbindungen wurden nicht unbeabsichtigt beeinflusst;
IPv4 und IPv6 funktionieren, sofern erforderlich;
weitere repräsentative Quellen funktionieren;
weitere repräsentative Ziele funktionieren;
Hochverfügbarkeit und Synchronisation sind fehlerfrei;
Cloud-Sicherheitsgruppen und Subnetz-ACLs sind konsistent;
ursprüngliche Anwendung funktioniert;
temporäre Testregeln wurden entfernt;
temporäre Protokollierung wurde zurückgenommen;
Konfigurationsstand wurde gesichert;
Ursache, Änderung, Rückweg und Prävention wurden dokumentiert.

Eine erfolgreiche Policy-Simulation oder ein einzelner steigender Regelzähler ist keine ausreichende Gesamtverifikation.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Quelle:
<Hostname, IP-Adresse und Quellport>

Ziel:
<Hostname, IP-Adresse und Zielport>

Protokoll:
<TCP, UDP, ICMP oder anderes IP-Protokoll>

Erwarteter Pfad:
<Zonen, Router, Firewall und Zielnetz>

Tatsächlicher Pfad:
<nachgewiesener Pfad>

Firewall:
<Gerät, Cluster und aktiver Knoten>

Virtueller Kontext:
<Mandant, VSYS, VRF oder Security Context>

Eingang:
<Schnittstelle und Quellzone>

Ausgang:
<Schnittstelle und Zielzone>

Originaldatenfluss:
<Quell-IP:Port -> Ziel-IP:Port>

Übersetzter Datenfluss:
<NAT-Quell-IP:Port -> NAT-Ziel-IP:Port>

Routingentscheidung:
<Ausgangsschnittstelle und nächster Hop>

Erwartete Regel:
<Name und ID>

Tatsächlich passende Regel:
<Name, ID, Position und Aktion>

Sicherheitsprofile:
<IPS, URL, Malware, TLS oder andere Profile>

Sitzungs-ID:
<ID und Zustand>

Pakete und Bytes:
<je Richtung>

Sitzungsendgrund:
<Grund>

Protokollbefund:
<Logeintrag und Zeitstempel>

Paketaufzeichnung:
<Eingangs- und Ausgangsbefund>

Hypothese:
<vermutete Ursache>

Erwarteter Nachweis:
<messbarer Befund>

Gegenbeweis:
<Befund, der die Hypothese widerlegt>

Nachgewiesene Ursache:
<technischer Nachweis>

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

Risiko:
<mögliche Nebenwirkung>

Rückweg:
<Rollback>

Verifikation:
<identischer Test und Anwendungstest>

Prävention:
<Monitoring, Bereinigung oder Prozessverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Beispiel
Datenfluss dokumentieren	`192.0.2.100:53124 -> 198.51.100.25:443/TCP`
Cisco IOS ACLs anzeigen	`show ip access-lists`
Cisco IOS ACL-Bindung prüfen	`show ip interface`
ASA ACLs anzeigen	`show access-list`
ASA ACL-Bindung anzeigen	`show access-group`
ASA Sitzungen anzeigen	`show conn`
ASA Sitzung nach Adresse filtern	`show conn address 192.0.2.100`
ASA NAT-Zustand anzeigen	`show xlate`
ASA Route anzeigen	`show route`
ASA Datenfluss simulieren	`packet-tracer input inside tcp 192.0.2.100 53124 198.51.100.25 443 detailed`
ASA Drop-Zähler anzeigen	`show asp drop`
Juniper Policies anzeigen	`show security policies`
Juniper Policy-Treffer anzeigen	`show security policies hit-count`
Juniper Sitzungen anzeigen	`show security flow session`
Juniper Route prüfen	`show route 198.51.100.25`
Palo Alto Sitzung suchen	`show session all filter source 192.0.2.100 destination 198.51.100.25 destination-port 443`
Palo Alto Route prüfen	`test routing fib-lookup virtual-router <Routername> ip 198.51.100.25`
Linux nftables anzeigen	`sudo nft list ruleset`
Linux nftables mit Handles	`sudo nft -a list ruleset`
Linux Routing anzeigen	`ip route show`
Linux IPv6-Routing anzeigen	`ip -6 route show`
Linux Conntrack anzeigen	`sudo conntrack -L`

Befehle, die nicht als erste Diagnosemaßnahme verwendet werden dürfen:

clear conn
clear xlate
clear access-list counters
clear security flow session
clear session all
conntrack -F
nft flush ruleset
iptables -F
policy commit ohne geprüften Änderungsplan
Firewall deaktivieren
Cluster-Failover erzwingen
Firewalldienst neu starten
allgemeine any-any-Freigabe erstellen
Sicherheitsprofile global deaktivieren

Quellen

Grundlagen und Standards

Cisco

Juniper Networks

Palo Alto Networks

Amazon Web Services

Microsoft Azure

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

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:

Client sendet ein TCP-SYN.
Firewall A prüft die Sicherheitsregel.
Firewall A legt eine Sitzung an.
Server sendet SYN, ACK.
Routing leitet die Antwort über Firewall B.
Firewall B besitzt keine passende Sitzung.
Firewall B sieht ein Antwortpaket ohne bekannten Verbindungsaufbau.
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:

Zähler und Uhrzeit erfassen.
definierten Testzeitraum starten.
genau einen reproduzierbaren Test durchführen.
Zähler erneut erfassen.
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

Exakte Fehlermeldung dokumentieren.
Datum, Uhrzeit und Zeitzone erfassen.
Betroffene Anwendung bestimmen.
Quell- und Zielsystem bestimmen.
Quelladresse und Quellport erfassen.
Zieladresse und Zielport erfassen.
Protokoll bestimmen.
IPv4 und IPv6 unterscheiden.
Originalrichtung dokumentieren.
Antwortrichtung dokumentieren.
NAT vor und nach Übersetzung dokumentieren.
Fehlerumfang bestimmen.
Erwarteten Hinweg dokumentieren.
Erwarteten Rückweg dokumentieren.
Lokale Clientroute prüfen.
Lokale Serverroute prüfen.
Policy Routing auf beiden Endsystemen prüfen.
Routinginstanzen und VRFs berücksichtigen.
Tatsächlichen Hinweg nachweisen.
Tatsächlichen Rückweg unabhängig nachweisen.
Alle zustandsbehafteten Komponenten erfassen.
Aktive Firewall- und Clusterknoten bestimmen.
Sessiontabellen auf allen möglichen Knoten prüfen.
Sitzungs-ID dokumentieren.
Original- und Antwort-Tupel vergleichen.
TCP-, UDP- oder ICMP-Zustand auswerten.
[UNREPLIED], [ASSURED] oder vergleichbare Markierung prüfen.
Pakete und Bytes je Richtung vergleichen.
NAT-Sitzung und NAT-Besitzer prüfen.
Regel- und Drop-Protokolle korrelieren.
Cluster- und State-Synchronisation prüfen.
Zeitpunkt des letzten Failovers prüfen.
ECMP und Hash-Verfahren prüfen.
PBR und Source Routing prüfen.
dynamische Routen und spezifischere Präfixe prüfen.
Load Balancer und Direct Server Return berücksichtigen.
Cloud-Routingtabellen und Firewallendpunkte prüfen.
Conntrack-Auslastung erfassen.
Conntrack-Fehlerzähler erfassen.
Timeouts dokumentieren.
Hardware-Offloading berücksichtigen.
kontrollierten Verbindungstest durchführen.
bei Bedarf Conntrack-Ereignisse beobachten.
bei Bedarf Paketaufzeichnung an mehreren Punkten durchführen.
Hypothese und Gegenbeweis formulieren.
genau eine kontrollierte Maßnahme vorbereiten.
Risiko, Rückweg und Erfolgskriterium dokumentieren.
Maßnahme freigeben und umsetzen.
vollständig neue Sitzung aufbauen.
Hin- und Rückweg erneut prüfen.
Session- und NAT-Zustand erneut prüfen.
ursprüngliche Anwendung verifizieren.
weitere repräsentative Datenflüsse prüfen.
temporäre Aufzeichnungen und Diagnoseregeln zurücknehmen.
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

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.

9.7 Ephemeral Ports und Verbindungsgrenzen

Beim Aufbau einer ausgehenden TCP- oder UDP-Kommunikation benötigt das initiierende System normalerweise einen freien lokalen Quellport. Dieser kurzzeitig verwendete Port wird als dynamischer, temporärer oder ephemerer Port bezeichnet.

Beispiel:

Client:
192.0.2.100:53124

Server:
198.51.100.25:443

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

Der Server verwendet den bekannten Zielport 443. Der Client verwendet den dynamisch ausgewählten Quellport 53124.

Wenn kein geeigneter Quellport, Socket, Dateideskriptor, NAT-Eintrag oder Verbindungseintrag mehr verfügbar ist, können neue Verbindungen fehlschlagen, obwohl:

das Ziel erreichbar ist;
die Firewallregel stimmt;
der Serverdienst läuft;
bestehende Verbindungen weiterhin funktionieren;
Ping erfolgreich ist;
DNS korrekt auflöst.

Ziele

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

welcher dynamische Portbereich auf einem System tatsächlich gilt;
wie viele Ports dieses Bereichs belegt sind;
welcher Prozess besonders viele Verbindungen erzeugt;
ob TIME_WAIT, CLOSE_WAIT oder andere Zustände auffällig sind;
ob lokale Porterschöpfung oder SNAT-Porterschöpfung vorliegt;
ob ein NAT-Gateway, Load Balancer oder eine Firewall die Grenze erreicht;
ob statt Ports eine andere Verbindungsgrenze betroffen ist;
warum bestehende Sitzungen funktionieren, während neue Verbindungen scheitern;
wie Verbindungswiederverwendung und Connection Pooling die Last reduzieren;
wie eine Kapazitätsänderung sicher geplant und verifiziert wird.

Sicherheits- und Änderungsgrundsätze

Port- und Verbindungsgrenzen dürfen nicht ohne Ursachenanalyse verändert werden. Eine größere Grenze kann das Symptom verschieben, während die eigentliche Ursache bestehen bleibt.

Mögliche Ursachen sind:

fehlerhafte Anwendungsschleife;
fehlende Verbindungswiederverwendung;
nicht geschlossene Sockets;
ungewöhnlich hohe Verbindungsrate;
langsames oder nicht antwortendes Ziel;
zu großer Retry-Sturm;
Portscan;
Schadsoftware;
DDoS;
ungeeignete NAT-Architektur;
fehlerhafte Timeouts;
fehlende Kapazitätsplanung.

Nicht als erste Diagnosemaßnahme geeignet sind:

Server vorsorglich neu starten;
NAT-Gateway neu erstellen;
Firewall-Sitzungstabelle vollständig löschen;
Conntrack-Tabelle leeren;
dynamischen Portbereich ungeprüft erweitern;
TIME_WAIT-Dauer ungeprüft verkürzen;
Socket- oder Dateideskriptorgrenzen maximal erhöhen;
Verbindungsbegrenzungen deaktivieren;
mehrere öffentliche IP-Adressen ohne Kapazitätsnachweis ergänzen;
alle Anwendungspools neu starten;
Keepalive- oder Timeoutwerte pauschal verändern;
Sicherheitssoftware deaktivieren.

Vor jeder Änderung sind zu dokumentieren:

Ausgangszustand;
aktueller Portbereich;
Anzahl belegter Ports;
Verbindungszustände;
betroffene Prozesse;
häufigste Ziele;
Verbindungsrate;
NAT- oder SNAT-Auslastung;
weitere Ressourcenlimits;
Risiko;
Rückweg;
Erfolgskriterium;
Testverfahren.

Portnummernbereiche

IANA unterscheidet folgende Bereiche:

Bereich	Bezeichnung	Typische Verwendung
`0–1023`	System Ports	bekannte und besonders geschützte Dienste
`1024–49151`	User Ports	registrierte Anwendungsdienste
`49152–65535`	Dynamic/Private Ports	dynamische oder private Verwendung

Der IANA-Bereich 49152–65535 ist eine allgemeine Einteilung. Er beweist nicht, dass ein Betriebssystem lokal genau diesen Bereich verwendet.

Der tatsächlich verwendete Bereich kann abhängen von:

Betriebssystem;
Betriebssystemversion;
TCP oder UDP;
IPv4 oder IPv6;
Netzwerknamespace;
Anwendung;
expliziter Socketbindung;
Systemrichtlinie;
Containerplattform;
Cloudplattform;
NAT-Gerät;
benutzerdefinierter Konfiguration.

Deshalb muss der aktuelle Bereich auf dem betroffenen System ausgelesen werden.

Ephemeren Quellport und Serverport unterscheiden

Normale Clientverbindung:

192.0.2.100:53124 -> 198.51.100.25:443/TCP

Port	Rolle
`53124`	dynamischer Quellport des Clients
`443`	Zielport des Serverdienstes

Rückverkehr:

198.51.100.25:443 -> 192.0.2.100:53124/TCP

Der Server benötigt nicht für jeden eingehenden Client einen neuen lokalen Listenerport. Alle HTTPS-Verbindungen können lokal den Serverport 443 verwenden, weil die vollständigen Verbindungen durch unterschiedliche Adressen und Ports unterscheidbar bleiben.

Das Verbindungstupel

Eine TCP- oder UDP-Kommunikation wird typischerweise über folgende Merkmale unterschieden:

Quelladresse
Quellport
Zieladresse
Zielport
Protokoll

Beispiel:

192.0.2.100:53124 -> 198.51.100.25:443/TCP

Eine gleichzeitig bestehende Verbindung kann denselben lokalen Port möglicherweise gegenüber einem anderen Ziel verwenden:

192.0.2.100:53124 -> 203.0.113.80:443/TCP

Ob und wie ein Betriebssystem lokale Ports zwischen verschiedenen Zielen wiederverwendet, hängt von Implementierung, Bindungsart und Socketoptionen ab.

Deshalb gilt nicht allgemein:

Anzahl dynamischer Ports =
maximale Gesamtzahl aller ausgehenden Verbindungen

Die Grenze muss immer im Zusammenhang mit Quelladresse, Zieladresse, Zielport, Protokoll, NAT und Verbindungszustand bewertet werden.

Anzahl eines Portbereichs berechnen

Allgemeine Berechnung:

Anzahl =
Endport - Startport + 1

Beispiel:

Startport:
49152

Endport:
65535

Anzahl:
65535 - 49152 + 1
= 16384 Ports

Davon können abzuziehen sein:

reservierte Ports;
bereits gebundene Ports;
Ports in aktiven Verbindungen;
noch nicht wiederverwendbare Verbindungstupel;
Ports in TIME_WAIT;
anwendungsspezifische Ausschlüsse;
System- oder Plattformreservierungen;
Sicherheitsrichtlinien;
NAT- oder Providerbeschränkungen.

Die theoretische Anzahl ist deshalb keine garantierte Verbindungskapazität.

TCP und UDP getrennt betrachten

TCP und UDP besitzen getrennte Protokollräume. Derselbe numerische Port kann gleichzeitig für TCP und UDP verwendet werden.

Beispiel:

TCP 53124
UDP 53124

Das sind zwei unterschiedliche Transportendpunkte.

Zu prüfen sind daher getrennt:

dynamischer TCP-Portbereich;
dynamischer UDP-Portbereich;
TCP-Verbindungen;
UDP-Endpunkte;
TCP-Time-Wait-Zustände;
UDP-Tracking- und NAT-Timeouts;
protokollspezifische Cloudlimits.

Eine funktionierende UDP-Verbindung beweist nicht, dass noch TCP-Ports verfügbar sind.

IPv4 und IPv6 getrennt prüfen

Betriebssysteme und Plattformen können Portbereiche oder Zustände für IPv4 und IPv6 getrennt verwalten.

Zu prüfen sind:

verwendete Adressfamilie;
IPv4-Portbereich;
IPv6-Portbereich;
Dual-Stack-Verhalten;
Happy-Eyeballs-Verbindungen;
getrennte Firewallregeln;
getrennte NAT- oder SNAT-Pfade;
IPv4-mapped IPv6 Sockets;
Anwendung mit mehreren parallelen Verbindungsversuchen.

Eine Anwendung kann bei einem Namensaufruf mehrere IPv6- und IPv4-Verbindungen starten. Dadurch kann die Zahl der Verbindungsversuche höher sein als die Zahl sichtbarer Benutzeranfragen.

Lokale und übersetzte Ports unterscheiden

Ein NAT- oder SNAT-Gerät kann den lokalen Quellport verändern.

Beispiel:

Vor SNAT:
10.10.20.25:53124 -> 203.0.113.80:443

Nach SNAT:
198.51.100.5:61001 -> 203.0.113.80:443

Dabei existieren zwei unterschiedliche Portbetrachtungen:

Ebene	Port
lokaler Clientport	`53124`
externer SNAT-Port	`61001`

Der Client kann lokal noch Ports besitzen, während der SNAT-Portpool des Gateways erschöpft ist. Umgekehrt kann das NAT-Gateway noch Kapazität besitzen, während das lokale Betriebssystem keinen geeigneten Quellport mehr findet.

Lokale Porterschöpfung

Lokale Porterschöpfung liegt vor, wenn ein System für eine neue ausgehende Kommunikation keinen geeigneten lokalen Port beziehungsweise kein verwendbares lokales Verbindungstupel mehr zuweisen kann.

Typische Symptome:

neue ausgehende TCP-Verbindungen schlagen fehl;
bestehende TCP-Verbindungen funktionieren weiter;
Fehler tritt nach längerer Laufzeit auf;
Neustart behebt das Problem nur vorübergehend;
viele Verbindungen besitzen denselben Prozess;
viele Einträge befinden sich in TIME_WAIT;
sehr viele Einträge befinden sich in CLOSE_WAIT;
hohe Anzahl von Verbindungen zu demselben Ziel;
DNS, Kerberos, RPC, Datenbank- oder API-Aufrufe scheitern gleichzeitig;
eingehende Verbindungen können teilweise weiter funktionieren;
Fehler verschwindet, sobald Verbindungen aus der Tabelle altern.

Mögliche Fehlermeldungen sind abhängig von Betriebssystem und Anwendung:

Cannot assign requested address
Address already in use
No buffer space available
Too many open files
Only one usage of each socket address is normally permitted
Connection timed out
Connection failed

Diese Meldungen sind nicht gleichbedeutend. Beispielsweise kann Address already in use auch auf eine einzelne explizite Portkollision hinweisen.

SNAT-Porterschöpfung

Bei SNAT teilen sich mehrere interne Systeme eine oder mehrere externe IP-Adressen.

Beispiel:

10.10.20.11 -> 198.51.100.5
10.10.20.12 -> 198.51.100.5
10.10.20.13 -> 198.51.100.5

Das NAT-Gateway muss die Verbindungen über externe Quellports eindeutig zuordnen.

Eine hohe Konzentration auf dasselbe Ziel kann besonders kritisch sein:

viele interne Systeme
        ->
eine öffentliche NAT-Adresse
        ->
eine Zieladresse
        ->
ein Zielport

Beispiel:

1000 interne Anwendungsinstanzen
        ->
198.51.100.5
        ->
203.0.113.80:443

Mögliche Symptome:

nur ausgehende Verbindungen über das NAT-Gateway scheitern;
interne Ziele funktionieren;
bestehende Verbindungen funktionieren;
neue Verbindungen zu einem häufig genutzten Ziel schlagen fehl;
Verbindungen zu anderen Zieladressen funktionieren;
Fehler tritt nur unter Last auf;
Cloudmetrik zeigt Port Allocation Errors;
zusätzliche NAT-IP verbessert das Verhalten;
Connection Pooling reduziert die Fehler.

Porterschöpfung pro Ziel einordnen

Der kritische Grenzfall ist häufig nicht die Gesamtzahl aller Ziele, sondern eine hohe Zahl gleichzeitiger oder schnell wiederholter Verbindungen zu genau derselben Kombination aus:

Ziel-IP-Adresse
Zielport
Protokoll

Beispiel:

203.0.113.80:443/TCP

Ein API-Gateway, Datenbankserver, Proxy oder zentrales Authentifizierungssystem kann dadurch einen besonders konzentrierten Portbedarf erzeugen.

Zu prüfen sind:

Anzahl unterschiedlicher Zieladressen;
Anzahl unterschiedlicher Zielports;
Verbindungen je Ziel;
neue Verbindungen pro Sekunde;
durchschnittliche Lebensdauer;
Anteil wiederverwendeter Verbindungen;
Retryrate;
Timeoutdauer;
DNS-Lastverteilung;
NAT-IP-Adressen;
Backend- oder Zielverteilung.

TIME_WAIT

Nach dem regulären Ende einer TCP-Verbindung kann das System das Verbindungstupel für eine bestimmte Zeit im Zustand TIME_WAIT halten.

Zweck ist unter anderem:

verspätete Segmente einer alten Verbindung abzufangen;
eine neue gleichartige Verbindung nicht mit alten Paketen zu vermischen;
den abschließenden Verbindungsabbau zuverlässig behandeln zu können.

Viele TIME_WAIT-Einträge sind nicht automatisch ein Fehler. Sie zeigen jedoch eine hohe Rate kurzlebiger TCP-Verbindungen.

Kritisch wird die Situation, wenn gleichzeitig:

neue ausgehende Verbindungen scheitern;
der dynamische Portbereich stark belegt ist;
Windows-Ereignisse auf Porterschöpfung hinweisen;
ein einzelner Prozess besonders viele Verbindungen erzeugt;
ein einzelnes Ziel stark konzentriert ist;
die Einträge schneller entstehen als sie freigegeben werden.

Ein hoher TIME_WAIT-Bestand ohne Verbindungsfehler beweist keine aktuelle Porterschöpfung.

CLOSE_WAIT

CLOSE_WAIT bedeutet vereinfacht:

Die Gegenstelle hat das Ende der Verbindung angekündigt.
Das lokale Betriebssystem hat dies an die Anwendung gemeldet.
Die lokale Anwendung hat ihren Socket noch nicht vollständig geschlossen.

Viele dauerhaft bestehende CLOSE_WAIT-Einträge können auf eine Anwendung hinweisen, die Verbindungen nicht korrekt schließt.

Zu prüfen sind:

betroffener Prozess;
Alter der Verbindungen;
Wachstum über die Zeit;
Remoteziele;
Anwendungsprotokolle;
Thread- oder Taskzustand;
Fehlerbehandlung;
Connection Pool;
Dateideskriptorverbrauch.

CLOSE_WAIT beweist nicht automatisch eine erschöpfte dynamische Portmenge. Es kann jedoch gleichzeitig Sockets, Dateideskriptoren, Speicher und lokale Verbindungstupel binden.

SYN_SENT

Viele Verbindungen im Zustand SYN_SENT bedeuten, dass das lokale System Verbindungsanfragen gesendet hat, aber der TCP-Handshake noch nicht abgeschlossen wurde.

Mögliche Ursachen:

Ziel antwortet nicht;
Firewall verwirft;
Rückroute fehlt;
Ziel ist überlastet;
falsche Zieladresse;
Paketverlust;
zu lange Anwendungstimeouts;
Retry-Sturm;
SYN-Pakete werden schneller erzeugt als sie ablaufen.

Viele lang anhaltende SYN_SENT-Verbindungen können Ports und Sockets binden, obwohl keine erfolgreiche Anwendungskommunikation entsteht.

ESTABLISHED

Viele ESTABLISHED-Verbindungen können beabsichtigt sein, beispielsweise bei:

Datenbank-Connection-Pools;
HTTP-Keepalive;
HTTP/2;
WebSockets;
Message Brokern;
Streaming;
Replikation;
persistenten Agentenverbindungen.

Zu prüfen sind:

sind die Verbindungen aktiv oder ungenutzt?
entspricht die Anzahl der Konfiguration?
werden alte Verbindungen ersetzt, ohne geschlossen zu werden?
existiert eine obere Poolgrenze?
besitzt jede Anwendungsinstanz einen eigenen Pool?
wächst die Zahl dauerhaft?
passt die Summe aller Instanzpools zur Zielkapazität?

Eine hohe Zahl etablierter Verbindungen ist nicht automatisch Porterschöpfung. Sie kann jedoch andere Grenzwerte erreichen.

FIN_WAIT und LAST_ACK

Viele Verbindungen in Zuständen des Verbindungsabbaus können auf Probleme beim sauberen Beenden hinweisen.

Zu prüfen sind:

antwortet die Gegenstelle auf den Verbindungsabbau?
besitzt die Anwendung geeignete Schließ- und Abbruchlogik?
blockiert eine Firewall abschließende Pakete?
existiert ein asymmetrischer Rückweg?
werden Verbindungen durch Timeouts statt kontrolliert beendet?
treten Paketverluste auf?
ist das Ziel überlastet?

Die genaue Bedeutung ist anhand der TCP-Zustandsfolge und einer Paketaufzeichnung zu prüfen.

UDP und QUIC

UDP besitzt keinen TCP-Verbindungsabbau und keinen TCP-TIME_WAIT-Zustand. Trotzdem können UDP-Sockets, NAT-Zuordnungen und Connection-Tracking-Einträge Ports belegen.

Betroffene Anwendungen können sein:

DNS;
VoIP;
Streaming;
QUIC und HTTP/3;
VPN;
Telemetrie;
Gaming;
Monitoring.

Zu prüfen sind:

lokale UDP-Endpunkte;
NAT-Timeout;
Conntrack-Timeout;
Portwiederverwendung;
Antwortverkehr;
QUIC-Verbindungsrate;
Anzahl externer Ziele;
Firewallzustand;
anwendungsspezifische Socketverwaltung.

Eine Analyse ausschließlich der TCP-Verbindungen übersieht UDP- oder QUIC-bedingte Engpässe.

RPC-Dynamik nicht mit Clientports verwechseln

Windows RPC kann nach dem Kontakt zum RPC Endpoint Mapper auf TCP-Port 135 einen dynamischen Serverport verwenden.

Vereinfachter Ablauf:

Client kontaktiert Ziel auf TCP 135.
Endpoint Mapper nennt den dynamischen Serverport.
Client verbindet sich mit diesem Zielport.
Der Client verwendet dafür zusätzlich einen eigenen dynamischen Quellport.

Beispiel:

Client:
192.0.2.100:53124

RPC-Server:
198.51.100.25:52044

Verbindung:
192.0.2.100:53124 -> 198.51.100.25:52044/TCP

Dabei sind beide Ports dynamisch, aber mit unterschiedlichen Rollen:

Port	Rolle
`53124`	dynamischer Clientquellport
`52044`	dynamisch zugewiesener RPC-Serverzielport

Firewallregeln müssen diese Rollen korrekt berücksichtigen.

Porterschöpfung und andere Verbindungsgrenzen unterscheiden

Grenze	Typischer Befund
dynamischer lokaler Portbereich	kein geeigneter Quellport für neue Verbindung
SNAT-Portpool	NAT-Gerät kann keine neue Übersetzung anlegen
Socketgrenze	Anwendung oder Kernel kann keinen weiteren Socket anlegen
Dateideskriptorgrenze	Prozess erhält beispielsweise `Too many open files`
Prozesshandlegrenze	Betriebssystem oder Prozess erreicht Handlegrenze
Conntrack-Tabelle	Firewall oder Router kann keinen neuen Zustand anlegen
Firewall-Sessionlimit	neue Sitzungen werden verworfen
NAT-Sessionlimit	neue NAT-Zuordnungen schlagen fehl
TCP-SYN-Backlog	neue Handshakes warten oder werden verworfen
Accept-Backlog	vollständig aufgebaute Verbindungen werden nicht schnell genug angenommen
Anwendungslimit	Dienst erlaubt nur definierte Zahl paralleler Verbindungen
Connection-Pool-Limit	Anwendung wartet auf freien Poolplatz
Thread- oder Workerlimit	Verbindungen werden nicht rechtzeitig verarbeitet
Datenbanklimit	maximale Datenbanksitzungen erreicht
Load-Balancer-Limit	Flow-, Port- oder Zielgrenze erreicht
Cloudquote	plattformspezifische Obergrenze erreicht
Zielsystemlimit	Gegenstelle begrenzt Quellen oder Verbindungsrate
API-Rate-Limit	Anwendung lehnt Anfragen trotz funktionierender TCP-Verbindung ab

Ein erfolgreicher TCP-Porttest beweist nicht, dass die Anwendung noch einen Datenbankpoolplatz oder Worker besitzt.

Windows: dynamischen Portbereich anzeigen

IPv4 TCP:

netsh int ipv4 show dynamicport tcp

IPv4 UDP:

netsh int ipv4 show dynamicport udp

IPv6 TCP:

netsh int ipv6 show dynamicport tcp

IPv6 UDP:

netsh int ipv6 show dynamicport udp

Bei aktuellen unterstützten Windows-Versionen ist der Standardbereich normalerweise:

Startport:
49152

Endport:
65535

Anzahl:
16384

Der tatsächliche Systemwert ist trotzdem mit netsh zu prüfen. TCP, UDP, IPv4 und IPv6 werden getrennt angezeigt.

Windows: TCP-Verbindungen anzeigen

Alle TCP-Verbindungen:

Get-NetTCPConnection

Etablierte Verbindungen:

Get-NetTCPConnection `
  -State Established

TIME_WAIT:

Get-NetTCPConnection `
  -State TimeWait

CLOSE_WAIT:

Get-NetTCPConnection `
  -State CloseWait

Ausgehende Verbindungsversuche:

Get-NetTCPConnection `
  -State SynSent

Nach Ziel filtern:

Get-NetTCPConnection `
  -RemoteAddress "198.51.100.25" `
  -RemotePort 443

Nach Prozess-ID filtern:

Get-NetTCPConnection `
  -OwningProcess <PID>

Prozess bestimmen:

Get-Process `
  -Id <PID>

Windows: Zustände zählen

Get-NetTCPConnection |
  Group-Object State |
  Sort-Object Count -Descending |
  Select-Object Count, Name

Mögliche Ausgabe:

Count Name
----- ----
 8200 TimeWait
 1450 Established
  200 CloseWait
   35 SynSent

Die Werte müssen mit einer Baseline und dem aktuellen Fehlerzeitpunkt verglichen werden.

Windows: Verbindungen je Prozess zählen

Get-NetTCPConnection |
  Group-Object OwningProcess |
  Sort-Object Count -Descending |
  Select-Object -First 20 Count, Name

Die Spalte Name enthält in diesem Fall die Prozess-ID.

Einzelne Prozess-IDs auflösen:

Get-Process `
  -Id <PID>

Ausführlicher Zusammenhang:

Get-NetTCPConnection |
  ForEach-Object {
    $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue

    [PSCustomObject]@{
      State         = $_.State
      LocalAddress  = $_.LocalAddress
      LocalPort     = $_.LocalPort
      RemoteAddress = $_.RemoteAddress
      RemotePort    = $_.RemotePort
      PID           = $_.OwningProcess
      Process       = $process.ProcessName
    }
  } |
  Sort-Object Process, State

Auf stark belasteten Systemen kann diese Auswertung umfangreich sein. Sie sollte gezielt und während des Fehlerzeitraums durchgeführt werden.

Windows: häufigste Ziele ermitteln

Get-NetTCPConnection |
  Where-Object State -ne Listen |
  Group-Object RemoteAddress, RemotePort |
  Sort-Object Count -Descending |
  Select-Object -First 20 Count, Name

Damit kann festgestellt werden, ob sich sehr viele Verbindungen auf ein einzelnes Ziel konzentrieren.

Windows: klassische Netstat-Auswertung

Verbindungen, Ports und Prozess-IDs:

netstat -ano

Mit ausführbarer Datei, administrative Eingabeaufforderung erforderlich:

netstat -anob

Gebundene Ports einschließlich bestimmter nicht aktiver TCP-Bindungen:

netstat -anoq

TIME_WAIT zählen:

netstat -ano | find /c "TIME_WAIT"

CLOSE_WAIT zählen:

netstat -ano | find /c "CLOSE_WAIT"

SYN_SENT zählen:

netstat -ano | find /c "SYN_SENT"

Ein einfacher Textzähler ist nur ein Indikator. Für die Zuordnung zu Prozess, Ziel, Zeit und Portbereich ist die vollständige Ausgabe erforderlich.

Windows: Ereignisse prüfen

Windows kann bei Porterschöpfung unter anderem TCP/IP-Ereignisse 4227 und 4231 protokollieren.

Gezielte Suche:

Get-WinEvent `
  -FilterHashtable @{
    LogName   = "System"
    Id        = 4227, 4231
    StartTime = (Get-Date).AddHours(-24)
  } |
  Select-Object TimeCreated, Id, ProviderName, Message

Die Ereignisse müssen zeitlich mit den tatsächlichen Verbindungsfehlern korreliert werden.

Ein hoher TIME_WAIT-Bestand allein bestätigt keine Porterschöpfung. Microsoft empfiehlt zusätzlich, reale ausgehende Verbindungsfehler und passende Ereignisse nachzuweisen.

Windows: Portbereich eines Tests berücksichtigen

Wenn der ausgelesene TCP-Bereich beispielsweise 49152–65535 lautet:

$startPort = 49152
$endPort   = 65535

Get-NetTCPConnection |
  Where-Object {
    $_.LocalPort -ge $startPort -and
    $_.LocalPort -le $endPort
  } |
  Group-Object State |
  Sort-Object Count -Descending |
  Select-Object Count, Name

Die Werte müssen an den tatsächlich mit netsh ermittelten Bereich angepasst werden.

Linux: lokalen Portbereich anzeigen

sysctl net.ipv4.ip_local_port_range

Alternative:

cat /proc/sys/net/ipv4/ip_local_port_range

Beispielausgabe:

32768 60999

Das ist nur ein Beispiel. Die lokale Ausgabe ist maßgeblich.

Reservierte lokale Ports:

sysctl net.ipv4.ip_local_reserved_ports

Alternative:

cat /proc/sys/net/ipv4/ip_local_reserved_ports

ip_local_port_range und ip_local_reserved_ports sind getrennte Einstellungen. Beide beeinflussen, welche Ports für automatische Zuweisungen zur Verfügung stehen.

Linux: Socketübersicht

ss -s

Mögliche Bereiche der Zusammenfassung:

Gesamtzahl der Sockets;
TCP-Sockets;
etablierte Verbindungen;
geschlossene Zustände;
TIME_WAIT;
UDP-Sockets;
RAW-Sockets;
fragmentierte Zustände.

Die genaue Darstellung hängt von der installierten iproute2-Version ab.

Linux: TCP-Verbindungen anzeigen

Alle TCP-Sockets:

ss -tan

Mit Prozessinformationen:

sudo ss -tanp

Etablierte Verbindungen:

ss -tan state established

TIME_WAIT:

ss -tan state time-wait

CLOSE_WAIT:

ss -tan state close-wait

SYN_SENT:

ss -tan state syn-sent

Listener:

ss -lntp

Nach Ziel filtern:

ss -tanp \
  dst 198.51.100.25:443

Linux: Zustände zählen

ss -Htan |
  awk '{print $1}' |
  sort |
  uniq -c |
  sort -nr

Nur TIME_WAIT zählen:

ss -Htan state time-wait |
  wc -l

Nur CLOSE_WAIT zählen:

ss -Htan state close-wait |
  wc -l

Nur SYN_SENT zählen:

ss -Htan state syn-sent |
  wc -l

Linux: Kernel-Socketstatistik

IPv4 und allgemeine Socketstatistik:

cat /proc/net/sockstat

IPv6:

cat /proc/net/sockstat6

Mögliche Felder sind unter anderem:

verwendete Sockets;
TCP in use;
orphaned;
TIME_WAIT;
zugewiesener Speicher;
UDP in use;
RAW in use;
fragmentierte Pakete.

Die Werte sind Momentaufnahmen und müssen mit einer Baseline verglichen werden.

Linux: Dateideskriptorgrenzen

Grenze der aktuellen Shell:

ulimit -n

Grenzen eines laufenden Prozesses:

cat /proc/<PID>/limits

Offene Dateideskriptoren eines Prozesses zählen:

ls -1 /proc/<PID>/fd |
  wc -l

Systemweite Dateideskriptorinformationen:

cat /proc/sys/fs/file-nr

Systemweite Obergrenze:

sysctl fs.file-max

Sockets werden unter Unix-ähnlichen Betriebssystemen über Dateideskriptoren angesprochen. Ein Prozess kann deshalb die Dateideskriptorgrenze erreichen, obwohl im dynamischen Portbereich noch Ports frei sind.

Linux: Listener- und Backloggrenzen

Aktuelle Listener:

ss -lnt

Globale Obergrenze des Listen-Backlogs:

sysctl net.core.somaxconn

TCP-SYN-Backlog:

sysctl net.ipv4.tcp_max_syn_backlog

Bei einem Listening Socket zeigt ss abhängig von Version und Kontext unter anderem aktuelle und maximale Warteschlangenwerte an.

Ein Backlogproblem betrifft eingehende Verbindungen und ist nicht mit ausgehender Porterschöpfung gleichzusetzen.

Linux: Conntrack zusätzlich prüfen

Anzahl aktuell verfolgter Verbindungen:

sysctl net.netfilter.nf_conntrack_count

Maximalwert:

sysctl net.netfilter.nf_conntrack_max

Statistiken, sofern conntrack-tools installiert ist:

sudo conntrack -S

Eine volle Conntrack-Tabelle kann neue Verbindungen verhindern, obwohl das lokale Betriebssystem noch Quellports besitzt.

macOS: Portbereich prüfen

Verfügbare Portbereichsparameter anzeigen:

sysctl -a |
  awk '/net\.inet\.ip\.portrange/'

Je nach macOS-Version können unter anderem folgende Werte verfügbar sein:

sysctl net.inet.ip.portrange.first

sysctl net.inet.ip.portrange.last

sysctl net.inet.ip.portrange.hifirst

sysctl net.inet.ip.portrange.hilast

Die tatsächlich vorhandenen Parameter und Werte sind auf dem betroffenen Mac zu prüfen.

macOS: Verbindungen und Prozesse prüfen

TCP-Verbindungen:

netstat -anv -p tcp

TCP-Sockets mit Prozessen:

sudo lsof -nP -iTCP

Nur etablierte TCP-Verbindungen:

sudo lsof -nP -iTCP -sTCP:ESTABLISHED

Nur Listener:

sudo lsof -nP -iTCP -sTCP:LISTEN

TCP-Statistik:

netstat -s -p tcp

Interaktive Netzwerksicht:

nettop -m tcp

Die genaue Ausgabe unterscheidet sich je nach macOS-Version.

Prozess statt nur Portbereich untersuchen

Die wichtigste Frage lautet häufig:

Welcher Prozess erzeugt die Verbindungen?

Zu dokumentieren sind:

Prozessname;
Prozess-ID;
Dienst;
ausführbare Datei;
Benutzerkonto;
Startzeit;
Anzahl TCP-Verbindungen;
Anzahl UDP-Sockets;
Zustandsverteilung;
häufigste Ziele;
neue Verbindungen pro Sekunde;
Retryrate;
Fehlerprotokolle;
Connection-Pool-Konfiguration;
zuletzt durchgeführte Änderung.

Ein Portbereich sollte nicht erweitert werden, bevor der verursachende Prozess und sein Verbindungsverhalten bekannt sind.

Verbindungsrate und gleichzeitige Verbindungen unterscheiden

Metrik	Bedeutung
gleichzeitige Verbindungen	aktuell parallel bestehende Datenflüsse
neue Verbindungen pro Sekunde	Geschwindigkeit des Verbindungsaufbaus
geschlossene Verbindungen pro Sekunde	Geschwindigkeit des Abbaus
`TIME_WAIT`-Bestand	noch nicht vollständig wiederverwendbare TCP-Zustände
durchschnittliche Lebensdauer	Zeit bis zum Verbindungsende
Retryrate	zusätzliche Versuche nach Fehler oder Timeout
Wiederverwendungsquote	Anfragen pro bestehender Verbindung

Eine Anwendung mit nur wenigen gleichzeitig aktiven Anfragen kann trotzdem sehr viele Ports verbrauchen, wenn sie für jede Anfrage eine neue Verbindung erstellt.

Planungsnäherung für kurzlebige Verbindungen

Vereinfachte Abschätzung:

dauerhaft mögliche neue Verbindungen pro Sekunde
≈
verfügbare Portkombinationen / Belegungsdauer

Beispiel:

verfügbare Ports:
16384

angenommene Belegungsdauer:
240 Sekunden

Näherung:
16384 / 240
≈ 68 neue Verbindungen pro Sekunde

Diese Rechnung ist nur ein vereinfachtes Planungsmodell für eine konzentrierte Zielkombination. Das reale Verhalten hängt unter anderem ab von:

Betriebssystem;
Portauswahl;
Portwiederverwendung;
Zieladressen;
Zielports;
Quelladressen;
NAT;
TCP-Zustand;
Socketoptionen;
Sicherheitsrichtlinien;
Plattformlimits.

Die Näherung darf nicht als garantierter Grenzwert verwendet werden.

Connection Pooling

Connection Pooling hält eine begrenzte Menge bestehender Verbindungen bereit und verwendet sie für mehrere Vorgänge erneut.

Mögliche Vorteile:

weniger TCP-Handshakes;
weniger TLS-Handshakes;
geringere Verbindungsrate;
weniger TIME_WAIT;
geringerer Portverbrauch;
geringere CPU-Last;
geringere Latenz;
weniger Last auf NAT und Firewall.

Zu prüfen sind:

minimale Poolgröße;
maximale Poolgröße;
Pool pro Prozess;
Pool pro Instanz;
Pool pro Benutzer;
Pool pro Ziel;
Idle-Timeout;
maximale Lebensdauer;
Health Check;
Validierung vor Wiederverwendung;
Verhalten bei Zielausfall;
Retrylogik;
Schließen beim Anwendungsende.

Ein unbegrenzt großer Pool beseitigt keine Kapazitätsgrenzen und kann das Zielsystem überlasten.

HTTP-Verbindungen wiederverwenden

Für HTTP-basierte Anwendungen sind relevant:

HTTP/1.1 Keep-Alive;
HTTP/2-Multiplexing;
HTTP/3 über QUIC;
Proxyverbindungen;
maximale parallele Verbindungen pro Ziel;
DNS-Änderungen;
TLS-Sitzungswiederverwendung;
Clientbibliothek;
Lebensdauer des HTTP-Clients.

Ein häufiges Fehlmuster ist die Erstellung eines neuen HTTP-Clients und einer neuen TCP-/TLS-Verbindung für jede einzelne Anfrage.

Besser ist eine kontrollierte Wiederverwendung mit:

begrenztem Pool;
korrekten Timeouts;
Fehlerbehandlung;
DNS-Aktualisierung;
Gesundheitsprüfung;
sauberem Schließen beim Anwendungsende.

Die konkrete Implementierung hängt von Programmiersprache, Framework und Bibliothek ab.

Retries kontrollieren

Ein langsames oder ausgefallenes Ziel kann einen Retry-Sturm auslösen.

Beispiel:

100 Anfragen
× 5 sofortige Wiederholungen
= 500 Verbindungsversuche

Bei mehreren Anwendungsinstanzen:

500 Versuche
× 20 Instanzen
= 10000 Verbindungsversuche

Zu prüfen sind:

maximale Anzahl von Wiederholungen;
Wartezeit;
exponentielles Backoff;
zufällige Streuung oder Jitter;
Circuit Breaker;
Gesamtzeitlimit;
Wiederholung nur idempotenter Operationen;
gemeinsames Ziel aller Instanzen;
Verhalten bei DNS- oder TLS-Fehlern.

Sofortige und unbegrenzte Retries können eine kleine Störung zu Port-, Socket- und Zielüberlastung verstärken.

AWS NAT Gateway

AWS dokumentiert für ein NAT Gateway pro zugeordneter IPv4-Adresse bis zu 55.000 gleichzeitige Verbindungen zu jedem eindeutigen Ziel.

Ein eindeutiges Ziel wird dabei bestimmt durch:

Ziel-IP-Adresse
Zielport
Protokoll

Zu prüfen sind:

NAT-Gateway-Typ;
zugeordnete IPv4-Adressen;
Anzahl Verbindungen je Ziel;
CloudWatch-Metriken;
Port Allocation Errors;
Verbindungsversuche;
Idle Timeouts;
Availability Zone;
Routing;
Zielkonzentration.

Mögliche relevante CloudWatch-Metriken sind abhängig vom Ressourcentyp unter anderem:

ActiveConnectionCount;
ConnectionAttemptCount;
ErrorPortAllocation;
IdleTimeoutCount;
PacketsDropCount.

Zusätzliche NAT-IP-Adressen können die Kapazität erhöhen. Vorher muss jedoch geprüft werden, ob die Anwendung unnötig viele neue Verbindungen erstellt.

Azure NAT Gateway

Azure NAT Gateway stellt pro öffentlicher IPv4-Adresse 64.512 SNAT-Ports bereit. Ein NAT Gateway kann mehrere öffentliche IP-Adressen verwenden.

Microsoft dokumentiert außerdem eine Grenze gleichzeitiger Verbindungen je eindeutigem Zielendpunkt. Die jeweils aktuelle Plattformdokumentation ist für die eingesetzte Ressource zu prüfen.

Zu prüfen sind:

Anzahl öffentlicher IP-Adressen;
zugeordnete Subnetze;
SNAT Connection Count;
Failed SNAT Connection Count;
Zieladresse und Zielport;
Verbindungsrate;
TCP- und UDP-Nutzung;
Idle Timeouts;
Load-Balancer-Outbound-Regeln;
Azure Firewall;
NAT-Gateway-Zuordnung.

TCP und UDP besitzen beim Azure NAT Gateway getrennte SNAT-Portinventare.

Azure Load Balancer

Ein Azure Load Balancer kann ausgehende SNAT-Ports nach konfigurierten Outbound Rules und Backendanzahl zuteilen.

Zu prüfen sind:

Load-Balancer-SKU;
Outbound Rule;
Anzahl Backendinstanzen;
zugewiesene SNAT-Ports je Instanz;
verwendete öffentliche IP-Adressen;
Idle Timeout;
Port-Reuse;
SNAT-Port-Metriken;
Port Allocation Failures;
NAT-Gateway-Zuordnung.

Eine ungleichmäßige Verbindungsverteilung kann dazu führen, dass eine einzelne Backendinstanz ihre Portzuteilung erreicht, obwohl andere Instanzen noch Kapazität besitzen.

Google Cloud NAT

Google Cloud NAT kann Ports statisch oder dynamisch auf VMs verteilen.

Zu prüfen sind:

NAT-IP-Adressen;
minimale Ports pro VM;
maximale Ports pro VM;
dynamische Portzuweisung;
Endpoint-Independent Mapping;
Portnutzung je VM;
verworfene Pakete;
Zielkonzentration;
VM- und Podanzahl;
Verbindungsrate;
Logging und Monitoring.

Bei dynamischer Portzuweisung kann eine schnelle Laststeigerung vorübergehend Pakete verlieren, während die Portzuweisung erweitert wird. Lasttests sollten deshalb auch den Anstieg der Verbindungsrate berücksichtigen.

Container und Kubernetes

Mehrere Container oder Pods können sich einen Host-, Node- oder NAT-Portpool teilen.

Zu prüfen sind:

Netzwerkmodus;
eigener oder gemeinsamer Network Namespace;
Node-IP;
Pod-IP;
Host-NAT;
kube-proxy;
CNI-Plugin;
eBPF-Datenpfad;
Cloud NAT;
Service Mesh;
Sidecar Proxy;
Zahl der Pods;
Poolgröße pro Pod;
Retryverhalten;
Rolling Deployment;
Horizontal Scaling.

Beispiel:

50 Pods
× 200 ausgehende Poolverbindungen
= 10000 Verbindungen

Ein Scale-out kann den Gesamtportbedarf erhöhen, obwohl jede einzelne Instanz unverändert arbeitet.

Proxies und Gateways

Forward Proxies, Reverse Proxies, API Gateways und Service-Mesh-Sidecars initiieren eigene ausgehende Verbindungen.

Dadurch existieren getrennte Verbindungsabschnitte:

Client -> Proxy
Proxy  -> Ziel

Zu prüfen sind für jeden Abschnitt:

Quelladresse;
Quellport;
Zieladresse;
Zielport;
Connection Pool;
maximale Verbindungen;
Idle Timeout;
Retrylogik;
NAT;
TLS-Terminierung;
Zahl der Worker;
Backendverteilung.

Der Client kann ausreichend Ports besitzen, während der Proxy seinen ausgehenden Portpool erschöpft.

Firewalls und Connection Tracking

Zusätzlich zum Quellport muss eine Stateful Firewall oder ein NAT-Router häufig einen Sitzungseintrag anlegen.

Zu prüfen sind:

aktuelle Sitzungsanzahl;
maximales Sitzungslimit;
Neuverbindungen pro Sekunde;
NAT-Übersetzungen;
Verbindungen je Quelle;
Verbindungen je Ziel;
halb offene Sitzungen;
UDP-Pseudositzungen;
Timeouts;
Drop-Zähler;
Tabellenfüllstand;
Cluster-Synchronisation.

Eine Portbereichserweiterung am Client kann die Firewall stärker belasten und dort die nächste Grenze erreichen.

Serverseitige Verbindungsgrenzen

Wenn eingehende Verbindungen scheitern, sind zusätzlich zu prüfen:

Listener vorhanden;
Listeneradresse;
Listenerport;
SYN-Backlog;
Accept-Backlog;
maximale Clients;
Workerzahl;
Threadzahl;
Prozessgrenze;
Dateideskriptorgrenze;
Datenbankpool;
Zielabhängigkeiten;
CPU;
Speicher;
Garbage Collection;
Lizenzgrenze;
Rate Limit;
Reverse Proxy;
Load Balancer.

Typische Unterscheidung:

Befund	Mögliche Einordnung
SYN erhält keine Antwort	Netzwerk, Firewall, Backlog oder Überlastung
SYN erhält RST	kein Listener oder aktive Ablehnung
TCP-Handshake erfolgreich, Anwendung wartet	Worker-, Pool- oder Backendproblem
bestehende Clients funktionieren, neue nicht	Backlog, Verbindungslimit oder Ressourcenerschöpfung
nur ausgehende Serveraufrufe scheitern	lokale Ports, NAT, Pool oder Zielproblem

Baseline erfassen

Eine Port- und Verbindungsdiagnose benötigt Vergleichswerte.

Sinnvolle Baseline:

dynamischer Portbereich
TCP-Verbindungen gesamt
UDP-Sockets gesamt
ESTABLISHED
TIME_WAIT
CLOSE_WAIT
SYN_SENT
LISTEN
Verbindungen je Prozess
Verbindungen je Ziel
neue Verbindungen pro Sekunde
Dateideskriptoren je Prozess
Conntrack-Auslastung
NAT-Sitzungen
SNAT-Portnutzung
Fehlerzähler
CPU und Speicher

Messpunkte:

Normalbetrieb;
Lastspitze;
unmittelbar vor der Störung;
während der Störung;
nach der Erholung;
nach einer kontrollierten Maßnahme.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der Anwendungsdienst erstellt für jeden API-Aufruf eine neue
HTTPS-Verbindung zum Ziel 203.0.113.80:443. Die Verbindungen
verbleiben anschließend in TIME_WAIT, bis der dynamische
TCP-Portbereich erschöpft ist.

Erwarteter Befund:
Während der Störung schlagen neue ausgehende Verbindungen fehl.
Windows protokolliert Ereignis 4227 oder 4231.
Die Anzahl der TIME_WAIT-Verbindungen zum Ziel
203.0.113.80:443 ist sehr hoch und gehört überwiegend zum
gleichen Prozess.

Gegenbeweis:
Der dynamische Portbereich besitzt während der Störung ausreichend
freie Kapazität, es existieren keine passenden TCP/IP-Ereignisse,
und der Verbindungsfehler tritt bereits vor der lokalen Portzuweisung
oder ausschließlich am Zielsystem auf.

Testmethode:
Portbereich, Get-NetTCPConnection, Prozesszuordnung,
Systemereignisse und eine kontrollierte Testverbindung zeitlich
korrelieren.

Risiko:
Nur lesende Diagnose.

Erfolgskriterium:
Portbelegung, verursachender Prozess, Zielkonzentration und
Verbindungsfehler sind für denselben Zeitpunkt nachgewiesen.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko	Rückweg
Connection Pooling aktivieren	hohe Rate kurzlebiger Verbindungen bestätigt	fehlerhafte Altverbindungen können wiederverwendet werden	vorherige Clientkonfiguration
HTTP-Verbindungen wiederverwenden	neue Verbindung pro Anfrage nachgewiesen	DNS- und Lebensdauerverhalten beachten	vorheriges Clientverhalten
Poolgröße begrenzen	unkontrolliert großer Pool bestätigt	Wartezeiten bei Last	vorherige Poolgröße
Retries begrenzen	Retry-Sturm nachgewiesen	einzelne Anfrage schlägt früher fehl	vorherige Retrykonfiguration
Backoff und Jitter ergänzen	gleichzeitige Wiederholungen vieler Instanzen	längere Wiederherstellungszeit	alte Retryrichtlinie
Anwendung korrigieren	nicht geschlossene Sockets bestätigt	Deploymentrisiko	vorherige Anwendungsversion
Portbereich erweitern	tatsächliche lokale Porterschöpfung bestätigt	Überschneidungen und höhere Folgelast	vorherigen Bereich wiederherstellen
zusätzliche Quell-IP verwenden	Kapazitätsbedarf und Architektur bestätigt	Routing, Firewall und Freigaben ändern sich	alte IP-Zuordnung
zusätzliche NAT-IP verwenden	SNAT-Erschöpfung bestätigt	Kosten und Ziel-Allowlisting	zusätzliche IP entfernen
NAT-Gateway skalieren	Plattformmetrik bestätigt Engpass	Kosten und Architekturänderung	vorherige Ressourcengröße
Timeouts anpassen	ungeeigneter Timeout nachgewiesen	veraltete Zustände oder höhere Last	alten Timeoutwert wiederherstellen
Dateideskriptorgrenze erhöhen	FD-Limit nachgewiesen und Speicher ausreichend	höherer Ressourcenverbrauch	alten Grenzwert wiederherstellen
Conntrack-Kapazität erhöhen	Tabellenlimit nachgewiesen	höherer Speicherverbrauch	alten Wert wiederherstellen
Serverpool skalieren	Zielkapazität nachgewiesen	zusätzliche Verbindungen und Kosten	Skalierung zurücknehmen

Die Ursachenbehebung in der Anwendung ist einer dauerhaften rein infrastrukturellen Vergrößerung vorzuziehen, wenn die Anwendung unnötig viele Verbindungen erzeugt.

Vollständiger Diagnoseablauf

Exakte Fehlermeldung erfassen.
Datum, Uhrzeit und Zeitzone dokumentieren.
Betroffene Anwendung bestimmen.
Ausgehende und eingehende Verbindungen unterscheiden.
Quell- und Zielsystem bestimmen.
Quelladresse und Zieladresse erfassen.
Quellport und Zielport erfassen.
TCP, UDP und QUIC unterscheiden.
IPv4 und IPv6 unterscheiden.
Umfang der Störung bestimmen.
Prüfen, ob bestehende Verbindungen weiter funktionieren.
Prüfen, ob nur neue Verbindungen scheitern.
Dynamischen Portbereich auslesen.
Reservierte und ausdrücklich gebundene Ports berücksichtigen.
Anzahl aktueller TCP-Verbindungen erfassen.
UDP-Sockets erfassen.
TCP-Zustände gruppieren.
TIME_WAIT auswerten.
CLOSE_WAIT auswerten.
SYN_SENT auswerten.
Verbindungen nach Prozess gruppieren.
Verbindungen nach Ziel gruppieren.
Verbindungsrate messen.
Retryrate bestimmen.
Connection-Pool-Konfiguration prüfen.
Dateideskriptoren und Handles prüfen.
Listener- und Backloggrenzen prüfen.
Anwendungs- und Workerlimits prüfen.
Conntrack-Auslastung prüfen.
Firewall- und NAT-Sitzungsgrenzen prüfen.
Vor-NAT- und Nach-NAT-Ports dokumentieren.
SNAT-Portnutzung prüfen.
Cloudmetriken und Port Allocation Errors prüfen.
Container-, Node- und Podkontext berücksichtigen.
Proxy- und Sidecar-Verbindungen getrennt prüfen.
Anwendungsprotokolle auswerten.
Betriebssystemereignisse auswerten.
kontrollierte Testverbindung durchführen.
bei Bedarf Paketaufzeichnung durchführen.
Hypothese und Gegenbeweis formulieren.
genau eine kontrollierte Maßnahme vorbereiten.
Risiko, Rückweg und Erfolgskriterium dokumentieren.
Maßnahme freigeben und umsetzen.
neue Verbindungen unter gleicher Last testen.
Portbelegung und Zustände erneut messen.
SNAT-, Conntrack- und Fehlerzähler erneut prüfen.
ursprüngliche Anwendung verifizieren.
Nebenwirkungen auf andere Dienste prüfen.
temporäre Diagnosemaßnahmen zurücknehmen.
Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
bestehende Verbindungen funktionieren, neue nicht	Port-, NAT-, Conntrack- oder Backloggrenze	jeweilige Auslastungszähler prüfen
viele `TIME_WAIT`	hohe Rate kurzlebiger TCP-Verbindungen	Prozess, Ziel und Verbindungsrate
viele `CLOSE_WAIT`	Anwendung schließt Sockets nicht	Prozess und Anwendungscode prüfen
viele `SYN_SENT`	Ziel antwortet nicht oder Rückweg fehlt	Paketaufzeichnung und Route
viele `ESTABLISHED`	Pool oder Langzeitverbindungen	Aktivität, Poolgrenze und Alter
Windows-Ereignis 4227	lokaler Endpunkt kann nicht sicher wiederverwendet werden	Portbestand und Prozesszuordnung
Windows-Ereignis 4231	Zuweisung eines ephemeren Ports fehlgeschlagen	dynamischen Bereich und Belegung prüfen
`Cannot assign requested address`	kein verwendbarer lokaler Endpunkt oder falsche Bindung	Ports, lokale IP und Anwendung
`Too many open files`	Dateideskriptorgrenze	Prozesslimits und offene FDs
lokale Ports frei, Cloudfehler bleibt	SNAT- oder Plattformgrenze	Cloudmetrik und NAT-Gateway
nur ein Ziel betroffen	Verbindungen pro Zielkombination erschöpft	Ziel-IP, Port und Protokoll gruppieren
andere Ziele funktionieren	zielbezogene NAT- oder Gegenstellenbegrenzung	Zielkonzentration und Plattformlimit
Neustart hilft nur vorübergehend	Zustände werden geleert, Ursache bleibt	Wachstum über die Zeit erfassen
zusätzliche NAT-IP hilft	SNAT-Kapazität wahrscheinlich betroffen	Port Allocation Error vor und nach Änderung
mehr Pods verschlechtern Fehler	Gesamtpool und Verbindungsrate steigen	Poolgröße × Podanzahl berechnen
nur Lastspitzen betroffen	Portzuweisung oder Rate überschritten	Verbindungen pro Sekunde messen
TCP funktioniert, UDP nicht	getrennte UDP-Port- oder NAT-Grenze	UDP-Sockets und NAT-Timeout
HTTP/1.1 problematisch, HTTP/2 besser	Multiplexing reduziert Verbindungen	Verbindungsrate vergleichen
Firewall-Sessions voll	Connection Tracking oder Sessionlimit	Firewallstatistik und Drops
Serverhandshake gelingt, Anfrage wartet	Worker-, Pool- oder Backendgrenze	Anwendungsmetriken
Listener-Queue wächst	Anwendung akzeptiert zu langsam	CPU, Worker und Backlog
Pool erschöpft, Ports frei	Anwendungslimit statt Portlimit	Poolwartezeit und Poolbelegung
viele Retries	Fehler verstärkt Verbindungslast	Backoff- und Retrykonfiguration
Portbereich angepasst, Fehler wandert zur Firewall	nachgelagerte Grenze erreicht	Firewall- und Conntrack-Kapazität

Typische Diagnosefehler

IANA-Portbereich ungeprüft als lokalen Betriebssystembereich annehmen.
Quellport und Zielport verwechseln.
RPC-Zielports und Clientquellports gleichsetzen.
TCP und UDP nicht getrennt prüfen.
IPv4 und IPv6 nicht getrennt prüfen.
Lokalen Port und SNAT-Port verwechseln.
Portanzahl als garantierte Gesamtverbindungszahl interpretieren.
Zieladresse und Zielport bei der Kapazität ignorieren.
Nur Gesamtverbindungen und nicht Verbindungen je Ziel prüfen.
TIME_WAIT allein als Beweis der Porterschöpfung verwenden.
CLOSE_WAIT als normalen Portablauf behandeln.
SYN_SENT ohne Netzwerkprüfung als Portproblem bewerten.
Prozesszuordnung nicht durchführen.
Verbindungsrate nicht messen.
Retries und Backoff nicht prüfen.
Connection Pooling nicht berücksichtigen.
Poolgröße nur pro Instanz und nicht über alle Instanzen berechnen.
Container, Pods oder Sidecars übersehen.
Proxy- und Zielverbindung als eine einzige Verbindung betrachten.
Dateideskriptorgrenze mit Portgrenze verwechseln.
Conntrack-Tabelle nicht prüfen.
Firewall-Sessionlimit ignorieren.
NAT-Gateway-Metriken nicht prüfen.
Cloudlimits aus einer anderen Ressource übertragen.
Portbereich als erste Maßnahme erweitern.
TIME_WAIT-Dauer vorsorglich verkürzen.
Server neu starten, bevor Beweisdaten gesichert sind.
Alle Sitzungen löschen.
Anwendungslimit durch Infrastrukturvergrößerung verdecken.
Nur eine einzelne Testverbindung durchführen.
Last- und Langzeittest nach der Maßnahme auslassen.
Temporäre Diagnoseaufzeichnungen aktiv lassen.

Verifikation

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

tatsächlicher dynamischer Portbereich ist dokumentiert;
reservierte Ports überschneiden sich nicht unerwartet;
neue Verbindungen werden zuverlässig aufgebaut;
bestehende Verbindungen bleiben stabil;
TIME_WAIT-Bestand entspricht der erwarteten Verbindungsrate;
CLOSE_WAIT wächst nicht dauerhaft;
SYN_SENT wächst nicht dauerhaft;
verursachender Prozess ist eindeutig bestimmt;
Connection Pool arbeitet innerhalb seiner Grenze;
Verbindungen werden wiederverwendet;
Retryrate entspricht der Vorgabe;
Dateideskriptorverbrauch bleibt unterhalb des Limits;
Listener- und Accept-Backlogs sind unauffällig;
Conntrack-Tabelle besitzt ausreichende Reserve;
Firewall-Sitzungslimit wird nicht erreicht;
NAT-Sitzungen besitzen ausreichende Reserve;
SNAT-Portfehler treten nicht mehr auf;
Cloudmetriken zeigen keine fehlgeschlagenen Portzuweisungen;
TCP und UDP funktionieren, sofern erforderlich;
IPv4 und IPv6 funktionieren, sofern erforderlich;
alle Anwendungsinstanzen funktionieren;
mehrere Ziele funktionieren;
konzentrierte Verbindungen zum Hauptziel funktionieren;
Lastspitze wird erfolgreich verarbeitet;
ursprüngliche Anwendung funktioniert;
keine neue Sicherheitsumgehung entstand;
keine unnötige allgemeine Portfreigabe besteht;
temporäre Diagnosen wurden zurückgenommen;
Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine erfolgreiche Einzelverbindung direkt nach einem Neustart ist keine ausreichende Verifikation. Porterschöpfung muss unter repräsentativer Last und über einen ausreichend langen Zeitraum ausgeschlossen werden.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

Betroffenes System:
<Hostname und IP-Adresse>

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

Adressfamilie:
<IPv4 oder IPv6>

Dynamischer Portbereich:
<Startport bis Endport>

Reservierte Ports:
<Portliste oder keine>

Verbindungen gesamt:
<Anzahl>

ESTABLISHED:
<Anzahl>

TIME_WAIT:
<Anzahl>

CLOSE_WAIT:
<Anzahl>

SYN_SENT:
<Anzahl>

UDP-Sockets:
<Anzahl>

Hauptverursachender Prozess:
<Name und PID>

Häufigstes Ziel:
<IP-Adresse und Port>

Verbindungsrate:
<neue Verbindungen pro Sekunde>

Connection Pool:
<Min, Max, Nutzung und Wiederverwendung>

Retryverhalten:
<Anzahl, Backoff und Jitter>

Dateideskriptoren:
<verwendet und Limit>

Conntrack:
<Count, Max und Fehler>

Firewall-Sitzungen:
<verwendet und Limit>

NAT vor Übersetzung:
<Quell-IP:Port>

NAT nach Übersetzung:
<öffentliche IP und SNAT-Port>

SNAT-Portnutzung:
<Metrik und Auslastung>

Plattformlimit:
<Ressource und dokumentierte Grenze>

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:
<Lasttest, Portnutzung und Anwendungstest>

Prävention:
<Monitoring, Pooling oder Kapazitätsplanung>

Checkliste

Schnellreferenz

Aufgabe	Befehl
Windows IPv4-TCP-Portbereich	`netsh int ipv4 show dynamicport tcp`
Windows IPv4-UDP-Portbereich	`netsh int ipv4 show dynamicport udp`
Windows IPv6-TCP-Portbereich	`netsh int ipv6 show dynamicport tcp`
Windows IPv6-UDP-Portbereich	`netsh int ipv6 show dynamicport udp`
Windows TCP-Verbindungen	`Get-NetTCPConnection`
Windows etablierte Verbindungen	`Get-NetTCPConnection -State Established`
Windows `TIME_WAIT`	`Get-NetTCPConnection -State TimeWait`
Windows `CLOSE_WAIT`	`Get-NetTCPConnection -State CloseWait`
Windows `SYN_SENT`	`Get-NetTCPConnection -State SynSent`
Windows Netstat	`netstat -ano`
Windows gebundene Ports	`netstat -anoq`
Windows relevante Ereignisse	`Get-WinEvent -FilterHashtable @{LogName="System"; Id=4227,4231}`
Linux-Portbereich	`sysctl net.ipv4.ip_local_port_range`
Linux-reservierte Ports	`sysctl net.ipv4.ip_local_reserved_ports`
Linux-Socketübersicht	`ss -s`
Linux-TCP-Sockets	`ss -tan`
Linux-TCP mit Prozessen	`sudo ss -tanp`
Linux `TIME_WAIT`	`ss -tan state time-wait`
Linux `CLOSE_WAIT`	`ss -tan state close-wait`
Linux `SYN_SENT`	`ss -tan state syn-sent`
Linux-Listener	`ss -lntp`
Linux-Socketstatistik	`cat /proc/net/sockstat`
Linux-FD-Limit der Shell	`ulimit -n`
Linux-Prozesslimits	`cat /proc/<PID>/limits`
Linux-systemweites FD-Limit	`sysctl fs.file-max`
Linux-Listen-Backlog	`sysctl net.core.somaxconn`
Linux-SYN-Backlog	`sysctl net.ipv4.tcp_max_syn_backlog`
Linux-Conntrack-Anzahl	`sysctl net.netfilter.nf_conntrack_count`
Linux-Conntrack-Maximum	`sysctl net.netfilter.nf_conntrack_max`
macOS-Portparameter	`sysctl -a \| awk '/net\.inet\.ip\.portrange/'`
macOS-TCP-Verbindungen	`netstat -anv -p tcp`
macOS-TCP-Prozesse	`sudo lsof -nP -iTCP`
macOS-Netzwerkübersicht	`nettop -m tcp`

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

netsh int ipv4 set dynamicport ...
netsh int ipv6 set dynamicport ...
sysctl -w net.ipv4.ip_local_port_range=...
sysctl -w net.ipv4.tcp_fin_timeout=...
TcpTimedWaitDelay ungeprüft verändern
MaxUserPort ungeprüft verändern
ulimit pauschal maximal erhöhen
LimitNOFILE ungeprüft erhöhen
fs.file-max ungeprüft erhöhen
net.core.somaxconn ungeprüft erhöhen
net.ipv4.tcp_max_syn_backlog ungeprüft erhöhen
nf_conntrack_max ungeprüft erhöhen
conntrack -F
Firewall-Sitzungen vollständig löschen
NAT-Sitzungen vollständig löschen
Server vorsorglich neu starten
NAT-Gateway vorsorglich neu erstellen
öffentliche IP-Adressen ohne Kapazitätsplanung ergänzen
Connection Pool unbegrenzt vergrößern
Timeouts pauschal verkürzen
Sicherheitsbegrenzungen deaktivieren

Quellen

Standards und Portregistrierung

Microsoft Windows

Linux Kernel und Manpages

Amazon Web Services

Microsoft Azure

Google Cloud

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

9.8 NAT, Portweiterleitung und Hairpin NAT im Datenpfad

Network Address Translation verändert IP-Adressen und gegebenenfalls Transportports innerhalb eines Datenflusses. Eine Verbindung kann deshalb an verschiedenen Stellen des Netzwerkpfads mit unterschiedlichen Adressen und Ports sichtbar sein.

Beispiel einer eingehenden Portweiterleitung:

Externer Client:
198.51.100.40:53124

Öffentliche Adresse:
203.0.113.10:8443

Interner Server:
192.0.2.25:443

Vor der Zielübersetzung:

198.51.100.40:53124 -> 203.0.113.10:8443/TCP

Nach der Zielübersetzung:

198.51.100.40:53124 -> 192.0.2.25:443/TCP

Eine scheinbar richtige Firewallregel kann wirkungslos bleiben, wenn sie die falsche Adressphase, das falsche Protokoll, die falsche Schnittstelle oder den falschen Übersetzungsport verwendet.

Ziele

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

welche Adressen und Ports vor und nach NAT verwendet werden;
ob Source NAT, Destination NAT oder Port Address Translation greift;
welche NAT-Regel tatsächlich angewendet wird;
ob eine Portweiterleitung auf das richtige interne Ziel zeigt;
ob Firewallregel, Routing und NAT zusammenpassen;
ob der Rückverkehr dieselbe NAT-Komponente durchläuft;
ob ein vorgeschaltetes NAT oder Carrier-Grade NAT eingehende Verbindungen verhindert;
ob Hairpin NAT beziehungsweise NAT Loopback unterstützt wird;
warum eine Verbindung intern, extern oder nur über die öffentliche Adresse fehlschlägt;
wie Container-, Cloud- und Load-Balancer-NAT berücksichtigt werden;
wie eine NAT-Änderung kontrolliert verifiziert wird.

Sicherheits- und Änderungsgrundsätze

Eine Portweiterleitung veröffentlicht einen internen Dienst über einen zusätzlichen Netzwerkpfad. Vor der Einrichtung sind mindestens zu prüfen:

geschäftlicher Zweck;
verantwortlicher Diensteigentümer;
erforderliches Protokoll;
erforderlicher Port;
erlaubte Quelladressen;
Authentifizierung;
Verschlüsselung;
Patchstand;
Protokollierung;
Rate Limiting;
Monitoring;
Rückweg;
Rücknahmezeitpunkt;
Risiko;
Freigabe.

Besonders schützenswerte Verwaltungs- und Dateidienste sollten nicht ohne zusätzliche Schutzarchitektur direkt aus dem Internet veröffentlicht werden.

Dazu gehören beispielsweise:

RDP;
SMB;
SSH mit schwacher Authentifizierung;
Datenbankports;
Hypervisorverwaltung;
NAS-Verwaltung;
Router- oder Firewallverwaltung;
unverschlüsselte Weboberflächen;
interne Verzeichnisdienste.

Geeignetere Zugriffsmöglichkeiten können sein:

VPN;
Zero-Trust-Zugriff;
Bastion Host;
Jump Host;
Reverse Proxy mit starker Authentifizierung;
Application Gateway;
Web Application Firewall;
privater Cloudendpunkt.

Nicht als erste Diagnosemaßnahme geeignet sind:

alle Ports weiterleiten;
DMZ-Host-Funktion eines Routers aktivieren;
Exposed Host einrichten;
Firewall vollständig deaktivieren;
allgemeine any-zu-any-Regel erstellen;
NAT-Tabelle vollständig leeren;
alle Verbindungstabellen löschen;
UPnP pauschal aktivieren;
Server direkt mit öffentlicher Adresse verbinden;
Managementport testweise veröffentlichen;
Router oder Firewall vorsorglich neu starten;
mehrere NAT-Regeln gleichzeitig verändern.

NAT ist keine Firewall

NAT verändert Adressen oder Ports. Eine Firewall entscheidet anhand einer Sicherheitsrichtlinie, ob Datenverkehr erlaubt oder verworfen wird.

Beide Funktionen können sich im selben Gerät befinden, bleiben aber logisch getrennt.

Beispiel:

NAT-Regel:
203.0.113.10:8443 -> 192.0.2.25:443

Firewallregel:
TCP von 198.51.100.0/24 zu 192.0.2.25:443 erlauben

Mögliche Kombinationen:

NAT	Firewall	Ergebnis
vorhanden	erlaubt	Verbindung kann weiterverarbeitet werden
vorhanden	blockiert	Übersetzung kann passen, Verkehr wird trotzdem verworfen
fehlt	erlaubt	Freigabe besitzt möglicherweise kein erreichbares Ziel
falsch	erlaubt	Verkehr erreicht falsches System oder falschen Port
vorhanden	falsche Richtung	Verbindungsaufbau bleibt blockiert
automatisch erstellt	unbekannt	Sicherheitswirkung muss ausdrücklich geprüft werden

Einige Router erzeugen zusammen mit einer Portweiterleitung automatisch eine Firewallfreigabe. Andere Produkte verlangen eine getrennte Regel. Dieses Verhalten ist hersteller- und versionsabhängig.

NAT-Begriffe

Begriff	Bedeutung
NAT	Oberbegriff für die Übersetzung von Netzwerkadressen
SNAT	Änderung der Quelladresse
DNAT	Änderung der Zieladresse
PAT	Übersetzung von Transportports, häufig zusammen mit Adressübersetzung
NAPT	Übersetzung von Netzwerkadresse und Transportport
Masquerading	SNAT auf die aktuelle Adresse einer Ausgangsschnittstelle
statisches NAT	fest definierte Zuordnung
dynamisches NAT	Zuordnung aus einem Adresspool
Portweiterleitung	statische eingehende Zieladress- und/oder Portübersetzung
1:1-NAT	feste Zuordnung einer internen zu einer externen Adresse
Twice NAT	Quelle und Ziel werden abhängig voneinander in einer Regel verarbeitet
NAT Exemption	bestimmter Datenverkehr wird ausdrücklich nicht übersetzt
Hairpin NAT	interner Client erreicht internes Ziel über dessen externe NAT-Adresse
NAT Loopback	gebräuchliche Bezeichnung für Hairpin NAT
NAT Reflection	herstellerabhängige Bezeichnung für Hairpin-Verarbeitung
U-Turn NAT	weitere gebräuchliche Bezeichnung für Hairpin NAT
CGNAT	NAT im Netz des Internetzugangsanbieters
NAT64	Übersetzung zwischen IPv6 und IPv4
NPTv6	zustandslose Übersetzung von IPv6-Präfixen

Die Begriffe werden von Herstellern nicht immer einheitlich verwendet.

Source NAT

Source NAT verändert die Quelladresse eines ausgehenden Datenflusses.

Vor SNAT:

192.0.2.100:53124 -> 198.51.100.25:443

Nach SNAT:

203.0.113.10:61001 -> 198.51.100.25:443

Das Zielsystem sieht als Quelle:

203.0.113.10:61001

und normalerweise nicht:

192.0.2.100:53124

Typische Anwendungsfälle:

private IPv4-Clients greifen auf das Internet zu;
mehrere interne Systeme teilen sich eine öffentliche Adresse;
Rückverkehr soll über eine bestimmte Firewall geführt werden;
überlappende Netze werden verbunden;
ein Ziel erlaubt nur definierte Quelladressen;
Hairpin-Verkehr wird symmetrisch über das NAT-Gerät geführt.

Auswirkungen:

ursprüngliche Quelladresse ist am Ziel nicht direkt sichtbar;
Protokolle zeigen gegebenenfalls nur die NAT-Adresse;
Portkapazität der NAT-Adresse wird benötigt;
Rückverkehr ist an die NAT-Sitzung gebunden;
Quell-IP-basierte Sicherheitsentscheidungen verändern sich.

Destination NAT

Destination NAT verändert die Zieladresse eines eingehenden Datenflusses.

Vor DNAT:

198.51.100.40:53124 -> 203.0.113.10:8443

Nach DNAT:

198.51.100.40:53124 -> 192.0.2.25:443

Typische Anwendungsfälle:

Portweiterleitung;
Veröffentlichung eines internen Servers;
Weiterleitung an Reverse Proxy;
Load Balancing;
transparente Proxyfunktion;
Umleitung auf einen lokalen Dienst.

Zu prüfen sind:

externe Zieladresse;
externer Zielport;
internes Ziel;
interner Zielport;
Protokoll;
Eingangsschnittstelle;
Quellbereich;
Firewallregel;
Rückroute;
Zustandstabelle.

Port Address Translation

PAT ermöglicht die Unterscheidung vieler Datenflüsse über dieselbe externe IP-Adresse.

Beispiel:

192.0.2.100:53124
    ->
203.0.113.10:61001

192.0.2.101:53124
    ->
203.0.113.10:61002

Beide Clients können dasselbe Ziel verwenden:

198.51.100.25:443

Das NAT-Gerät hält dafür getrennte Zuordnungen:

203.0.113.10:61001 -> 192.0.2.100:53124
203.0.113.10:61002 -> 192.0.2.101:53124

PAT benötigt:

freie Übersetzungsports;
eine Sitzungstabelle;
passende Timeouts;
einen symmetrischen Rückweg;
ausreichende NAT-Kapazität.

1:1-NAT

Bei 1:1-NAT wird eine interne Adresse fest einer externen Adresse zugeordnet.

Beispiel:

Öffentlich:
203.0.113.25

Intern:
192.0.2.25

Mögliche Übersetzung:

203.0.113.25 <-> 192.0.2.25

1:1-NAT bedeutet nicht automatisch, dass alle Ports erlaubt sind. Die Firewallrichtlinie muss weiterhin festlegen:

zulässige Quellen;
zulässige Protokolle;
zulässige Ports;
Richtung;
Protokollierung;
Sicherheitsprofile.

Portweiterleitung

Eine Portweiterleitung ordnet eine externe Kombination einer internen Kombination zu.

Beispiel:

Externe Adresse:
203.0.113.10

Externer Port:
8443

Protokoll:
TCP

Internes Ziel:
192.0.2.25

Interner Port:
443

Vereinfachte Regel:

TCP 203.0.113.10:8443
    ->
TCP 192.0.2.25:443

Eine vollständige Portweiterleitung benötigt mindestens:

richtige öffentliche Adresse;
richtige Eingangsschnittstelle;
richtiges Protokoll;
richtigen externen Port;
richtige interne Zieladresse;
richtigen internen Port;
aktiven Serverdienst;
lokale Serverfirewall;
zentrale Firewallfreigabe;
korrekte Rückroute;
funktionierenden NAT-Zustand.

Externen und internen Port unterscheiden

Die Portnummern müssen nicht identisch sein.

Beispiel:

Extern:
TCP 8443

Intern:
TCP 443

Mögliche Diagnosefehler:

extern Port 443 testen, obwohl 8443 veröffentlicht ist;
Firewall für internen Port 8443 öffnen, obwohl Server auf 443 hört;
Server auf 8443 prüfen, obwohl DNAT auf 443 übersetzt;
TCP-Regel anlegen, obwohl Anwendung UDP verwendet;
IPv4-NAT testen, obwohl DNS eine IPv6-Adresse liefert.

TCP und UDP getrennt weiterleiten

Eine Portnummer bezeichnet ohne Transportprotokoll keinen vollständigen Dienstendpunkt.

Diese beiden Regeln sind verschieden:

TCP 203.0.113.10:8443 -> 192.0.2.25:443

UDP 203.0.113.10:8443 -> 192.0.2.25:443

Zu prüfen sind:

TCP;
UDP;
gegebenenfalls beide Protokolle;
ICMP-Verhalten;
QUIC über UDP;
anwendungsspezifische Zusatzports;
dynamisch ausgehandelte Ports.

Ein erfolgreicher TCP-Test beweist keine funktionierende UDP-Weiterleitung.

Eingangsschnittstelle und Zieladresse

Eine NAT-Regel kann an eine bestimmte Eingangsschnittstelle oder öffentliche Zieladresse gebunden sein.

Beispiele:

WAN1;
WAN2;
VPN;
Mobilfunk;
öffentliche Adresse A;
öffentliche Adresse B;
virtuelle IP-Adresse;
Load-Balancer-Adresse.

Typischer Fehler:

NAT-Regel:
gilt nur für WAN1

Tatsächlicher Datenverkehr:
trifft über WAN2 ein

Die Regel ist vorhanden, verarbeitet diesen Datenfluss aber nicht.

Vollständiger eingehender Datenpfad

Ein eingehender Zugriff kann folgende Ebenen durchlaufen:

öffentlicher DNS-Eintrag;
Internetzugangsanbieter;
vorgeschaltetes Provider-NAT;
Modem oder Router;
Edge-Firewall;
öffentliche IP-Adresse;
DNAT- oder Portweiterleitungsregel;
Sicherheitsregel;
interne Route;
VLAN- oder Segmentfirewall;
Load Balancer;
Reverse Proxy;
Containerhost;
veröffentlichter Hostport;
Containerport;
lokale Host-Firewall;
Serverprozess;
Anwendung.

Jede Ebene muss mit ihrer vor und nach der Verarbeitung sichtbaren Adresse geprüft werden.

Vollständiger Rückweg

Der Rückverkehr einer eingehenden Verbindung muss die zustandsbehaftete NAT-Komponente wieder erreichen.

Beispiel:

Hinweg:
198.51.100.40
    ->
203.0.113.10
    ->
192.0.2.25

Rückweg:
192.0.2.25
    ->
203.0.113.10
    ->
198.51.100.40

Wenn der Server über ein anderes Gateway antwortet:

192.0.2.25
    ->
anderer Router
    ->
198.51.100.40

fehlt dort möglicherweise die Rückübersetzung.

Mögliche Folgen:

Client erhält eine Antwort mit unerwarteter Quelladresse;
Antwort wird durch eine Firewall verworfen;
TCP-Handshake bleibt unvollständig;
NAT-Sitzung bleibt ohne Rückverkehr;
Server sendet wiederholt SYN, ACK;
Client sendet wiederholt SYN.

NAT-Reihenfolge ist produktspezifisch

Die Verarbeitung kann unter anderem umfassen:

Eingangsschnittstelle bestimmen;
bestehende Sitzung suchen;
DNAT anwenden;
Route bestimmen;
Zielzone bestimmen;
Sicherheitsregel prüfen;
SNAT anwenden;
Ausgangsschnittstelle bestimmen;
Paket weiterleiten.

Die genaue Reihenfolge unterscheidet sich zwischen:

Linux Netfilter;
Cisco ASA;
Palo Alto Networks;
Juniper SRX;
Fortinet;
Cloud-Firewalls;
Heimroutern;
Load Balancern;
Containerplattformen.

Es darf nicht pauschal angenommen werden, dass eine Firewallregel immer:

die öffentliche Adresse;
die private Adresse;
den externen Port;
den internen Port;
die Vor-NAT-Zone;
die Nach-NAT-Zone

verwenden muss.

Maßgeblich ist die Dokumentation des eingesetzten Produkts und der Softwareversion.

NAT-Regelreihenfolge

NAT-Regeln können priorisiert oder der Reihe nach ausgewertet werden.

Mögliche Probleme:

allgemeinere Regel steht vor spezifischer Regel;
bestehende Masquerade-Regel erfasst den Datenfluss;
NAT-Ausnahme überschattet die gewünschte Übersetzung;
doppelte Portweiterleitung verwendet denselben externen Port;
falsche Schnittstelle besitzt höhere Priorität;
Twice-NAT-Regel beendet die weitere Auswertung;
alte Regel ist noch aktiv;
zentrale Policy überschreibt lokale Regel;
IPv6-Regel wird mit IPv4-Regel verwechselt.

Zu dokumentieren sind:

Regel-ID;
Regelname;
Reihenfolge;
Quellbereich;
Zielbereich;
Protokoll;
Ports;
Schnittstellen;
Trefferzähler;
letzte Verwendung;
aktive Konfigurationsversion.

Statische interne Zieladresse

Das Ziel einer Portweiterleitung muss dauerhaft erreichbar bleiben.

Geeignete Möglichkeiten:

statische Serveradresse;
DHCP-Reservierung;
stabile virtuelle IP-Adresse;
Load-Balancer-Adresse;
Serviceadresse.

Typischer Fehler:

Portweiterleitung:
192.0.2.25

Aktuelle Serveradresse:
192.0.2.37

Die NAT-Regel ist syntaktisch korrekt, zeigt aber auf ein nicht mehr verwendetes Ziel.

Zu prüfen sind:

aktuelle IP-Adresse;
DHCP-Lease;
Adressreservierung;
DNS;
ARP- oder Neighbor-Tabelle;
Serverroute;
Mehrfachadressierung;
Cluster- oder Failoveradresse.

Öffentliche Erreichbarkeit prüfen

Eine eingehende Portweiterleitung benötigt eine von außen erreichbare Zieladresse.

Zu prüfen sind:

WAN-Adresse des eigenen Routers;
öffentliche DNS-Adresse;
von einem autorisierten externen System beobachtete Quelladresse;
vorgeschaltetes Modem;
weiterer Router;
Provider-NAT;
Carrier-Grade NAT;
DS-Lite;
Mobilfunk-NAT;
VPN oder Tunnel;
dynamische öffentliche Adresse;
IPv4 oder IPv6.

Eine private Adresse auf der WAN-Schnittstelle ist nicht direkt aus dem öffentlichen Internet erreichbar.

Private IPv4-Bereiche

RFC 1918 definiert:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Das bedeutet:

10.0.0.0 bis 10.255.255.255
172.16.0.0 bis 172.31.255.255
192.168.0.0 bis 192.168.255.255

Befindet sich die WAN-Adresse des eigenen Routers in einem dieser Bereiche, existiert mindestens ein weiteres vorgeschaltetes Routing- oder NAT-System.

Shared Address Space und CGNAT

RFC 6598 reserviert für Provider-NAT:

100.64.0.0/10

Das umfasst:

100.64.0.0 bis 100.127.255.255

Dieser Bereich ist kein RFC-1918-Privatnetz, wird aber für Shared Address Space und häufig für Carrier-Grade NAT verwendet.

Hinweise auf vorgeschaltetes NAT:

WAN-Adresse liegt in einem privaten Bereich;
WAN-Adresse liegt in 100.64.0.0/10;
Router-WAN-Adresse weicht von der extern beobachteten Adresse ab;
Portweiterleitung funktioniert trotz richtiger lokaler Konfiguration nicht;
Internetzugang funktioniert ausschließlich ausgehend;
Anbieter nennt DS-Lite oder CGNAT;
öffentliche IPv4-Adresse ist nicht Bestandteil des Anschlusses.

Eine Abweichung der Adressen ist ein Hinweis und muss unter Berücksichtigung von VPN, Proxy, mehreren Leitungen und Providerarchitektur bewertet werden.

Doppeltes NAT

Beispiel:

Internet
    ->
Providerrouter 192.168.0.1
    ->
eigener Router 192.168.0.2
    ->
Server 192.0.2.25

Für eine eingehende Verbindung können zwei Weiterleitungen erforderlich sein:

Providerrouter:
203.0.113.10:8443
    ->
192.168.0.2:8443

Eigener Router:
192.168.0.2:8443
    ->
192.0.2.25:443

Zusätzlich müssen beide Firewalls und beide Rückwege passen.

Besser kann je nach freigegebener Architektur sein:

Bridge- oder Modemmodus;
eigener Router als einziges NAT-Gateway;
statische Route statt zweitem NAT;
öffentliche Adresse direkt am Edge-Gerät;
kontrollierte DMZ-Verbindung zwischen den Geräten.

Ein Exposed Host ist keine geeignete Standardlösung, weil dadurch möglicherweise sehr viele Ports weitergeleitet werden.

Carrier-Grade NAT und Portweiterleitung

Befindet sich die öffentliche IPv4-Adresse auf einem Provider-NAT, kann der eigene Router keine beliebige eingehende Abbildung auf diesem Providergerät erstellen.

Mögliche Lösungen hängen vom Anbieter ab:

öffentliche IPv4-Adresse buchen;
statische öffentliche IPv4-Adresse verwenden;
IPv6 mit geeigneter Firewallfreigabe verwenden;
VPN mit eingehendem Tunnelendpunkt verwenden;
Reverse Tunnel;
Cloud-Reverse-Proxy;
providerseitige Portzuordnung;
Port Control Protocol, sofern tatsächlich unterstützt.

Die technische und sicherheitstechnische Eignung muss für den konkreten Dienst bewertet werden.

Hairpin NAT

Hairpin NAT ermöglicht einem internen Client den Zugriff auf einen internen Server über dessen externe NAT-Adresse.

Beispiel:

Interner Client:
192.0.2.100

Öffentliche Dienstadresse:
203.0.113.10:443

Interner Server:
192.0.2.25:443

Der Client verwendet:

192.0.2.100:53124 -> 203.0.113.10:443

Das NAT-Gerät übersetzt das Ziel:

192.0.2.100:53124 -> 192.0.2.25:443

Abhängig von Topologie und Produkt muss zusätzlich die Quelle übersetzt werden, damit der Server über dasselbe NAT-Gerät antwortet.

Hairpin NAT mit Quellübersetzung

Mögliche Verarbeitung:

Ursprünglich:
192.0.2.100:53124 -> 203.0.113.10:443

Nach Hairpin DNAT und SNAT:
192.0.2.1:61001 -> 192.0.2.25:443

Dabei ist:

192.0.2.1

eine Adresse des NAT-Gateways.

Der Server antwortet an das Gateway:

192.0.2.25:443 -> 192.0.2.1:61001

Das Gateway stellt für den Client wieder die erwartete Ansicht her:

203.0.113.10:443 -> 192.0.2.100:53124

Vorteil:

Hin- und Rückverkehr durchlaufen dieselbe NAT-Sitzung.

Nachteil:

der Server sieht möglicherweise nicht die ursprüngliche Clientadresse;
Protokolle zeigen die Gatewayadresse;
quelladressbasierte Richtlinien verändern sich.

Direkter Rückweg als Hairpin-Problem

Client und Server befinden sich im selben internen Subnetz:

Client:
192.0.2.100

Server:
192.0.2.25

Wenn nur das Ziel übersetzt wird, kann der Server direkt antworten:

192.0.2.25:443 -> 192.0.2.100:53124

Der Client hat die Verbindung jedoch zu folgender Adresse aufgebaut:

203.0.113.10:443

Eine direkte Antwort von:

192.0.2.25:443

passt nicht zur erwarteten Gegenstelle.

Mögliche Symptome:

interner Zugriff über private Adresse funktioniert;
externer Zugriff über öffentliche Adresse funktioniert;
interner Zugriff über öffentliche Adresse scheitert;
Server sieht das eingehende Paket;
NAT-Gerät sieht keinen Rückverkehr;
Client verwirft die unerwartete Antwort.

Hairpin NAT ist nicht überall verfügbar

Mögliche Produktbezeichnungen:

NAT Loopback;
NAT Reflection;
Hairpin NAT;
U-Turn NAT;
Same-Interface NAT;
Intra-Interface NAT.

Zu prüfen sind:

wird Hairpin NAT unterstützt?
ist es aktiviert?
gilt es für IPv4, IPv6 oder beide?
gilt es für dieselbe Schnittstelle?
benötigt es eine zusätzliche SNAT-Regel?
wird die ursprüngliche Clientadresse erhalten?
greift die richtige Firewallregel?
verwendet es dieselbe öffentliche Adresse?
funktioniert es bei mehreren WAN-Adressen?
ist es mit Load Balancer oder Proxy kompatibel?

Das Verhalten darf nicht von einem anderen Routermodell oder Hersteller übertragen werden.

Split DNS als Alternative

Statt Hairpin NAT kann internes DNS den Dienstnamen direkt auf die interne Adresse auflösen.

Extern:

app.example.test
    ->
203.0.113.10

Intern:

app.example.test
    ->
192.0.2.25

Vorteile:

interner Verkehr bleibt intern;
keine Hairpin-NAT-Sitzung erforderlich;
ursprüngliche Clientadresse bleibt sichtbar;
weniger Last auf der Edge-Firewall;
einfacherer Datenpfad.

Zu prüfen sind:

identischer FQDN;
TLS-Zertifikat für den FQDN;
interne und externe DNS-Zone;
TTL;
DNSSEC-Kontext;
VPN- und Split-DNS-Verhalten;
Load-Balancer-Abhängigkeit;
unterschiedliche Anwendungspfade;
IPv4- und IPv6-Antworten.

Split DNS ist nicht automatisch besser, wenn intern derselbe Reverse Proxy, dieselbe Web Application Firewall oder dieselben Sicherheitsprüfungen benötigt werden.

Internen und externen Test unterscheiden

Mindestens drei Tests sind getrennt zu dokumentieren:

Test A:
interner Client -> interne Serveradresse

Test B:
interner Client -> öffentliche Dienstadresse

Test C:
externer Client -> öffentliche Dienstadresse

Einordnung:

Test A	Test B	Test C	Mögliche Einordnung
erfolgreich	erfolgreich	erfolgreich	grundlegender Pfad funktioniert
erfolgreich	fehlerhaft	erfolgreich	Hairpin NAT oder internes DNS
erfolgreich	erfolgreich	fehlerhaft	externe Weiterleitung, Provider, WAN oder Firewall
fehlerhaft	fehlerhaft	fehlerhaft	Serverdienst, Host-Firewall oder interne Route
fehlerhaft	erfolgreich	erfolgreich	unterschiedliche interne Adresse oder Sicherheitsregel
erfolgreich	fehlerhaft	fehlerhaft	DNAT-Regel oder öffentliche Adresszuordnung
fehlerhaft	fehlerhaft	erfolgreich	externer Proxy oder anderer Backendpfad

Test C muss tatsächlich aus einem externen Netz erfolgen. Ein Mobilgerät im WLAN ist kein externer Test. Auch ein VPN kann den Datenpfad zurück ins interne Netz führen.

DNS und NAT gemeinsam prüfen

Ein FQDN kann liefern:

öffentliche IPv4-Adresse;
öffentliche IPv6-Adresse;
interne IPv4-Adresse;
interne IPv6-Adresse;
Load-Balancer-Adresse;
CDN-Adresse;
Proxyadresse.

Windows:

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A

Resolve-DnsName `
  -Name "app.example.test" `
  -Type AAAA

Linux und macOS:

dig app.example.test A

dig app.example.test AAAA

Zu prüfen sind:

welche Adresse verwendet die Anwendung tatsächlich?
ist diese Adresse Bestandteil der NAT-Regel?
greift IPv6 ohne IPv4-NAT?
existiert Split DNS?
verwendet der Browser verschlüsseltes DNS?
ist ein Proxy beteiligt?
ist der DNS-Eintrag nach Adressänderung aktuell?

Eine korrekte IPv4-Portweiterleitung hilft nicht, wenn der Client aufgrund eines AAAA-Eintrags direkt IPv6 verwendet.

IPv6 und NAT

IPv6 benötigt für normale öffentliche Erreichbarkeit nicht dieselbe Form von IPv4-Portübersetzung. Ein global adressierter IPv6-Server ist trotzdem nicht automatisch erreichbar.

Zu prüfen sind:

globale IPv6-Adresse;
Präfixdelegation;
IPv6-Route;
IPv6-Firewall;
Listener auf IPv6;
AAAA-Eintrag;
Privacy Address;
stabile Serveradresse;
NDP;
ICMPv6;
Providerfilter;
Reverse Proxy;
NPTv6 oder NAT64.

NAT darf nicht als Ersatz für eine IPv6-Firewall betrachtet werden.

NPTv6 übersetzt IPv6-Präfixe zustandslos und besitzt ein anderes Verhalten als klassische IPv4-Portübersetzung.

Automatische Portabbildungen

Anwendungen können je nach Umgebung automatische Portabbildungen anfordern, beispielsweise über:

UPnP Internet Gateway Device;
NAT-PMP;
Port Control Protocol;
herstellerspezifische Verfahren.

Zu prüfen sind:

ist die Funktion aktiviert?
welche Anwendung hat die Regel erstellt?
welcher interne Host ist Ziel?
welcher externe Port wurde vergeben?
welches Protokoll wird verwendet?
wie lange gilt die Abbildung?
existiert Authentifizierung oder Zugriffskontrolle?
bleibt die Regel nach Anwendungsende bestehen?
wird die Regel protokolliert?
überschneidet sie sich mit administrativen Regeln?

Automatische Portabbildungen können die vorgesehene Sicherheitskontrolle umgehen. Sie dürfen nicht nur zur schnellen Fehlerbehebung aktiviert werden.

Application Level Gateways

Ein NAT-Gerät kann Protokollinhalte analysieren und Adressen oder Ports innerhalb der Nutzdaten verändern.

Mögliche Protokolle:

FTP;
SIP;
H.323;
TFTP;
bestimmte VPN-Protokolle;
ältere RPC-Verfahren.

Zu prüfen sind:

ALG aktiviert oder deaktiviert;
verschlüsselte oder unverschlüsselte Nutzdaten;
dynamisch ausgehandelte Ports;
NAT-Helper;
fehlerhafte Protokollumschreibung;
Herstellerfehler;
Interaktion mit TLS;
zusätzliche Firewallregeln.

Ein ALG kann helfen, aber auch Verbindungen beschädigen. Es darf nur nach nachgewiesenem Zusammenhang verändert werden.

NAT und TLS

NAT verändert normalerweise nicht den TLS-Hostnamen oder das Zertifikat.

Beispiel:

FQDN:
app.example.test

Öffentliche Adresse:
203.0.113.10

Interner Server:
192.0.2.25

Das Zertifikat muss zum verwendeten Namen passen:

app.example.test

und nicht zwangsläufig zur öffentlichen oder privaten IP-Adresse.

NAT kann jedoch indirekt TLS-Probleme verursachen, wenn:

falscher Backendserver erreicht wird;
externer und interner Port unterschiedliche Dienste liefern;
SNI an falschen Reverse Proxy gelangt;
Hairpin-Zugriff einen anderen Proxy umgeht;
Split DNS ein anderes Ziel liefert;
TLS-Inspektion beteiligt ist;
Proxy Protocol oder ursprüngliche Clientadresse erwartet wird.

Reverse Proxy und Portweiterleitung

Häufig zeigt eine Portweiterleitung nicht direkt auf den Anwendungsserver, sondern auf einen Reverse Proxy.

Beispiel:

Internet:
203.0.113.10:443

DNAT:
192.0.2.20:443

Reverse Proxy:
app.example.test -> 192.0.2.25:8080

Zu prüfen sind zwei getrennte Verbindungen:

Client -> Reverse Proxy
Reverse Proxy -> Backend

Mögliche Fehlerstellen:

öffentliche DNAT-Regel;
Firewall;
TLS-Zertifikat;
SNI;
Proxy-VHost;
Backendadresse;
Backendport;
Proxyroute;
Backendfirewall;
Health Check;
Hostheader;
WebSocket-Weiterleitung;
Timeout;
ursprüngliche Clientadresse.

Ein erfolgreicher externer TCP-Handshake bis zum Reverse Proxy beweist nicht, dass das Backend erreichbar ist.

Docker-Portveröffentlichung

Ein Docker-Container in einem Bridge-Netz ist normalerweise nicht allein durch EXPOSE von außen erreichbar. Der Port muss veröffentlicht oder über einen anderen Proxy bereitgestellt werden.

Beispiel:

docker run \
  -p 8080:80 \
  nginx

Bedeutung:

Hostport 8080
    ->
Containerport 80

Ohne ausdrücklich angegebene Hostadresse kann ein veröffentlichter Port auf allen geeigneten Hostadressen gebunden werden.

Sicherer auf den lokalen Host begrenzt:

docker run \
  -p 127.0.0.1:8080:80 \
  nginx

Damit ist der Port für einen lokalen Reverse Proxy erreichbar, aber nicht automatisch über jede externe Hostschnittstelle.

Docker-Portzuordnung prüfen

Laufende Container und veröffentlichte Ports:

docker ps \
  --format 'table {{.Names}}\t{{.Ports}}'

Portzuordnung eines Containers:

docker port <Containername>

Vollständige Netzwerkinformation:

docker inspect <Containername>

Hostlistener:

ss -lntp

Containerlistener:

docker exec <Containername> \
  ss -lntp

Falls ss im Container nicht installiert ist, sind Anwendungsprotokolle, Health Checks oder die im Image verfügbaren Diagnosewerkzeuge zu verwenden.

Zu unterscheiden sind:

Routerport
Hostport
Containerport
Anwendungsport

Beispiel:

203.0.113.10:8443
    ->
192.0.2.20:6875
    ->
Container:80

Docker-Netzwerkmodus berücksichtigen

Netzwerkmodus	NAT- oder Portverhalten
Bridge	Portveröffentlichung und NAT üblich
Host	Container verwendet den Netzwerkstack des Hosts; `-p` wird nicht angewendet
Macvlan	Container kann eigene Adresse im Netz besitzen
Ipvlan	direkte adressbasierte Anbindung je nach Betriebsart
Overlay	zusätzlicher Overlay- und Orchestrierungspfad
None	keine normale externe Netzwerkanbindung

Bei host-Netzwerkmodus besitzt der Container keinen getrennten Host-zu-Container-Portpfad. Eine konfigurierte -p-Option wird nicht als normale Portweiterleitung verwendet.

Docker und Firewallregeln

Docker kann für Bridge-Netze eigene Firewall- und NAT-Regeln erzeugen.

Zu prüfen sind:

nftables oder iptables;
Docker-spezifische Chains;
veröffentlichte Ports;
Host-Firewall;
Forwarding;
Masquerading;
benutzerdefinierte Regeln;
Docker-Netzwerk;
Startreihenfolge;
Neustart des Docker-Daemons;
Firewallreload.

Eigene Regeln dürfen nicht ungeprüft vor, nach oder innerhalb von Docker-verwalteten Regelketten eingefügt werden.

Kubernetes-Datenpfad

Mögliche Ebenen:

öffentliche Adresse
    ->
Cloud Load Balancer
    ->
Ingress Controller
    ->
Kubernetes Service
    ->
Pod

Oder:

Node-IP:NodePort
    ->
Service
    ->
Pod

Lesende Prüfungen:

kubectl get services \
  --all-namespaces \
  -o wide

kubectl get ingress \
  --all-namespaces

kubectl get endpointslices \
  --all-namespaces

kubectl describe service \
  <Servicename> \
  --namespace <Namespace>

Zu prüfen sind:

Service-Typ;
ClusterIP;
NodePort;
LoadBalancer-Adresse;
TargetPort;
Selector;
EndpointSlices;
Podport;
Network Policy;
Ingressregel;
Hostname;
TLS;
External Traffic Policy;
Source NAT;
Health Checks.

Windows WinNAT lesend prüfen

NAT-Objekte:

Get-NetNat

Statische Abbildungen:

Get-NetNatStaticMapping

Aktive NAT-Sitzungen:

Get-NetNatSession

Netzwerkschnittstellen:

Get-NetIPConfiguration

Routing:

Get-NetRoute

Listener:

Get-NetTCPConnection `
  -State Listen

WinNAT wird unter anderem für Hyper-V- und Windows-Container-Netze verwendet. Die Cmdlets zeigen keine NAT-Konfiguration eines getrennten physischen Routers.

Linux nftables lesend prüfen

Vollständiges Regelwerk:

sudo nft list ruleset

Tabellen:

sudo nft list tables

Eine bekannte NAT-Tabelle anzeigen:

sudo nft list table ip nat

Die Tabelle muss nicht ip nat heißen. Maßgeblich ist die Ausgabe von:

sudo nft list tables

Regelwerk mit Handles:

sudo nft -a list ruleset

Zu suchen sind unter anderem:

dnat
snat
masquerade
redirect
prerouting
postrouting
output
input

Bei nftables sind:

dnat und redirect für geeignete NAT-Chains wie prerouting oder output vorgesehen;
snat und masquerade für geeignete NAT-Chains wie postrouting vorgesehen.

Die tatsächliche Chain, Priorität und Familie sind zu prüfen.

Vereinfachtes nftables-DNAT-Beispiel

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;

        iifname "wan0" \
        ip daddr 203.0.113.10 \
        tcp dport 8443 \
        dnat to 192.0.2.25:443
    }
}

Dieses Beispiel enthält nur die Zielübersetzung. Zusätzlich erforderlich sein können:

Forwarding;
Filterregel;
Rückroute;
SNAT;
Hairpin-Regel;
Protokollierung;
IPv6-Regel;
dauerhaftes Konfigurationsmanagement.

Es darf nicht ungeprüft in ein produktives Regelwerk übernommen werden.

Vereinfachtes nftables-Hairpin-Prinzip

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;

        ip saddr 192.0.2.0/24 \
        ip daddr 203.0.113.10 \
        tcp dport 443 \
        dnat to 192.0.2.25:443
    }

    chain postrouting {
        type nat hook postrouting priority srcnat;

        ip saddr 192.0.2.0/24 \
        ip daddr 192.0.2.25 \
        tcp dport 443 \
        masquerade
    }
}

Dieses vereinfachte Prinzip erzwingt, dass der Rückverkehr wieder über das NAT-Gateway läuft. Adressen, Schnittstellen, Sicherheitsregeln und Regelprioritäten müssen an die tatsächliche Umgebung angepasst und freigegeben werden.

Linux iptables lesend prüfen

NAT-Regeln:

sudo iptables \
  -t nat \
  -L \
  -n \
  -v \
  --line-numbers

Regeln in speicherbarer Syntax:

sudo iptables \
  -t nat \
  -S

IPv6-Regeln, sofern verwendet:

sudo ip6tables \
  -t nat \
  -S

Filter- und Forwardingregeln:

sudo iptables \
  -L FORWARD \
  -n \
  -v \
  --line-numbers

Aktive Weiterleitung:

sysctl net.ipv4.ip_forward

IPv6-Weiterleitung:

sysctl net.ipv6.conf.all.forwarding

Linux Connection Tracking

Aktive NAT- und Verbindungseinträge:

sudo conntrack -L

TCP-Einträge zu einem internen Server:

sudo conntrack -L \
  -p tcp \
  -d 192.0.2.25 \
  --dport 443

Ereignisse während eines kontrollierten Tests:

sudo conntrack -E

Zu prüfen sind:

Originalrichtung;
Antwortrichtung;
Quell- und Zielports;
src-nat;
dst-nat;
[UNREPLIED];
[ASSURED];
Timeout;
Paket- und Bytezähler.

Das vollständige Leeren der Conntrack-Tabelle ist keine erste Diagnosemaßnahme.

Cisco Secure Firewall ASA prüfen

NAT-Regeln:

show nat

Details und Treffer:

show nat detail

Übersetzungen:

show xlate

Verbindungen:

show conn

Nach Adresse filtern:

show conn address 192.0.2.25

Routing:

show route

Simulation:

packet-tracer input outside tcp 198.51.100.40 53124 203.0.113.10 8443 detailed

Zu prüfen sind:

passende NAT-Regel;
NAT-Abschnitt und Reihenfolge;
reale und übersetzte Adresse;
externer und interner Port;
ACL;
Route;
Eingangs- und Ausgangsschnittstelle;
Ergebnis jeder Verarbeitungsphase.

Bei aktuellen Cisco-ASA-Regelwerken werden Zugriffsregeln im NAT-Kontext anhand realer Adressen ausgewertet. Dieses Verhalten darf nicht auf andere Produkte übertragen werden.

Cloud-NAT und eingehende Verbindungen

Ein Cloud-NAT-Gateway dient häufig ausschließlich der ausgehenden Kommunikation privater Ressourcen.

Wichtig:

Outbound NAT
ist nicht automatisch
Inbound Port Forwarding

Für eingehende Veröffentlichung können stattdessen erforderlich sein:

öffentliche Instanzadresse;
Load Balancer;
Network Load Balancer;
Application Gateway;
Cloud Firewall DNAT;
Reverse Proxy;
API Gateway;
Ingress Controller;
private Verbindung;
VPN.

AWS NAT Gateway

AWS NAT Gateway erlaubt privaten Ressourcen ausgehende Verbindungen. Es nimmt keine unaufgeforderten eingehenden Internetverbindungen für diese Ressourcen an.

Zu prüfen sind:

public oder private NAT Gateway;
Subnetz;
Routingtabelle;
Internet Gateway;
Elastic IP;
Security Groups der Instanz;
Network ACLs;
Rückverkehr einer ausgehenden Sitzung;
CloudWatch-Metriken.

Eine Portweiterleitung auf ein AWS NAT Gateway ist nicht der vorgesehene Weg zur Veröffentlichung eines privaten Servers.

Mögliche Alternativen:

Application Load Balancer;
Network Load Balancer;
öffentliche Instanzadresse mit Security Group;
AWS Network Firewall beziehungsweise geeignete zentrale Firewall;
API Gateway;
VPN oder PrivateLink, abhängig vom Anwendungsfall.

Azure NAT Gateway

Azure NAT Gateway stellt ausgehende Internetkonnektivität für ein Subnetz bereit. Unaufgeforderte eingehende Internetverbindungen werden nicht bereitgestellt. DNAT wird nur für Antwortpakete einer zuvor ausgehend aufgebauten Kommunikation angewendet.

Für eingehende Veröffentlichung können je nach Anforderung verwendet werden:

Azure Load Balancer;
Application Gateway;
Azure Firewall DNAT;
öffentliche IP-Adresse einer Ressource;
API Management;
Front Door;
privater Endpunkt;
VPN.

Zu prüfen sind:

Subnetzanbindung;
öffentliche NAT-Adressen;
effektive Route;
Azure Firewall;
Load Balancer;
Network Security Group;
User Defined Route;
Zielressource;
Health Probe.

Paketaufzeichnung entlang des NAT-Pfads

Für einen NAT-Nachweis sind mehrere Beobachtungspunkte erforderlich.

Beispiel:

Beobachtungspunkt	Erwarteter Datenfluss
vor Edge-Firewall	`198.51.100.40:53124 -> 203.0.113.10:8443`
nach DNAT	`198.51.100.40:53124 -> 192.0.2.25:443`
am Server	`198.51.100.40:53124 -> 192.0.2.25:443`
Serverantwort	`192.0.2.25:443 -> 198.51.100.40:53124`
nach Rückübersetzung	`203.0.113.10:8443 -> 198.51.100.40:53124`

Mit tcpdump auf dem externen Abschnitt:

sudo tcpdump \
  -ni <WAN-Schnittstelle> \
  'host 198.51.100.40 and host 203.0.113.10 and tcp port 8443'

Auf dem internen Abschnitt:

sudo tcpdump \
  -ni <LAN-Schnittstelle> \
  'host 198.51.100.40 and host 192.0.2.25 and tcp port 443'

Am Server:

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

Die Platzhalter müssen durch autorisierte reale Werte ersetzt werden.

Befund aus Paketaufzeichnungen

WAN-Eingang	LAN-Ausgang	Serverantwort	Einordnung
nein	nein	nein	Problem vor dem NAT-Gerät
ja	nein	nein	NAT-, Firewall- oder Routingproblem
ja	ja	nein	Server, Host-Firewall oder Dienst prüfen
ja	ja	ja, aber nicht am NAT	falscher Rückweg
ja	ja	ja und Rückübersetzung	Clientpfad oder Anwendung prüfen
Hairpin am LAN sichtbar	kein Hairpin-Ausgang	Hairpin NAT fehlt oder passt nicht
DNAT korrekt	falscher interner Port	NAT-Regel korrigieren
Paket erreicht falschen Server	falsches Zielobjekt oder alte Regel	Regel und Objekt prüfen

Hardware-Offloading kann verhindern, dass eine allgemeine Softwareaufzeichnung alle Pakete zeigt. Dann sind herstellerspezifische Captures, SPAN oder TAP erforderlich.

Porttest richtig ausführen

Windows:

Test-NetConnection `
  -ComputerName "203.0.113.10" `
  -Port 8443 `
  -InformationLevel Detailed

Linux und macOS:

nc -vz 203.0.113.10 8443

HTTPS mit FQDN:

curl \
  -v \
  https://app.example.test:8443/

Ein TCP-Porttest beweist nur den TCP-Aufbau bis zu der Komponente, die antwortet. Er beweist nicht:

richtigen Backendserver;
korrekte Anwendung;
gültiges TLS-Zertifikat;
korrekten Hostheader;
funktionierende Authentifizierung;
funktionierende Datenbank;
korrekte UDP-Weiterleitung.

Ein UDP-Test benötigt eine anwendungsspezifische Antwort, Protokollauswertung oder Paketaufzeichnung.

Externer Test

Ein externer Test muss aus einem tatsächlich unabhängigen Netz erfolgen.

Mögliche Testsysteme:

autorisierter Server in einem anderen Standort;
freigegebene Cloud-VM;
Mobilfunkverbindung ohne WLAN;
externer Monitoringstandort;
vereinbarter Testhost eines Dienstleisters.

Zu dokumentieren sind:

externe Quelladresse;
Zeitpunkt;
DNS-Ergebnis;
Zieladresse;
Zielport;
Protokoll;
Ergebnis;
Firewalllog;
NAT-Regeltreffer;
Serversicht.

Öffentliche Portscan-Webseiten sollten nicht unkontrolliert für interne oder sensible Dienste verwendet werden.

NAT-Protokollierung

Ein geeigneter NAT- oder Firewalllogeintrag enthält möglichst:

Zeitstempel;
Eingangs- und Ausgangsschnittstelle;
Quellzone;
Zielzone;
Original-Quelladresse;
Original-Quellport;
Original-Zieladresse;
Original-Zielport;
übersetzte Quelladresse;
übersetzter Quellport;
übersetzte Zieladresse;
übersetzter Zielport;
Protokoll;
NAT-Regel;
Sicherheitsregel;
Sitzungs-ID;
Aktion;
Pakete;
Bytes;
Sitzungsendgrund.

Ein fehlender NAT-Logeintrag kann bedeuten:

Datenverkehr erreicht das Gerät nicht;
Logging ist deaktiviert;
falscher Clusterknoten wird geprüft;
falscher virtueller Kontext wird geprüft;
andere NAT-Regel trifft;
Paket wird vor NAT verworfen;
Sitzung bestand bereits;
Hardware-Offload verwendet andere Zähler.

Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Die Portweiterleitung 203.0.113.10:8443 zeigt korrekt auf
192.0.2.25:443. Interne Clients können die öffentliche Adresse
jedoch nicht verwenden, weil die Firewall kein Hairpin NAT für
dieselbe interne Zone ausführt.

Erwarteter Befund:
Der interne Direktzugriff auf 192.0.2.25:443 funktioniert.
Ein externer Zugriff auf 203.0.113.10:8443 funktioniert.
Beim internen Zugriff auf 203.0.113.10:8443 steigt der Trefferzähler
der normalen WAN-DNAT-Regel nicht oder der Rückverkehr umgeht die
NAT-Sitzung.

Gegenbeweis:
Der Hairpin-Datenfluss wird nachweislich übersetzt, Hin- und
Rückverkehr durchlaufen dieselbe NAT-Sitzung und die Antwort erreicht
den Client mit der erwarteten öffentlichen Quelladresse.

Testmethode:
Drei getrennte Zugriffe über interne Adresse, öffentliche Adresse
von intern und öffentliche Adresse von extern durchführen.
NAT-Zähler, Sitzungstabelle und Paketaufzeichnung korrelieren.

Risiko:
Nur lesende Diagnose und kontrollierte Verbindungstests.

Erfolgskriterium:
Fehler ist eindeutig auf Hairpin-Verarbeitung, Rückweg oder eine
nachgelagerte Anwendungsebene begrenzt.

Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko	Rückweg
DNAT-Ziel korrigieren	falsche interne Adresse nachgewiesen	anderes System wird veröffentlicht	alte Zieladresse wiederherstellen
externen Port korrigieren	falscher Port bestätigt	Clients müssen neuen Port verwenden	alten Port wiederherstellen
internen Port korrigieren	tatsächlicher Listener nachgewiesen	falscher Dienst kann erreicht werden	alten Zielport wiederherstellen
Protokoll korrigieren	TCP-/UDP-Abweichung bestätigt	zusätzliche Erreichbarkeit	alte Protokollregel
Quellbereich einschränken	zulässige Quellen bekannt	legitime Quellen können fehlen	vorherigen Bereich wiederherstellen
Rückroute korrigieren	asymmetrischer Rückweg bestätigt	weitere Ziele betroffen	alte Route wiederherstellen
Hairpin DNAT ergänzen	interner öffentlicher Zugriff erforderlich	zusätzlicher interner Pfad	Regel entfernen
Hairpin SNAT ergänzen	direkter Rückweg verhindert Sitzung	ursprüngliche Client-IP geht verloren	SNAT-Regel entfernen
Split DNS einrichten	interner Direktpfad freigegeben	interner Pfad unterscheidet sich extern	vorherige DNS-Antwort
Host-Firewall korrigieren	Serverdrop bestätigt	zusätzliche Angriffsfläche	alte Regel
Containerport korrigieren	Host-/Containerabweichung bestätigt	Dienst wird anders veröffentlicht	alte Portzuordnung
Reverse-Proxy-Ziel korrigieren	falsches Backend bestätigt	Anwendungspfad verändert sich	alte Proxykonfiguration
öffentliche IPv4 bereitstellen	CGNAT bestätigt und fachlich erforderlich	Kosten und größere Angriffsfläche	Vertrag oder Zuweisung zurücknehmen
NAT-Regelreihenfolge korrigieren	Überschattung nachgewiesen	andere Datenflüsse betroffen	alte Reihenfolge

Vollständiger Diagnoseablauf

Exakte Fehlermeldung erfassen.
Datum, Uhrzeit und Zeitzone dokumentieren.
Betroffene Anwendung bestimmen.
FQDN dokumentieren.
DNS-A- und AAAA-Antworten prüfen.
tatsächlich verwendete Zieladresse bestimmen.
TCP, UDP oder anderes Protokoll bestimmen.
externen Zielport bestimmen.
internen Zielport bestimmen.
externe Quelladresse dokumentieren.
öffentliche Zieladresse dokumentieren.
internes Ziel dokumentieren.
Vor-NAT-Tupel dokumentieren.
Nach-NAT-Tupel dokumentieren.
Umfang der Störung bestimmen.
interne Direktverbindung testen.
internen Zugriff über öffentliche Adresse testen.
tatsächlich externen Zugriff testen.
WAN-Adresse des Edge-Geräts prüfen.
vorgeschaltetes NAT oder CGNAT prüfen.
doppeltes NAT berücksichtigen.
richtige Eingangsschnittstelle bestimmen.
richtige öffentliche Zieladresse bestimmen.
aktive NAT-Konfiguration prüfen.
NAT-Regelreihenfolge prüfen.
NAT-Regeltreffer dokumentieren.
Firewallregel getrennt prüfen.
Routing zum internen Ziel prüfen.
Host-Firewall prüfen.
Listener des Serverdienstes prüfen.
Serverantwort und Rückroute prüfen.
NAT-Sitzung oder Translation Table prüfen.
Hin- und Rückverkehr vergleichen.
Hairpin-Unterstützung prüfen.
Hairpin-DNAT und gegebenenfalls SNAT prüfen.
Split-DNS-Verhalten berücksichtigen.
Reverse Proxy oder Load Balancer prüfen.
Container-Hostport und Containerport prüfen.
Kubernetes-Servicepfad berücksichtigen.
automatische Portabbildungen prüfen.
ALG oder NAT-Helper berücksichtigen.
IPv4 und IPv6 getrennt prüfen.
Cloud-NAT und Inbound-Komponente unterscheiden.
bei Bedarf Paketaufzeichnung vor und nach NAT durchführen.
Hypothese und Gegenbeweis formulieren.
genau eine kontrollierte Maßnahme vorbereiten.
Risiko, Rückweg und Erfolgskriterium dokumentieren.
Maßnahme freigeben und umsetzen.
neue Sitzung aufbauen.
internen, Hairpin- und externen Test wiederholen.
NAT-, Firewall- und Anwendungslogs verifizieren.
weitere repräsentative Quellen testen.
temporäre Regeln und Captures zurücknehmen.
Ursache, Maßnahme und Prävention dokumentieren.

Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
interne Adresse funktioniert, öffentliche intern nicht	Hairpin NAT oder Split DNS	Hairpin-Sitzung und Rückweg prüfen
öffentliche Adresse extern funktioniert	DNAT und externer Pfad grundsätzlich aktiv	internen Hairpin-Pfad getrennt prüfen
öffentliche Adresse extern nicht erreichbar	Provider, CGNAT, WAN, DNAT oder Firewall	WAN-IP und NAT-Regeltreffer
NAT-Regelzähler bleibt null	falsche IP, Schnittstelle, Port oder Pfad	Capture vor dem NAT-Gerät
NAT-Regel trifft, Firewall blockiert	getrennte Sicherheitsrichtlinie	Firewalllog und Adressphase
NAT und Firewall erlauben, Server antwortet nicht	Host-Firewall, Listener oder Dienst	serverseitiges Capture
Server antwortet, NAT sieht Antwort nicht	falsche Rückroute	Serverroute und Gateway
Rückantwort besitzt private Quelladresse	fehlende Rückübersetzung oder Hairpin-Asymmetrie	NAT-Sitzung und Pfad
WAN-Adresse ist privat	vorgeschaltetes NAT	Upstreamgerät prüfen
WAN-Adresse liegt in `100.64.0.0/10`	CGNAT wahrscheinlich	Provider und externe Adresse
Router-WAN-IP weicht von externer IP ab	vorgeschaltetes NAT, VPN oder Proxy	vollständigen Ausgangspfad prüfen
TCP funktioniert, UDP nicht	Protokollregel oder UDP-State	UDP-Capture und NAT-Timeout
IPv4 funktioniert, FQDN nicht	AAAA-Pfad oder DNS	A-/AAAA-Antwort vergleichen
externer Port offen, falsche Anwendung	falsches DNAT-Ziel oder Reverse Proxy	Backend und Hostheader prüfen
Docker-Hostport lauscht nicht	Port nicht veröffentlicht oder Container gestoppt	`docker ps` und `docker port`
Hostport lauscht, Container antwortet nicht	Containerdienst oder Zielport	Containerlistener und Logs
Container direkt erreichbar, öffentlich nicht	Router-, Host- oder DNAT-Pfad	schrittweise Porttests
Zugriff nach Routerneustart kurz möglich	Zustand, dynamische Adresse oder Konflikt	Translation Table und WAN-IP
nur manche Quellen funktionieren	Quellfilter oder NAT-Filterverhalten	Regeln und Quelladressen vergleichen
Zugriff über IP, nicht über Namen	DNS, SNI oder Zertifikat	FQDN und TLS-Prüfung
intern anderer Server als extern	Split DNS oder Proxyunterschied	DNS-Antworten und Backend
AWS NAT Gateway sendet ausgehend, kein Inbound	erwartetes Produktverhalten	Load Balancer oder andere Inbound-Komponente
Azure NAT Gateway sendet ausgehend, kein Inbound	erwartetes Produktverhalten	Azure Firewall DNAT oder Load Balancer
nach Regeländerung alte Sitzung bleibt	bestehender Translation State	vollständig neue Sitzung testen
extern klappt nur über einen WAN-Anschluss	NAT-Regel nur an einer Schnittstelle	WAN-Bindung und Routing

Typische Diagnosefehler

NAT als Firewall betrachten.
Vorhandene NAT-Regel als vollständige Freigabe bewerten.
Öffentliche und private Adresse verwechseln.
externen und internen Port verwechseln.
TCP und UDP nicht unterscheiden.
IPv4 und IPv6 nicht getrennt prüfen.
FQDN nicht auf A und AAAA prüfen.
Regel an falscher WAN-Schnittstelle übersehen.
NAT-Regelreihenfolge ignorieren.
alte oder überschattete Regel nicht erkennen.
Rückweg nicht prüfen.
nur Hinrichtung aufzeichnen.
NAT-Sitzung nicht auswerten.
bestehende und neue Sitzung nicht unterscheiden.
interne Direktverbindung als Nachweis externer Erreichbarkeit verwenden.
internen Zugriff auf öffentliche Adresse als externen Test bewerten.
Mobilgerät im WLAN als externes System verwenden.
VPN-Pfad beim externen Test übersehen.
CGNAT nicht berücksichtigen.
100.64.0.0/10 mit normalem RFC-1918-Netz gleichsetzen.
doppeltes NAT übersehen.
DMZ Host oder Exposed Host als schnelle Lösung aktivieren.
Hairpin NAT als überall vorhandene Funktion annehmen.
Split DNS ohne Betrachtung von Proxy und Sicherheitskontrollen einsetzen.
Hairpin-SNAT ohne Auswirkungen auf Clientprotokollierung aktivieren.
NAT als Schutzmechanismus für IPv6 verwenden.
UPnP zur Fehlerbehebung pauschal aktivieren.
automatisch erzeugte Portabbildungen nicht prüfen.
ALG ohne Nachweis deaktivieren oder aktivieren.
Docker-EXPOSE mit Portveröffentlichung verwechseln.
Docker-Hostport und Containerport verwechseln.
-p bei Host-Netzwerkmodus als wirksam annehmen.
Kubernetes Service Port und TargetPort verwechseln.
Cloud NAT Gateway als Inbound-Portweiterleitung behandeln.
erfolgreichen TCP-Handshake als Anwendungserfolg bewerten.
NAT- oder Conntrack-Tabelle vorsorglich leeren.
mehrere NAT- und Firewallregeln gleichzeitig verändern.
temporäre Portweiterleitung aktiv lassen.
Ursache und Sicherheitswirkung nicht dokumentieren.

Verifikation

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

DNS liefert die vorgesehenen Adressen;
Client verwendet die erwartete Adressfamilie;
öffentliche Zieladresse stimmt;
WAN-Adresse stimmt;
vorgeschaltetes NAT ist berücksichtigt;
externes Protokoll stimmt;
externer Port stimmt;
internes Ziel stimmt;
interner Port stimmt;
NAT-Regel trifft;
richtige NAT-Regel trifft;
Regelreihenfolge ist korrekt;
Firewallregel erlaubt nur den benötigten Verkehr;
Quellbereich ist angemessen begrenzt;
internes Routing funktioniert;
Server besitzt die erwartete Adresse;
Serverdienst lauscht;
Host-Firewall erlaubt den benötigten Verkehr;
Rückroute führt über die richtige NAT-Komponente;
NAT-Sitzung enthält korrekte Original- und Antworttupel;
interner Direktzugriff funktioniert;
Hairpin-Zugriff funktioniert, sofern vorgesehen;
Split DNS funktioniert, sofern vorgesehen;
externer Zugriff aus einem unabhängigen Netz funktioniert;
TCP und UDP funktionieren, sofern erforderlich;
IPv4 und IPv6 funktionieren, sofern vorgesehen;
TLS-Zertifikat und SNI stimmen;
Reverse Proxy erreicht das richtige Backend;
Docker-Host- und Containerport stimmen;
Kubernetes Service und Endpoint stimmen;
keine unbeabsichtigte Portveröffentlichung besteht;
keine allgemeine Exposed-Host-Regel aktiv ist;
Logs zeigen die erwartete Quelle und Übersetzung;
Monitoring erkennt Ausfälle;
temporäre Regeln und Captures wurden zurückgenommen;
Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine erfolgreiche Verbindung aus dem internen Netz reicht nicht als Verifikation einer Internet-Portweiterleitung.

Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Datum und Uhrzeit:
<Zeitpunkt mit Zeitzone>

Betroffene Anwendung:
<Anwendung oder Dienst>

FQDN:
<Name>

DNS-Antworten:
<A- und AAAA-Einträge>

Externe Quelle:
<IP-Adresse und Quellport>

Öffentliches Ziel:
<IP-Adresse und Zielport>

Protokoll:
<TCP, UDP oder anderes Protokoll>

Internes Ziel:
<IP-Adresse und Zielport>

Vor-NAT-Tupel:
<Quelle:Port -> Ziel:Port>

Nach-NAT-Tupel:
<Quelle:Port -> Ziel:Port>

NAT-Gerät:
<Name, Clusterknoten und Kontext>

Eingangsschnittstelle:
<Name>

Ausgangsschnittstelle:
<Name>

NAT-Regel:
<Name, ID und Position>

Firewallregel:
<Name und ID>

NAT-Sitzung:
<Original- und Antwortdaten>

WAN-Adresse:
<Adresse>

Extern beobachtete Adresse:
<Adresse>

Vorgeschaltetes NAT:
<ja, nein oder ungeklärt>

CGNAT:
<ja, nein oder ungeklärt>

Rückroute:
<Gateway und Pfad>

Serverlistener:
<Adresse und Port>

Host-Firewall:
<Befund>

Containerzuordnung:
<Routerport -> Hostport -> Containerport>

Reverse Proxy:
<Frontend und Backend>

Interner Direktzugriff:
<Ergebnis>

Interner Zugriff über öffentliche Adresse:
<Ergebnis>

Externer Zugriff:
<Ergebnis>

Paketaufzeichnung:
<Befund vor und nach NAT>

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:
<interner, Hairpin- und externer Test>

Prävention:
<Monitoring, Dokumentation oder Architekturverbesserung>

Checkliste

Schnellreferenz

Aufgabe	Befehl
Windows-NAT-Objekte	`Get-NetNat`
Windows-statische NAT-Abbildungen	`Get-NetNatStaticMapping`
Windows-NAT-Sitzungen	`Get-NetNatSession`
Windows-Routing	`Get-NetRoute`
Windows-Listener	`Get-NetTCPConnection -State Listen`
Windows-DNS A	`Resolve-DnsName -Name "app.example.test" -Type A`
Windows-DNS AAAA	`Resolve-DnsName -Name "app.example.test" -Type AAAA`
Windows-TCP-Porttest	`Test-NetConnection -ComputerName "203.0.113.10" -Port 8443`
Linux-nftables-Regelwerk	`sudo nft list ruleset`
Linux-nftables-Tabellen	`sudo nft list tables`
Linux-nftables mit Handles	`sudo nft -a list ruleset`
Linux-iptables-NAT	`sudo iptables -t nat -L -n -v --line-numbers`
Linux-iptables-NAT-Regeln	`sudo iptables -t nat -S`
Linux-Forwardingregeln	`sudo iptables -L FORWARD -n -v --line-numbers`
Linux-IPv4-Forwarding	`sysctl net.ipv4.ip_forward`
Linux-Conntrack	`sudo conntrack -L`
Linux-Conntrack-Ereignisse	`sudo conntrack -E`
Linux-Listener	`ss -lntp`
Linux/macOS-DNS A	`dig app.example.test A`
Linux/macOS-DNS AAAA	`dig app.example.test AAAA`
Linux/macOS-TCP-Porttest	`nc -vz 203.0.113.10 8443`
HTTPS-Test	`curl -v https://app.example.test:8443/`
Docker-Ports	`docker ps --format 'table {{.Names}}\t{{.Ports}}'`
Docker-Portzuordnung	`docker port <Containername>`
Docker-Details	`docker inspect <Containername>`
Kubernetes-Services	`kubectl get services --all-namespaces -o wide`
Kubernetes-Ingress	`kubectl get ingress --all-namespaces`
Kubernetes-Endpunkte	`kubectl get endpointslices --all-namespaces`
Cisco-ASA-NAT	`show nat`
Cisco-ASA-NAT-Details	`show nat detail`
Cisco-ASA-Übersetzungen	`show xlate`
Cisco-ASA-Verbindungen	`show conn`
Cisco-ASA-Routing	`show route`

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

New-NetNat
Add-NetNatStaticMapping
Remove-NetNat
Remove-NetNatStaticMapping
nft add rule ... dnat ...
nft add rule ... snat ...
nft flush ruleset
iptables -t nat -F
conntrack -F
clear xlate
clear conn
Firewall deaktivieren
Exposed Host aktivieren
DMZ Host aktivieren
alle Ports weiterleiten
UPnP pauschal aktivieren
NAT-PMP pauschal aktivieren
PCP pauschal aktivieren
ALG ungeprüft deaktivieren
ALG ungeprüft aktivieren
Router vorsorglich neu starten
Firewall vorsorglich neu starten
öffentliche Verwaltungsports testweise freigeben
allgemeine any-any-Regel erstellen

Quellen

Standards

Microsoft Windows

Linux Netfilter

Docker und Kubernetes

Cisco

Amazon Web Services

Microsoft Azure

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