Sophos Firewall Live Connections correct interpreteren

Live Connections toont welke verbindingen momenteel actief zijn op Sophos Firewall. De weergave laat snel zien welke client, gebruiker of toepassing verkeer genereert, welke interfaces betrokken zijn en welke firewall- of NAT-regel de sessie verwerkt. Voor één specifieke verbinding biedt Diagnostics > Connection list nog meer technische details.

Beide weergaven zijn momentopnamen. Ze vervangen noch Log Viewer voor vastgelegde beslissingen, noch Packet Capture voor de daadwerkelijke pakketstroom. Correct gecombineerd besparen ze echter veel tijd: zoek eerst de actieve sessie en controleer daarna zo nodig de logs en pakketten.

Live Connections in zeven stappen

1. Leg de testflow vast: bron-IP, doel-IP, protocol, bronpoort voor zover bekend, doelpoort en exact tijdstip.
2. Maak vanaf de testclient een nieuwe verbinding, bijvoorbeeld HTTPS van 192.0.2.25 naar 198.51.100.50 via TCP 443.
3. Open Current activities > Live connections en groepeer op Source IP address.
4. Filter op 192.0.2.25 en open via Total de afzonderlijke verbindingen.
5. Noteer Start time, In interface, Out interface, Source, Destination, poorten, Firewall Rule ID en NAT Rule ID.
6. Filter dezelfde flow onder Diagnostics > Connection list > Display filter zo nauwkeurig mogelijk en vergelijk Translated source, Translated destination, Gateway ID, Policy IDs en RX/TX.
7. Correleer bij afwijkingen de flow in Log Viewer en Packet Capture voordat regels, NAT of routing worden gewijzigd.

De adressen 192.0.2.25 en 198.51.100.50 komen uit documentatienetwerken. Vervang ze voor een echte test door het werkelijke client- en doeladres. TCP 443 is alleen passend wanneer daadwerkelijk een HTTPS-verbinding wordt getest.

⚠️ De weergaven bevatten interne IP-adressen, gebruikersnamen, toepassingen en communicatierelaties. Houd filters en screenshots daarom beperkt en deel supportgegevens alleen met bevoegde ontvangers.

Live Connections en Connection List onderscheiden

De twee weergaven gebruiken de actuele verbindingsstatus, maar zijn voor verschillende vragen bedoeld.

Live Connections voor het overzicht

Onder Current activities > Live connections kunnen actieve verbindingen worden gegroepeerd op:

• Application
• Source IP address
• Username

De weergave toont upload, download, gemiddeld bandbreedtegebruik, eigenschappen en het aantal sessies. Dat helpt bij vragen zoals: welke client genereert op dit moment veel verkeer? Welke toepassing is actief? Welke gebruiker heeft meerdere verbindingen openstaan?

De getoonde overdrachtswaarden gelden voor de tijd sinds de verbinding werd opgebouwd. Upstream bandwidth en Downstream bandwidth worden berekend uit de overgedragen bytes en de verstreken verbindingsduur. Ze vormen daarom geen lijntest per seconde. Voor een prestatietest is iPerf3 correct gebruiken met Sophos Firewall geschikter.

In Live Connections kan slechts één filter tegelijk actief zijn. Het bron-IP is meestal het duidelijkste vertrekpunt. Username of Application is nuttig wanneer de client al correct is geauthenticeerd of de toepassing is herkend.

Connection List voor de afzonderlijke sessie

Onder Diagnostics > Connection list staat elke actuele verbinding op een afzonderlijke regel. Deze weergave is technischer en toont onder andere:

• In interface en Out interface
• Source en Destination met poorten
• Protocol en Application
• Rule ID en NAT ID
• User en User group
• Policy IDs voor Web, Application, IPS, Traffic Shaping en Remote Access
• Gateway ID
• Translated source en Translated destination
• Expiry, RX/TX bytes en RX/TX packets
• Connection served by

De Display filter kan meerdere bekende kenmerken van de testflow bevatten. Daarmee wordt een lange lijst teruggebracht tot een kleine groep passende sessies.

Wat geen van beide weergaven bewijst

Een zichtbare sessie bewijst dat er een actuele connection-tracking-vermelding bestaat. Ze bewijst niet automatisch:

• dat elk verzoek en elk antwoord volledig is overgedragen
• dat de doelserver de toepassing correct heeft verwerkt
• dat een eerdere fout in dezelfde flow nog historisch beschikbaar is
• dat de geselecteerde firewall- of NAT-regel functioneel de juiste is
• dat een groene vermelding geen pakketverlies, retransmissie of MTU-probleem bevat

Voor historische beslissingen zijn logs nodig. Voor ingress, egress, antwoorden en drops is Packet Capture nodig. Voor de toepassing zelf blijven server-, client- of SaaS-logs relevant.

Een gecontroleerde testflow voorbereiden

Een bruikbare test begint niet met een willekeurige browserrefresh. Leg eerst het vijftal vast:

• bron-IP
• doel-IP
• protocol
• bronpoort
• doelpoort

De bronpoort is bij clientverbindingen vaak dynamisch. Als deze nog niet bekend is, zijn bron-IP, doel-IP, protocol en doelpoort voldoende voor het eerste filter. Na de treffer kan de concrete bronpoort uit de sessie worden overgenomen.

Leg daarnaast de verwachtingen vast:

• In interface en Out interface
• Firewall Rule ID en indien van toepassing NAT Rule ID
• gebruiker of gebruikersgroep wanneer de regel identiteit gebruikt
• Gateway of SD-WAN-pad
• verwachte Source en Destination na NAT
• exact testtijdstip met tijdzone

Na wijzigingen altijd een nieuwe verbinding maken

Bestaande sessies behouden hun opgebouwde status. Vooral NAT-beslissingen worden niet voor elk volgend pakket opnieuw genomen. Sluit daarom na een wijziging aan regels, NAT, routing of SD-WAN de toepassingssessie en maak een nieuwe flow.

Een browserrefresh kan dezelfde TCP-, HTTP/2- of HTTP/3-verbinding blijven gebruiken. Voor een betrouwbare acceptatietest helpt een nieuw privévenster, een opnieuw gestart clientproces of een andere gecontroleerde test die zeker een nieuwe verbinding opent. De exacte methode moet bij de toepassing passen en mag geen productiesessie onbedoeld onderbreken.

Live Connections gebruiken voor de eerste treffer

1. Open Current activities > Live connections.
2. Kies een Automatic refresh interval dat bij de test past of werk handmatig bij met Refresh.
3. Selecteer voor een bekende client Source IP address.
4. Open het filter, kies een passende modifier en voer het bron-IP in.
5. Controleer Transfer, Bandwidth en Total in de regel.
6. Klik op het getal onder Total om de afzonderlijke verbindingen in een nieuw tabblad te openen.
7. Identificeer de passende flow aan de hand van Start time, interfaces, IP-adressen, poorten en Protocol.

Een zeer kort DNS-, ICMP- of webverzoek kan al verdwenen zijn voordat de pagina wordt vernieuwd. Stel dan eerst het filter in, bereid Refresh voor en start de test nog precies één keer.

Other applications en DNS correct interpreteren

Other applications bevat niet-herkende toepassingen en door het systeem gegenereerd verkeer, zoals downloads van signatures, consoletoegang of DNS-verzoeken van de firewall zelf. Dit is niet automatisch een foutcategorie.

DNS vraagt extra aandacht: verkeer tussen een interne client en een externe DNS-server valt onder normale firewallregels en verschijnt als DNS. Door de firewall gegenereerd DNS-verkeer kan daarentegen zowel onder DNS als onder Other applications verschijnen.

Als een toepassing niet wordt herkend en Security Heartbeat actief is, kan Connection List aanbieden om Application Information voor verbonden endpoints op te lossen. Zonder verbonden Sophos Endpoint of zonder Heartbeat blijft No information available mogelijk. Een onbekende naam is daarom niet automatisch kwaadaardig verkeer.

Firewall Rule ID 0 is contextafhankelijk

Door het systeem gegenereerd verkeer heeft in Live Connections Firewall Rule ID 0, omdat normale firewallregels dit verkeer niet sturen. Toegang tot lokale firewallservices wordt onder andere geregeld via Administration > Device access en de Local Service ACL. Device Access en Local Service ACL legt de veilige configuratie uit.

Deze 0 mag niet zonder context worden gelezen als een impliciete dropregel. Rule #0 kan in een firewalllog of Packet Capture een andere diagnostische betekenis hebben. Bepalend zijn de weergave, Status, Reason en de vraag of het systeemverkeer of doorgestuurd clientverkeer betreft.

Connection List beperken tot één flow

1. Open Diagnostics > Connection list.
2. Selecteer Display filter.
3. Stel Network protocol in op IPv4 of IPv6, passend bij de test.
4. Voer het bron-IP en doel-IP in.
5. Voeg Packet type en de bron- of doelpoort toe voor zover bekend.
6. Voer de verwachte Rule ID in wanneer specifiek naar de actieve sessies van die regel wordt gezocht.
7. Pas het filter toe met OK en vergelijk de treffers met het testtijdstip.

Een leeg resultaat bewijst niet dat de firewall het verkeer blokkeert. De sessie kan al zijn beëindigd, de client kan via DNS of een CDN een ander doeladres gebruiken, NAT kan het zichtbare adres wijzigen of de test kan door de andere HA-node zijn verwerkt. Controleer eerst de testflow en kijkrichting in plaats van de firewallregel te verruimen.

De belangrijkste velden samen lezen

• Time: begintijd van de verbinding. Deze moet bij de gecontroleerde test passen.
• In interface / Out interface: tonen het ingangs- en uitgangspad dat de sessie gebruikt.
• Source / Destination / Ports: bepalen de zichtbare flow voordat de details worden geïnterpreteerd.
• Rule ID: toont de firewallregel die de sessie toestaat.
• NAT ID: toont de betrokken NAT-regel.
• Translated source / Translated destination: maken SNAT, MASQ, DNAT of PAT zichtbaar.
• Gateway ID: koppelt de sessie aan een gateway en is bijzonder belangrijk bij WAN- of SD-WAN-vragen.
• Username / User group: tonen of de verwachte gebruikerscontext aan de sessie is gekoppeld.
• Policy IDs: tonen welke Web-, Application-, IPS-, Traffic Shaping- of Remote Access-policy is toegewezen.
• Expiry: toont na hoeveel seconden een inactieve sessie verloopt.
• RX/TX bytes en packets: helpen herkennen of slechts één richting gegevens levert of beide richtingen actief zijn.
• Connection served by: toont welke firewall de verbinding in een HA-omgeving verwerkt.

Lees Rule ID en NAT ID altijd samen met interfaces, adressen en poorten. Een verwachte Rule ID met een onverwachte NAT ID wijst op een NAT-matchingprobleem. Kloppen beide ID’s, maar Out interface of Gateway niet, controleer dan vervolgens routing of SD-WAN. NAT op Sophos Firewall legt de basis uit.

Related Connections niet overwaarderen

Een klik op de Connection ID kan afhankelijke verbindingen tonen, bijvoorbeeld bij Web Proxy, FTP, SIP of andere protocollen met samenhangende sessies. Als er geen afhankelijke flow bestaat, blijft de weergave leeg. Een lege Related Connections-weergave is daarom geen bewijs van een fout.

Live sessie, Log Viewer en Packet Capture correleren

De drie hulpmiddelen beantwoorden achtereenvolgens drie verschillende vragen:

1. Live Connections of Connection List: welke sessie bestaat momenteel en welke ID’s, interfaces, adressen, policies en gatewaytoewijzingen bevat deze?
2. Log Viewer: welke firewall-, NAT- of beveiligingsbeslissing is vastgelegd?
3. Packet Capture: komen pakketten aan, worden ze doorgestuurd en keren antwoorden terug?

Voor een betrouwbare vergelijking:

1. Noteer testtijdstip en vijftal.
2. Noteer de actieve sessie en Connection ID.
3. Documenteer Rule ID, NAT ID, In/Out interface, Gateway en vertaalde adressen.
4. Filter Log Viewer op bron, bestemming, poort en tijd.
5. Start bij een ontbrekend antwoord of onduidelijk pad Packet Capture met een nauw BPF-filter.
6. Documenteer het resultaat voordat de configuratie wordt gewijzigd.

Als Live Connections een sessie toont, maar Log Viewer geen passende firewallgebeurtenis weergeeft, controleer dan eerst Log firewall traffic, Local reporting en de filters. De werkwijze staat in Log Viewer toont geen nieuwe logs.

Device Console biedt daarnaast system diagnostics utilities connections. De actuele openbare help documenteert het hulpmiddel, maar niet alle buildafhankelijke opties. Controleer daarom voor gebruik met ? de beschikbare syntaxis en gebruik de uitvoer alleen-lezen. Sophos Firewall CLI-troubleshooting beschrijft de veilige grens.

Typische symptomen

De verwachte sessie verschijnt niet

Controleer eerst of de flow nog actief is en of bron, bestemming en IP-versie kloppen. Bij DNS, CDN, proxy, NAT of IPv6 kan het werkelijke doeladres afwijken van de aanname. Maak een nieuwe test en start parallel Packet Capture wanneer onduidelijk is of de firewall überhaupt pakketten ontvangt.

De verkeerde Rule ID of NAT ID is zichtbaar

Een algemenere regel hoger in de lijst kan winnen. Vergelijk de volgorde van firewall- en NAT-regels, zones, bron, bestemming, service, gebruiker en tijdschema. Verplaats niet meerdere regels tegelijk. De begeleide werkwijze staat in Een Sophos Firewall-regel correct testen.

Slechts één richting telt RX of TX op

Dit kan wijzen op een ontbrekend retourpad, verkeerde NAT-vertaling, een probleem met het doelsysteem of de lokale firewall van de server. Controleer interfaces, vertaalde adressen en gateway en zoek daarna beide richtingen in Packet Capture. Eén teller alleen bewijst de oorzaak niet.

De waarden veranderen niet na een configuratiewijziging

Waarschijnlijk wordt nog de bestaande sessie getoond. Sluit de clientverbinding correct, maak een nieuwe flow en controleer Start time en Connection ID opnieuw. Gebruik geen globale sessieflush of servicerestart als normale eerste test.

In HA ontbreekt de sessie of passende logvermelding

Noteer Connection served by en houd rekening met de node die het verkeer op het moment van de gebeurtenis verwerkte. Logs worden lokaal op elke HA-node opgeslagen en niet volledig tussen de nodes gesynchroniseerd. Leid geen ononderbroken sessievoortzetting af uit een zichtbare Connection List. Sophos Firewall HA configureren legt de grenzen uit.

Other applications is ongewoon groot

Groepeer eerst op bron-IP en open de afzonderlijke sessies. Niet-herkende toepassingen, systeemverkeer en verschillende oorzaken kunnen in deze groep samenkomen. Controleer Rule ID, doelen, poorten, gebruiker en toepassingscontext voordat dit als een beveiligingsincident wordt beschouwd.

Checklist

• Bron, bestemming, protocol, poorten en testtijdstip zijn bekend.
• Voor de test is een nieuwe verbinding gemaakt.
• Live Connections is zinvol gegroepeerd op bron-IP, gebruiker of toepassing.
• Start time, In/Out interface, Rule ID en NAT ID komen overeen met de verwachting.
• Translated source/destination en Gateway ID passen bij het geplande pad.
• User en Policy IDs werden alleen verwacht wanneer de bijbehorende herkenning actief is.
• Rule ID 0 is in de juiste context van systeemverkeer gelezen.
• Bij HA is Connection served by gedocumenteerd.
• Log Viewer en waar nodig Packet Capture bevestigen de sessie.
• Er is geen globale sessieflush of servicerestart als eerste diagnosepoging uitgevoerd.

Veelgestelde vragen