NOTRACK is an iptables raw table action that tells the kernel not to place selected packets into conntrack. It is useful when state tracking creates side effects such as flow reuse or looping, but it removes the benefits of connection state for that traffic.
How NOTRACK Changes Packet Handling
NOTRACK is a raw-table iptables action that removes selected traffic from connection tracking. That means packets can still be filtered, routed, and logged, but the kernel no longer maintains the state record that conntrack would normally build for that flow.
The practical effect is simple: you are choosing stateless treatment for traffic that would otherwise inherit stateful behavior. That can be useful for certain high-volume, one-way, or loop-prone flows, but it also changes how later rules and related controls behave because they can no longer rely on tracked connection state for those packets.
Where NOTRACK Fits in the Netfilter Path
NOTRACK is used early in packet processing, before the normal connection-tracking decision is made. Because it sits in the raw table, it is a mechanism for shaping how the kernel interprets traffic, not just whether a packet is accepted or dropped.
This placement matters operationally. If a flow is exempted from conntrack, any downstream rule set that expects stateful control logic may no longer see the same connection semantics. In practice, NOTRACK is therefore a performance and behavior tuning choice, not a generic security bypass.
Why Teams Use It
Administrators typically reach for NOTRACK when connection tracking adds overhead or unwanted side effects. Common examples include traffic that is highly repetitive, traffic that should not consume conntrack table space, or flows that can be harmed by stateful inspection behavior such as reuse, asymmetry, or looping.
The benefit is reduced tracking cost and fewer state-related side effects. The trade-off is that state-aware capabilities tied to conntrack, including some firewall expectations, NAT interactions, and response matching, may no longer apply cleanly to the exempted packets. That makes the choice tightly dependent on the exact traffic path and rule design.
Connection State, Firewall Behavior, and Operational Trade-offs
NOTRACK changes the relationship between packet filtering and connection semantics. A rule set that was built around established, related, or tracked states can behave differently once selected packets are removed from conntrack, so rule ordering and exception scope become important.
For that reason, NOTRACK should be treated as a deliberate architecture decision, not a blanket optimization. It is most effective when the operator understands which flows truly do not need state and has validated that the rest of the stack, including logging, filtering, and any upstream or downstream network controls, still behaves as intended.
Risk and Threat Considerations
Removing traffic from conntrack can create visibility and control gaps if the exempted flows were expected to benefit from stateful inspection or rule correlation. The main risk is that a state exception meant for performance can also reduce the defender’s ability to distinguish legitimate traffic from malformed, abusive, or unexpected traffic patterns.
Failure mechanism: A flow marked NOTRACK no longer contributes to connection state, so controls that depend on tracked sessions may not enforce the same protections or observability for that traffic.
Impact: Mis-scoped exemptions can weaken firewall logic, complicate troubleshooting, and create blind spots in environments that assume conntrack-backed behavior for enforcement or analysis.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | NOTRACK changes how traffic is handled at network boundaries. |
| CM-7 — Least Functionality | NOTRACK is a deliberate reduction of tracking functionality for selected traffic. | |
| Recommendation — Review stateless exemptions against SC-7 and preserve boundary enforcement for any traffic that still needs stateful inspection. Limit NOTRACK exemptions to flows that genuinely require reduced kernel tracking behavior. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Conntrack exemptions are a security-relevant network configuration choice. |
| Recommendation — Document and review raw-table exceptions as part of secure network configuration. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | NOTRACK affects firewall and network-stack behavior at the host boundary. |
| Recommendation — Validate firewall exceptions and host network settings before deploying stateless packet handling. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | NOTRACK directly alters how network traffic is enforced and inspected. |
| Recommendation — Assess whether stateless exceptions preserve the required network-security controls. | ||
