Sophos Firewall Live Connections richtig lesen

Live Connections zeigt, welche Verbindungen auf der Sophos Firewall gerade aktiv sind. Die Ansicht beantwortet schnell, welcher Client, Benutzer oder welche Anwendung Traffic erzeugt, welche Interfaces beteiligt sind und welche Firewall- oder NAT-Regel die Session verarbeitet. Für eine einzelne Verbindung liefert Diagnostics > Connection list noch mehr technische Details.

Beide Ansichten sind Momentaufnahmen. Sie ersetzen weder den Log Viewer für protokollierte Entscheidungen noch Packet Capture für den tatsächlichen Paketfluss. Richtig kombiniert sparen sie aber viel Zeit: Zuerst findet man die aktive Session, danach prüft man bei Bedarf Logs und Pakete.

Live Connections in sieben Schritten

1. Testflow festlegen: Source IP, Destination IP, Protokoll, Source Port soweit bekannt, Destination Port und genaue Uhrzeit.
2. Vom Testclient eine neue Verbindung erzeugen, beispielsweise HTTPS von 192.0.2.25 zu 198.51.100.50 auf TCP 443.
3. Current activities > Live connections öffnen und nach Source IP address gruppieren.
4. Nach 192.0.2.25 filtern und über Total die einzelnen Verbindungen öffnen.
5. Start time, In interface, Out interface, Source, Destination, Ports, Firewall Rule ID und NAT Rule ID notieren.
6. Unter Diagnostics > Connection list > Display filter denselben Flow möglichst eng filtern und Translated source, Translated destination, Gateway ID, Policy IDs sowie RX/TX vergleichen.
7. Bei Abweichungen den Flow im Log Viewer und mit Packet Capture korrelieren, bevor Regeln, NAT oder Routing geändert werden.

Die Adressen 192.0.2.25 und 198.51.100.50 stammen aus Dokumentationsnetzen. Für einen echten Test werden sie durch die reale Client- und Zieladresse ersetzt. TCP 443 passt nur, wenn tatsächlich eine HTTPS-Verbindung geprüft wird.

⚠️ Die Ansichten enthalten interne IP-Adressen, Benutzernamen, Anwendungen und Kommunikationsbeziehungen. Filter und Screenshots deshalb eng halten und Supportdaten nur an berechtigte Stellen weitergeben.

Live Connections und Connection List unterscheiden

Die zwei Ansichten greifen auf den aktuellen Verbindungszustand zu, sind aber für unterschiedliche Fragen gebaut.

Live Connections für den Überblick

Unter Current activities > Live connections gruppiert man aktive Verbindungen nach:

• Application
• Source IP address
• Username

Die Ansicht zeigt Upload, Download, durchschnittlich genutzte Bandbreite, Eigenschaften und die Anzahl der Sessions. Das hilft bei Fragen wie: Welcher Client erzeugt gerade viel Traffic? Welche Anwendung ist aktiv? Welcher Benutzer hat mehrere Verbindungen offen?

Die angezeigten Transferwerte beziehen sich auf die Zeit seit dem Aufbau der Verbindung. Upstream bandwidth und Downstream bandwidth werden aus den übertragenen Bytes und der bisherigen Verbindungsdauer berechnet. Sie sind deshalb kein sekundengenauer Leitungstest. Für einen Performance-Test passt iPerf3 auf Sophos Firewall richtig einsetzen besser.

In Live Connections kann jeweils nur ein Filter aktiv sein. Für den ersten Einstieg ist die Source IP meistens am eindeutigsten. Benutzer oder Application sind hilfreich, wenn der Client bereits sauber authentifiziert beziehungsweise die Anwendung erkannt wurde.

Connection List für die einzelne Session

Unter Diagnostics > Connection list sieht man eine Zeile pro aktueller Verbindung. Diese Ansicht ist technischer und zeigt unter anderem:

• In interface und Out interface
• Source und Destination mit Ports
• Protokoll und Application
• Rule ID und NAT ID
• Benutzer und User group
• Web-, Application-, IPS-, Traffic-Shaping- und Remote-Access-Policy-IDs
• Gateway ID
• Translated source und Translated destination
• Expiry, RX/TX bytes und RX/TX packets
• Connection served by

Der Display filter kann mehrere bekannte Merkmale des Testflows aufnehmen. Damit lässt sich die grosse Liste auf einen kleinen Satz passender Sessions reduzieren.

Was keine der beiden Ansichten beweist

Eine sichtbare Session beweist, dass ein aktueller Connection-Tracking-Eintrag vorhanden ist. Sie beweist nicht automatisch:

• dass jeder Request und jede Antwort vollständig übertragen wurde
• dass der Zielserver die Anwendung korrekt verarbeitet
• dass ein früherer Fehler im selben Flow noch historisch verfügbar ist
• dass die ausgewählte Firewall- oder NAT-Regel fachlich richtig ist
• dass ein grüner Eintrag keinen Paketverlust, Retransmit oder MTU-Fehler enthält

Für historische Entscheidungen braucht es Logging. Für Ingress, Egress, Antworten und Drops braucht es Packet Capture. Für die Anwendung selbst bleiben Server-, Client- oder SaaS-Logs relevant.

Einen kontrollierten Testflow vorbereiten

Ein brauchbarer Test beginnt nicht mit einem beliebigen Browser-Reload. Zuerst wird das Fünf-Tupel festgelegt:

• Source IP
• Destination IP
• Protokoll
• Source Port
• Destination Port

Der Source Port ist bei Clientverbindungen oft dynamisch. Wenn er noch nicht bekannt ist, reichen für den ersten Filter Source IP, Destination IP, Protokoll und Destination Port. Nach dem Treffer kann der konkrete Source Port aus der Session übernommen werden.

Zusätzlich werden erwartet:

• In interface und Out interface
• Firewall Rule ID und gegebenenfalls NAT Rule ID
• Benutzer oder Benutzergruppe, falls die Regel Identität verwendet
• Gateway beziehungsweise SD-WAN-Pfad
• erwartete Source und Destination nach NAT
• genaue Testzeit mit Zeitzone

Nach Änderungen immer eine neue Verbindung erzeugen

Bestehende Sessions behalten ihren aufgebauten Zustand. Besonders NAT-Entscheidungen werden nicht für jedes weitere Paket neu getroffen. Nach einer Regel-, NAT-, Routing- oder SD-WAN-Änderung wird deshalb die Anwendungssession beendet und ein neuer Flow erzeugt.

Ein Browser-Reload kann dieselbe TCP-, HTTP/2- oder HTTP/3-Verbindung weiterverwenden. Für eine belastbare Abnahme hilft ein neues privates Browserfenster, ein neu gestarteter Clientprozess oder ein anderer kontrollierter Test, der sicher eine neue Verbindung öffnet. Der genaue Testweg sollte zur Anwendung passen und keine produktive Sitzung unbeabsichtigt unterbrechen.

Live Connections für den ersten Treffer verwenden

1. Current activities > Live connections öffnen.
2. Automatic refresh interval passend zum Test wählen oder manuell mit Refresh aktualisieren.
3. Für einen bekannten Client Source IP address auswählen.
4. Filter öffnen, passenden Modifier wählen und die Source IP eingeben.
5. In der Zeile Transfer, Bandwidth und Total prüfen.
6. Auf die Zahl unter Total klicken, um die einzelnen Verbindungen in einem neuen Tab zu öffnen.
7. Den passenden Flow anhand von Start time, Interfaces, IPs, Ports und Protocol identifizieren.

Bei einem sehr kurzen DNS-, ICMP- oder Webrequest kann die Verbindung bereits verschwunden sein, bevor die Seite aktualisiert wird. Dann den Filter zuerst setzen, Refresh vorbereiten und den Test erneut genau einmal auslösen.

Other applications und DNS richtig einordnen

Other applications enthält nicht erkannte Anwendungen und systemgenerierten Traffic, beispielsweise Signaturdownloads, Console Access oder DNS-Anfragen der Firewall selbst. Das ist keine automatische Fehlerklasse.

DNS braucht zusätzliche Aufmerksamkeit: Traffic zwischen einem internen Client und einem externen DNS-Server unterliegt normalen Firewall-Regeln und erscheint als DNS. Systemgenerierter DNS-Traffic der Firewall kann dagegen sowohl unter DNS als auch unter Other applications auftauchen.

Wenn eine Anwendung nicht erkannt wird und Security Heartbeat aktiv ist, kann die Connection List bei verbundenen Endpoints eine Auflösung der Application Information anbieten. Ohne verbundenen Sophos Endpoint oder ohne Heartbeat bleibt No information available möglich. Ein unbekannter Name ist deshalb nicht automatisch bösartiger Traffic.

Firewall Rule ID 0 ist kontextabhängig

Systemgenerierter Traffic trägt in Live Connections die Firewall Rule ID 0, weil normale Firewall-Regeln diesen Traffic nicht steuern. Für den Zugriff auf lokale Firewall-Dienste sind stattdessen unter anderem Administration > Device access und die Local Service ACL relevant. Die sichere Konfiguration erklärt Device Access und Local Service ACL.

Diese 0 darf nicht ohne Kontext als implizite Drop-Regel gelesen werden. In einem Firewall-Log oder Packet Capture kann Rule #0 einen anderen Diagnosekontext haben. Entscheidend sind Ansicht, Status, Reason und die Frage, ob es sich um Systemtraffic oder weitergeleiteten Clienttraffic handelt.

Connection List auf einen Flow eingrenzen

1. Diagnostics > Connection list öffnen.
2. Display filter wählen.
3. Network protocol auf IPv4 oder IPv6 passend zum Test setzen.
4. Source IP und Destination IP eintragen.
5. Packet type sowie Source oder Destination port ergänzen, soweit bekannt.
6. Erwartete Rule ID eintragen, wenn gezielt deren aktive Sessions gesucht werden.
7. Mit OK filtern und die Treffer gegen die Testzeit prüfen.

Ein leerer Filter ist kein Beweis, dass die Firewall den Traffic blockiert. Die Session kann schon beendet sein, der Client kann eine andere Zieladresse aus DNS oder CDN verwenden, NAT kann die sichtbare Adresse verändern oder der Test kann auf dem anderen HA-Knoten verarbeitet worden sein. Dann zuerst den Testflow und die Blickrichtung prüfen, nicht die Firewall-Regel vergrössern.

Die wichtigsten Felder gemeinsam lesen

• Time: Startzeit der Verbindung. Sie muss zum kontrollierten Test passen.
• In interface / Out interface: zeigen den von der Session verwendeten Eingangs- und Ausgangspfad.
• Source / Destination / Ports: definieren den sichtbaren Flow vor der Detailinterpretation.
• Rule ID: zeigt die Firewall-Regel, welche die Session erlaubt.
• NAT ID: zeigt die beteiligte NAT-Regel.
• Translated source / Translated destination: machen SNAT, MASQ, DNAT oder PAT sichtbar.
• Gateway ID: ordnet die Session einem Gateway zu und ist bei WAN- oder SD-WAN-Fragen besonders wichtig.
• Username / User group: zeigen, ob der erwartete Benutzerkontext an der Session hängt.
• Policy IDs: zeigen, welche Web-, Application-, IPS-, Traffic-Shaping- oder Remote-Access-Policy zugeordnet ist.
• Expiry: zeigt, nach wie vielen Sekunden eine inaktive Session verfällt.
• RX/TX bytes und packets: helfen zu erkennen, ob nur eine Richtung Daten liefert oder beide Richtungen aktiv sind.
• Connection served by: zeigt in HA-Umgebungen, welche Firewall die Verbindung verarbeitet.

Rule ID und NAT ID werden immer zusammen mit Interfaces, Adressen und Ports gelesen. Eine erwartete Rule ID mit einer unerwarteten NAT ID ist ein NAT-Matching-Problem. Stimmen beide IDs, aber das Out interface oder Gateway nicht, liegt die nächste Prüfung bei Routing oder SD-WAN. Die Grundlagen erklärt NAT auf Sophos Firewall.

Related Connections nicht überbewerten

Ein Klick auf die Connection ID kann abhängige Verbindungen zeigen, beispielsweise bei Web Proxy, FTP, SIP oder anderen Protokollen mit zusammengehörigen Sessions. Ist kein abhängiger Flow vorhanden, bleibt die Ansicht leer. Eine leere Related-Connections-Ansicht ist deshalb kein Fehlernachweis.

Live Session, Log Viewer und Packet Capture korrelieren

Die drei Werkzeuge beantworten nacheinander drei verschiedene Fragen:

1. Live Connections oder Connection List: Welche Session ist aktuell vorhanden und welche IDs, Interfaces, Adressen, Policies und Gateway-Zuordnungen trägt sie?
2. Log Viewer: Welche Firewall-, NAT- oder Security-Entscheidung wurde protokolliert?
3. Packet Capture: Kommen die Pakete an, werden sie weitergeleitet und kehren Antworten zurück?

Für einen belastbaren Abgleich:

1. Testzeit und Fünf-Tupel festhalten.
2. Aktive Session und Connection ID notieren.
3. Rule ID, NAT ID, In/Out interface, Gateway und übersetzte Adressen dokumentieren.
4. Im Log Viewer nach Source, Destination, Port und Zeit filtern.
5. Bei fehlender Antwort oder unklarem Pfad Packet Capture mit engem BPF-Filter starten.
6. Ergebnis dokumentieren, bevor eine Konfiguration geändert wird.

Wenn Live Connections eine Session zeigt, aber im Log Viewer kein passender Firewall-Event erscheint, zuerst Log firewall traffic, Local reporting und die Filter prüfen. Der Ablauf steht in Log Viewer zeigt keine neuen Logs.

Die Device Console bietet zusätzlich system diagnostics utilities connections. Die aktuelle öffentliche Hilfe dokumentiert das Werkzeug, aber nicht alle buildabhängigen Optionen. Vor einer Verwendung deshalb mit ? die verfügbare Syntax prüfen und die Ausgabe nur lesend nutzen. Für den sicheren CLI-Rahmen passt Sophos Firewall CLI Troubleshooting.

Typische Fehlerbilder

Die erwartete Session erscheint nicht

Zuerst prüfen, ob der Flow wirklich noch aktiv ist und ob Source, Destination und IP-Version stimmen. Bei DNS, CDN, Proxy, NAT oder IPv6 kann die tatsächliche Zieladresse von der Annahme abweichen. Einen neuen Test erzeugen und parallel Packet Capture starten, wenn unklar ist, ob die Firewall überhaupt Pakete erhält.

Die falsche Rule ID oder NAT ID ist sichtbar

Eine allgemeinere Regel gewinnt möglicherweise weiter oben. Firewall- und NAT-Reihenfolge, Zonen, Source, Destination, Service, Benutzer und Zeitplan vergleichen. Nicht mehrere Regeln gleichzeitig verschieben. Der geführte Ablauf steht unter Sophos Firewall-Regel sauber testen.

Nur eine Richtung zählt RX oder TX

Das kann auf einen fehlenden Rückweg, eine falsche NAT-Übersetzung, ein Zielsystemproblem oder eine lokale Server-Firewall hindeuten. Interfaces, übersetzte Adressen und Gateway prüfen und danach beide Richtungen im Packet Capture suchen. Ein Zähler allein beweist die Ursache nicht.

Die Werte ändern sich nach einer Konfigurationsänderung nicht

Wahrscheinlich wird noch die bestehende Session betrachtet. Clientverbindung sauber beenden, neuen Flow erzeugen und Start time sowie Connection ID erneut prüfen. Kein globales Session-Flush und keinen Service-Neustart als normalen ersten Test verwenden.

In HA fehlt die Session oder der passende Logeintrag

Connection served by notieren und den Knoten berücksichtigen, der den Traffic zum Ereigniszeitpunkt verarbeitet hat. Logs liegen auf jedem HA-Knoten lokal und werden nicht vollständig zwischen den Nodes synchronisiert. Keine unterbrechungsfreie Sessionfortsetzung aus der sichtbaren Connection List ableiten. Die Grenzen erklärt Sophos Firewall HA einrichten.

Other applications ist ungewöhnlich gross

Zuerst nach Source IP gruppieren und die einzelnen Sessions öffnen. Nicht erkannte Anwendungen, Systemtraffic und mehrere unterschiedliche Ursachen können in dieser Gruppe zusammenlaufen. Erst Rule ID, Ziele, Ports, Benutzer und Anwendungskontext prüfen, bevor daraus ein Security Incident abgeleitet wird.

Checkliste

• Source, Destination, Protokoll, Ports und Testzeit sind bekannt.
• Eine neue Verbindung wurde für den Test erzeugt.
• Live Connections wurde nach Source IP, Benutzer oder Application sinnvoll gruppiert.
• Start time, In/Out interface, Rule ID und NAT ID stimmen zur Erwartung.
• Translated source/destination und Gateway ID passen zum geplanten Pfad.
• Benutzer und Policy IDs wurden nur erwartet, wenn die entsprechende Erkennung aktiv ist.
• Rule ID 0 wurde im richtigen Systemtraffic-Kontext gelesen.
• Bei HA wurde Connection served by dokumentiert.
• Log Viewer und bei Bedarf Packet Capture bestätigen die Session.
• Es wurde kein globales Session-Flush oder Service-Restart als erster Diagnoseversuch ausgeführt.

Häufige Fragen