What connection tracking contributes
Linux connection tracking records state about network flows used by features such as stateful filtering and NAT. When that state becomes constrained, new flows can fail while existing sessions appear healthier. A successful ping or one already-open SSH session is therefore weak evidence that a business application's new connections are working.
This runbook applies to an authorized Linux firewall or host using conntrack. It does not replace the diagnostic interface of a managed cloud NAT service or a commercial firewall. Identify the actual stateful device and network namespace before comparing its counters with application failures.
Setup: establish the traffic and counter scope
Record source, destination, transport, expected NAT behavior and whether failures affect new or established sessions. Inspect the relevant kernel logs and supported conntrack statistics. The kernel documents nf_conntrack_count as current allocated entries and nf_conntrack_max as the allowed entry limit; read them in the applicable namespace.
Capture a short time series rather than one occupancy sample after traffic has fallen. Pair occupancy with connection-attempt rate, relevant drop or insertion-failure counters and application connection errors. A large count alone does not prove saturation, and a low count observed after the incident does not disprove an earlier peak.
Illustrative incident: connection churn follows a deployment
An illustrative application stops reusing outbound connections after a release. Request volume stays similar, but new-flow churn rises and new requests intermittently fail. This constructed example is not a real customer incident or an allegation that a particular framework always behaves this way.
Compare the application revision, connection reuse, destination distribution and failure timestamps. If one short-lived workload dominates the change, ask its owner to reproduce that behavior in a controlled test. Do not assume malicious traffic from a flow count alone, but escalate through incident response when other evidence indicates abuse.
Troubleshooting: connect counters to observed failure
| Observation | Evidence | Next investigation |
|---|---|---|
| New sessions fail while old ones continue | Application timestamps and conntrack pressure | Is state allocation failing at the same time? |
| Occupancy grows with unchanged request rate | New connection rate and reuse behavior | Did connection churn increase? |
| Count is healthy but traffic still drops | Routing, policy and interface counters | Is another network boundary failing? |
| Only one namespace shows pressure | Namespace-specific limits and workload map | Are host-wide observations hiding the affected scope? |
Avoid publishing raw connection tables containing customer addresses or sensitive service names. A bounded, restricted diagnostic capture is usually more useful than an unrestricted dump. Keep sufficient aggregation to identify direction, lifecycle and affected workload without exposing unnecessary communication details.
Correct the demonstrated capacity problem
Restore sensible connection reuse or limit an offending workload where evidence supports that action. If state capacity needs to grow, review memory cost, hash-table behavior and the supported kernel configuration. A larger limit is a resource decision, not a cost-free universal fix.
Do not flush the live conntrack table to make occupancy disappear: active stateful sessions can be disrupted. Timeout changes also alter connection behavior and require protocol-specific review. Coordinate an approved change and preserve a rollback value, while checking that the underlying traffic pattern is understood.
Verify new flows and define the operating procedure
Exercise fresh representative connections from the affected network path and verify successful application work. Observe the pressure counters under expected concurrency and through a normal traffic peak. Existing sessions remaining alive are not a substitute for testing new ones.
Set an internal SLO around successful eligible connection-dependent operations, supported by state-headroom and churn alerts. Choose thresholds from the environment's observed behavior rather than publishing a universal conntrack percentage. SLA commitments require a separate agreement. The SOP should identify device and namespace ownership, restricted evidence handling, permitted capacity changes and escalation to network or security response.
See Clouvenix firewall security for help defining a reviewed operational scope.
Technical reference
Kernel conntrack settings, Netfilter conntrack-tools manual. Reviewed 19 October 2026; select documentation matching the installed release.