NOTRACK

What NOTRACK Does in the Packet Path

NOTRACK is not a filtering decision, it changes how the kernel handles state for selected traffic. By bypassing conntrack in the raw table, it prevents packet flows from being added to the connection-tracking table, so later rules and helpers cannot rely on connection state for that traffic.

This matters because stateful inspection is a core assumption in many Linux firewall designs. When a flow is deliberately excluded from conntrack, you are trading away state awareness to avoid side effects such as unwanted flow reuse, loop amplification, or helper interaction.

Why Administrators Use NOTRACK

NOTRACK is typically chosen for traffic that should remain stateless from the firewall’s perspective, such as certain high-volume, asymmetric, or intentionally unmanaged flows. It can reduce unnecessary conntrack churn and prevent stateful processing from interfering with specialised packet handling.

The trade-off is operational rather than cosmetic: once a flow is outside conntrack, any policy that depends on established, related, or return-state matching no longer applies to that traffic. That means NOTRACK should be used only when the administrator understands exactly which packets must bypass state and why.

How NOTRACK Changes Firewall Behaviour

Because conntrack is often used by NAT, stateful allow rules, and protocol helpers, NOTRACK can alter more than one control path at once. Traffic excluded in the raw table may no longer benefit from connection tracking, but it may also stop working with rules that assume tracked sessions or reply direction awareness.

That makes placement important. NOTRACK belongs early in the packet path, before state is established, and it should be applied narrowly to the minimum traffic needed. Broad exclusions can create blind spots where the firewall no longer has the contextual state it would otherwise use for enforcement.

For practitioners who need a control baseline for Linux firewall hardening, CIS Benchmarks are a useful companion reference because they emphasise secure default configuration and controlled firewall behaviour.

Operational Limits and Troubleshooting Considerations

When a rule set uses NOTRACK, troubleshooting must account for the fact that the traffic may never appear in conntrack views. That can make debugging lookups, session visibility, and packet-flow analysis less intuitive, especially when administrators are expecting stateful counters or return-path correlation.

It also means changes to related firewall rules must be tested with care. A rule that works for tracked traffic may fail silently for excluded flows, not because the packet is blocked, but because the matching logic depends on state that no longer exists.

In practice, NOTRACK is best treated as a precise exception mechanism, not a general optimisation. The more broadly it is used, the easier it is to lose visibility into what the firewall is actually deciding, which is why solid baseline controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls remain relevant when designing and reviewing firewall policy.

Risk and Threat Considerations

Excluding packets from conntrack can create a security blind spot if administrators assume stateful controls still apply. The main risk is not the bypass itself, but the possibility that important traffic is no longer covered by rules, logs, or assumptions built around tracked sessions.

Failure mechanism: An attacker or misconfiguration can route traffic through a path that the firewall no longer tracks, which can weaken inspection, reduce visibility, or allow traffic patterns that would otherwise have been constrained by stateful policy.

Impact: The result can be incomplete monitoring, ineffective rule evaluation for affected flows, and harder incident investigation when the firewall no longer has session context for those packets.

Practitioner Guidance

What to watch for: Use NOTRACK only when the traffic class is clearly defined and the loss of state is acceptable. Review any rule that depends on session state, NAT behaviour, or protocol helpers before you exclude a flow, because the packet may still pass while the intended control no longer functions.

Practitioner takeaway: NOTRACK is a narrow firewall design tool, not a generic performance tweak, and it should be documented wherever stateful assumptions are intentionally removed.

Related resources from NHI Mgmt Group

• What is the difference between conntrack-based NAT handling and NOTRACK for proxied DNS traffic?