Connection tracking

• Back to system main section

Artica can show you, in real time and over time, every network connection the appliance currently knows about: 
how many there are, who opens them, where they go, how much traffic they carry, and how close you are to the kernel's capacity limit. 
This page explains what the feature gives you, when you want it, how to read the dashboard, and how to turn it off on appliances where you would rather not pay its cost.

The feature is built on the Linux kernel's connection tracking subsystem (nf_conntrack) and on the conntrackd daemon. 
Artica reads both and stores a time series so you keep history, not just a live snapshot.

What it gives you

• Capacity headroom at a glance. 
  The kernel refuses new connections once its tracking table is full, and it does so silently — users see random connection failures with nothing in the proxy logs. 
  The dashboard shows the current count against nf_conntrack_max as a percentage, so table exhaustion becomes something you see coming instead of something you diagnose afterwards.
   
• Who is actually using the appliance. 
  Top sources and top destinations rank the busiest IP addresses by number of connections and by bandwidth, computed live from the kernel table. 
  This answers "which machine is saturating us right now" without capturing packets.
   
• History, not just a snapshot. 
  Samples are recorded every minute and rolled up (hourly, daily, monthly), so you can compare today with last week, correlate a slowdown with a connection spike, and keep evidence after the incident is over.
• A connection-lifecycle view. 
  Created, updated and destroyed counters separate "many connections because many arrive" from "many connections because none are being released" — two very different problems.
   
• Per-CPU pressure indicators. 
  Dropped, invalid and failed-insert counters are reported per CPU core, which is where kernel-level congestion shows up first.
   
• No extra agent. 
  Everything comes from the kernel and from a daemon already present on the appliance. 
  There is nothing to install on clients and no traffic mirroring to configure.

Use cases

Where to find it

The dashboard is a tab of the Artica home dashboard. 
Log in, then open Dashboard and select the Connections tab.

Reading the dashboard

The summary row

The Usage widget is the one to watch. 
Anything sustained above 80 % deserves attention before it becomes an outage.

• Time ranges
  The buttons under the summary row select the period: Last hour, 6h, 24h, 7d and 30d. 
  Artica picks the appropriate level of detail automatically — per-minute samples for short ranges, hourly averages for a day or two, daily averages beyond that. 
  On aggregated ranges the connections chart also draws faint peak and min lines, so a short spike is not hidden by the average.
   
• Connections
  Total tracked connections and active connections, plus table usage as a percentage on the right-hand axis. 
  A gap between the two lines is normal: the total includes connections in transient states, the active line counts established ones.
   
• Lifecycle:
  Connections created, updated and destroyed. Read it as a balance sheet: 
  if created stays well above destroyed for a long period, connections are accumulating and the table will eventually fill.
   
• Bandwidth
  Traffic carried by the tracked connections, in megabytes and packets. 
  This is accounting data attached to each kernel entry, so it covers everything the appliance forwards, not only proxied traffic.
   
• Realtime requests

Live counters read directly from the kernel and the daemon, refreshed each time you reload the panel. 
The CPU Distribution table underneath reports per-core counters using the exact names the conntrack -S command prints, so you can cross-check on the console:
 

Values other than invalid are highlighted in red when they are not zero, because unlike invalid they always indicate a problem worth investigating. 
Compare cores: figures concentrated on one core usually point to an interrupt-affinity or queue-distribution problem rather than to a lack of capacity.

Top sources and top destinations:
The ten busiest addresses, each with its connection count, a proportional bar, and the bandwidth carried. 
Loopback addresses are filtered out. Sort criteria is the connection count.

Read the two columns together. Many connections with a lot of bandwidth is a heavy but legitimate user; many connections with almost no bandwidth is the classic scanning or beaconing pattern.

Turning connection tracking off

Tracking is enabled by default, and that is the right setting for the vast majority of appliances. 
It can be turned off on an appliance where the extra kernel work is not worth the visibility.

• What it costs
  The kernel allocates one tracking entry per network flow — roughly 300 bytes each. 
  On an appliance whose ceiling is 524 288 entries that is about 150 MB in the worst case, plus a small amount of CPU per packet. 
  On a busy appliance with a small tracking table there is also a real risk: once the table fills, the kernel starts dropping new connections.

When turning it off makes sense:

• The appliance runs a stateless rule set only — a pure transparent-proxy deployment, for instance — so nothing needs connection state to make a filtering decision.
• The appliance is memory-constrained and you do not use the connection statistics.
• You are deliberately trading observability for the last few percent of throughput.

Do not turn it off if you use any firewall rule that matches connection state, or any form of network address translation: those features need the tracker and will stop behaving correctly without it.

How to turn it off

Go to Your system → System information. 
The Connection tracking line shows the current state.

Click the state badge to open the settings window, then switch Disable connection tracking on.

The change is applied immediately — there is no service to restart and no Apply button to press; closing the window is enough. 
The line then reports the new state:

Set the same switch back off to resume collecting statistics. 
Existing connections already recorded by the kernel are not removed when you disable tracking; they simply expire normally, so the dashboard fades out over the following minutes rather than emptying instantly.

When the dashboard reports no data
 

If the dashboard has nothing to show, it tells you why instead of displaying empty charts

There are two reasons this message appears.

• An administrator turned tracking off
  The message names the setting explicitly. 
  Re-enable it as described above and data starts accumulating within a minute.
   
• Nothing is asking the kernel to track
  This one is worth understanding, because it is counter-intuitive. 
  Loading the kernel's tracking module is not enough to make it track anything: modern Linux kernels only start tracking once a firewall rule actually asks for connection state. 
  A daemon that merely reads the tracking table does not count — it will happily report zero forever.

On an appliance whose firewall is entirely stateless, no rule ever makes that request. Artica therefore installs a dedicated rule of its own for the sole purpose of switching the kernel's tracking on. The rule sits in its own chain that no traffic ever reaches, so it cannot allow, block or alter a single packet — it exists purely to enable the counters.

If you see this message while the setting is enabled, check that the rule is present on the appliance:

iptables -S ARTICA_CONNTRACK

It is re-created automatically within three minutes if something removed it — a firewall rebuild, for example — so a missing rule is normally self-healing. 
You can also force it immediately from the API below.

REST API

All endpoints are served on the local Artica socket and answer with a {"success": …, "data": …} envelope.

Example:

SOCKET=/usr/share/artica-postfix/bin/run/articarest.sock
curl -s --unix-socket $SOCKET http://localhost/conntrackd/status
curl -s --unix-socket $SOCKET http://localhost/conntrackd/tracking/apply

Troubleshooting