Read Sophos Firewall Live Connections correctly

Live Connections shows which connections are currently active on Sophos Firewall. The view quickly answers which client, user, or application is generating traffic, which interfaces are involved, and which firewall or NAT rule is processing the session. For an individual connection, Diagnostics > Connection list provides even more technical detail.

Both views are snapshots. They replace neither Log Viewer for recorded decisions nor Packet Capture for the actual packet flow. Used together correctly, however, they save a great deal of time: first find the active session, then check logs and packets when necessary.

Live Connections in seven steps

1. Define the test flow: source IP, destination IP, protocol, source port if known, destination port, and exact time.
2. Generate a new connection from the test client, for example HTTPS from 192.0.2.25 to 198.51.100.50 on TCP 443.
3. Open Current activities > Live connections and group by Source IP address.
4. Filter for 192.0.2.25 and open the individual connections through Total.
5. Record Start time, In interface, Out interface, Source, Destination, ports, Firewall Rule ID, and NAT Rule ID.
6. Under Diagnostics > Connection list > Display filter, filter the same flow as narrowly as possible and compare Translated source, Translated destination, Gateway ID, policy IDs, and RX/TX.
7. If anything differs from the plan, correlate the flow in Log Viewer and Packet Capture before changing rules, NAT, or routing.

The addresses 192.0.2.25 and 198.51.100.50 come from documentation networks. For a real test, replace them with the actual client and destination addresses. TCP 443 only fits when an HTTPS connection is actually being tested.

⚠️ The views contain internal IP addresses, usernames, applications, and communication relationships. Keep filters and screenshots narrow, and only share support data with authorised recipients.

Distinguish Live Connections from Connection List

The two views access the current connection state, but they are designed for different questions.

Live Connections for the overview

Under Current activities > Live connections, group active connections by:

• Application
• Source IP address
• Username

The view shows upload, download, average bandwidth use, characteristics, and the number of sessions. It helps answer questions such as: Which client is generating a lot of traffic right now? Which application is active? Which user has several connections open?

The displayed transfer values cover the period since the connection was established. Upstream bandwidth and Downstream bandwidth are calculated from the transferred bytes and the connection duration so far. They are therefore not a second-by-second line test. For performance testing, use iPerf3 correctly with Sophos Firewall.

Only one filter can be active at a time in Live Connections. The source IP is usually the clearest starting point. Username or Application is useful when the client is already authenticated correctly or the application has been identified.

Connection List for the individual session

Under Diagnostics > Connection list, each current connection appears on its own row. This view is more technical and includes information such as:

• In interface and Out interface
• Source and Destination with ports
• Protocol and Application
• Rule ID and NAT ID
• User and User group
• Web, Application, IPS, Traffic Shaping, and Remote Access policy IDs
• Gateway ID
• Translated source and Translated destination
• Expiry, RX/TX bytes, and RX/TX packets
• Connection served by

The Display filter can contain several known characteristics of the test flow. This reduces a large list to a small set of matching sessions.

What neither view proves

A visible session proves that a current connection-tracking entry exists. It does not automatically prove:

• that every request and response was transferred completely
• that the destination server processed the application correctly
• that an earlier error in the same flow is still available historically
• that the selected firewall or NAT rule is the correct business rule
• that a green entry contains no packet loss, retransmission, or MTU issue

Historical decisions require logging. Ingress, egress, replies, and drops require Packet Capture. Server, client, or SaaS logs remain relevant for the application itself.

Prepare a controlled test flow

A useful test does not begin with an arbitrary browser refresh. First define the five-tuple:

• Source IP
• Destination IP
• Protocol
• Source port
• Destination port

The source port is often dynamic for client connections. If it isn’t known yet, source IP, destination IP, protocol, and destination port are sufficient for the first filter. After finding the entry, take the specific source port from the session.

Also define the expected:

• In interface and Out interface
• Firewall Rule ID and, where applicable, NAT Rule ID
• User or user group if the rule uses identity
• Gateway or SD-WAN path
• Source and Destination after NAT
• Exact test time and time zone

Always create a new connection after changes

Existing sessions retain the state established for them. In particular, NAT decisions aren’t evaluated again for every subsequent packet. After changing a rule, NAT, routing, or SD-WAN, therefore close the application session and generate a new flow.

A browser refresh may continue to use the same TCP, HTTP/2, or HTTP/3 connection. A new private browser window, a restarted client process, or another controlled test that definitely opens a new connection helps with reliable acceptance testing. The exact method should suit the application and must not unintentionally interrupt a production session.

Use Live Connections to find the first entry

1. Open Current activities > Live connections.
2. Select an Automatic refresh interval suitable for the test, or update manually with Refresh.
3. Select Source IP address for a known client.
4. Open the filter, choose a suitable modifier, and enter the source IP.
5. Check transfer, bandwidth, and Total on the row.
6. Click the number under Total to open the individual connections in a new tab.
7. Identify the matching flow from Start time, interfaces, IP addresses, ports, and Protocol.

A very short DNS, ICMP, or web request may already have disappeared before the page refreshes. In that case, set the filter first, prepare Refresh, and trigger the test exactly once again.

Interpret Other applications and DNS correctly

Other applications contains unidentified applications and system-generated traffic, such as signature downloads, console access, or DNS requests generated by the firewall. It is not automatically an error class.

DNS requires extra attention: traffic between an internal client and an external DNS server is subject to normal firewall rules and appears as DNS. System-generated DNS traffic from the firewall can appear under both DNS and Other applications.

If an application is unidentified and Security Heartbeat is enabled, Connection List can offer to resolve Application Information for connected endpoints. Without a connected Sophos Endpoint or without Heartbeat, No information available remains possible. An unknown name is therefore not automatically malicious traffic.

Firewall Rule ID 0 depends on context

System-generated traffic has Firewall Rule ID 0 in Live Connections because normal firewall rules don’t control that traffic. Access to local firewall services is instead controlled, among other things, by Administration > Device access and the Local Service ACL. Device Access and Local Service ACL explains the secure configuration.

Do not read this 0 out of context as an implicit drop rule. Rule #0 in a firewall log or Packet Capture may have a different diagnostic context. The decisive details are the view, Status, Reason, and whether the traffic is system-generated or forwarded client traffic.

Narrow Connection List to one flow

1. Open Diagnostics > Connection list.
2. Select Display filter.
3. Set Network protocol to IPv4 or IPv6 to match the test.
4. Enter the source IP and destination IP.
5. Add Packet type and source or destination port where known.
6. Enter the expected Rule ID when looking specifically for active sessions using that rule.
7. Apply the filter with OK and compare the results with the test time.

An empty result doesn’t prove that the firewall is blocking the traffic. The session may already have ended, the client may be using a different destination address obtained through DNS or a CDN, NAT may change the visible address, or the test may have been processed by the other HA node. Check the test flow and viewing direction first instead of broadening the firewall rule.

Read the most important fields together

• Time: The connection start time. It must match the controlled test.
• In interface / Out interface: show the inbound and outbound path used by the session.
• Source / Destination / Ports: define the visible flow before interpreting details.
• Rule ID: shows the firewall rule that permits the session.
• NAT ID: shows the NAT rule involved.
• Translated source / Translated destination: make SNAT, MASQ, DNAT, or PAT visible.
• Gateway ID: assigns the session to a gateway and is particularly important for WAN or SD-WAN questions.
• Username / User group: show whether the expected user context is attached to the session.
• Policy IDs: show the assigned Web, Application, IPS, Traffic Shaping, or Remote Access policy.
• Expiry: shows after how many seconds an idle session expires.
• RX/TX bytes and packets: help identify whether only one direction carries data or both directions are active.
• Connection served by: shows which firewall processes the connection in an HA environment.

Always read Rule ID and NAT ID together with the interfaces, addresses, and ports. An expected Rule ID with an unexpected NAT ID indicates a NAT matching issue. If both IDs match but the Out interface or gateway doesn’t, investigate routing or SD-WAN next. NAT on Sophos Firewall explains the fundamentals.

Don’t overinterpret Related Connections

Clicking the Connection ID can show dependent connections, for example with Web Proxy, FTP, SIP, or other protocols that create related sessions. If no dependent flow exists, the view remains empty. An empty Related Connections view is therefore not evidence of an error.

Correlate the live session, Log Viewer, and Packet Capture

The three tools answer three different questions in sequence:

1. Live Connections or Connection List: Which session currently exists, and which IDs, interfaces, addresses, policies, and gateway assignments does it carry?
2. Log Viewer: Which firewall, NAT, or security decision was recorded?
3. Packet Capture: Do packets arrive, are they forwarded, and do replies return?

For a reliable comparison:

1. Record the test time and five-tuple.
2. Record the active session and Connection ID.
3. Document Rule ID, NAT ID, In/Out interface, gateway, and translated addresses.
4. Filter Log Viewer by source, destination, port, and time.
5. If the reply is missing or the path is unclear, start Packet Capture with a narrow BPF filter.
6. Document the result before changing the configuration.

If Live Connections shows a session but no matching firewall event appears in Log Viewer, first check Log firewall traffic, Local reporting, and the filters. Log Viewer doesn’t show new logs provides the workflow.

Device Console additionally provides system diagnostics utilities connections. The current public help documents the tool but not every build-dependent option. Check the available syntax with ? before use and keep the query read-only. Sophos Firewall CLI troubleshooting explains the safe CLI boundary.

Typical symptoms

The expected session doesn’t appear

First check whether the flow is still active and whether the source, destination, and IP version are correct. With DNS, CDNs, proxies, NAT, or IPv6, the actual destination address may differ from the assumption. Generate a new test and start Packet Capture in parallel if it is unclear whether the firewall receives any packets.

The wrong Rule ID or NAT ID is visible

A more general rule may be winning higher in the list. Compare firewall and NAT order, zones, source, destination, service, user, and schedule. Don’t move several rules at the same time. Test a Sophos Firewall rule properly provides the guided workflow.

Only one direction increments RX or TX

This may indicate a missing return path, incorrect NAT translation, a destination system issue, or the server’s local firewall. Check interfaces, translated addresses, and gateway, then look for both directions in Packet Capture. A counter alone doesn’t prove the cause.

The values don’t change after a configuration change

The view is probably still showing the existing session. Close the client connection cleanly, generate a new flow, and check Start time and Connection ID again. Don’t use a global session flush or service restart as the normal first test.

The session or matching log entry is missing in HA

Record Connection served by and consider the node that processed the traffic at the time of the event. Logs are stored locally on each HA node and aren’t fully synchronised between nodes. Don’t infer uninterrupted session continuity from a visible Connection List. Configure Sophos Firewall HA explains the boundaries.

Other applications is unusually large

First group by source IP and open the individual sessions. Unidentified applications, system traffic, and several different causes can be combined in this group. Check Rule ID, destinations, ports, user, and application context before treating it as a security incident.

Checklist

• Source, destination, protocol, ports, and test time are known.
• A new connection was generated for the test.
• Live Connections was grouped meaningfully by source IP, user, or application.
• Start time, In/Out interface, Rule ID, and NAT ID match the expectation.
• Translated source/destination and Gateway ID match the planned path.
• User and policy IDs were expected only when the corresponding identification is active.
• Rule ID 0 was read in the correct system-traffic context.
• Connection served by was documented for HA.
• Log Viewer and, where necessary, Packet Capture confirm the session.
• No global session flush or service restart was used as the first diagnostic attempt.

Frequently asked questions