Read your firewall activity

The Activity tab on the Firewall page shows what the firewall recently did with traffic aimed at your servers. The Logs section collects the same information across everything you own.

You’ll use it for two different jobs: checking whether traffic you want is arriving, and getting a sense of the traffic you don’t.

What you’re looking at

Each entry is one decision the firewall made — the source it came from, the destination and port it was aimed at, and whether it was allowed or blocked.

Only traffic involving your own addresses appears. Activity is also scoped to the period each address has been yours, so if an address was assigned to someone else before you, their traffic never shows up in your view.

A page full of “blocked” is normal

This surprises people, so it’s worth being direct: blocked entries are the firewall working.

Any address exposed to the internet is scanned continuously, within minutes of coming online. Most of what you see will be automated attempts on SSH, database ports and known-vulnerable paths, from hosts you have no relationship with. Every one of them being blocked is the desired outcome, not an incident.

What deserves attention is the opposite:

traffic allowed to a port you didn’t mean to expose
traffic allowed from somewhere unexpected on an administrative port like 22 or 3389
a sudden change in volume aimed at one service

If SSH is open to the whole internet, narrowing it to the addresses you actually connect from will quiet most of the noise. See Route traffic to your server.

Using it to debug a connection

Activity answers one question precisely: did my traffic reach the firewall, and what happened to it? Try the connection, then look.

Your attempt appears, blocked. The traffic arrived and a rule stopped it. Add or widen a rule.

Your attempt appears, allowed — but the connection still fails. The firewall did its part, so the problem is beyond it: the service isn’t listening, or the server’s own firewall (ufw, firewalld) is refusing it. Check from the console.

Your attempt doesn’t appear at all. It never got to your server’s edge. Usually the traffic was never translated — check the NAT mapping or port forward. If you’re testing by domain name, confirm DNS resolves to the right address; you may be connecting somewhere else entirely.

What it doesn’t show

Traffic inside your private network. Servers talking directly to each other don’t pass the edge firewall, so those connections aren’t listed.

What was in the traffic. This is a record of connections, not contents. For attack patterns within traffic that was allowed through, see WAF and intrusion detection.

Your application’s own logs. A request that reached your web server and got a 500 back is a success as far as the firewall is concerned. Application errors live in the application’s logs.