Dataplane
The dataplane classifies packets, applies compiled policy, maintains flow state, and forwards traffic.
The dataplane is the part of the Neuwerk that handles packet-by-packet enforcement.
Its job is to:
- classify traffic
- evaluate compiled policy
- keep flow and NAT state
- forward packets on the selected I/O path
It does not own DNS parsing, cluster logic, SSO, or the management API.
What The Dataplane Decides
For each packet, the dataplane reduces the decision to one of three outcomes:
DropForwardToHost
Drop and Forward are the normal enforcement outcomes.
ToHost is used when traffic needs a control-plane service instead of pure packet forwarding. The
important examples are DNS traffic aimed at the Neuwerk and traffic that has been selected for
active TLS interception.
What Inputs It Uses
The dataplane evaluates traffic against a compiled policy snapshot. Depending on the traffic, that can include:
- source-group membership
- destination IPs
- protocol
- source and destination ports
- ICMP type and code
- TLS metadata when TLS-aware rules are in use
When hostname-based policy is in use, the dataplane also relies on the dynamic allowlist that the DNS proxy maintains from successful DNS answers.
Stateful Behavior
The dataplane is not a stateless ACL engine. It maintains:
- active flow state
- NAT state
- forwarding context
- optional overlay state
That state is local to each node. In clustered deployments, policy is replicated, but active flow tables are not.
I/O Paths
The same enforcement model is used in both supported I/O shapes:
- software mode through
tunortap - DPDK mode for higher-throughput deployments
The I/O mechanics differ, but the policy model stays the same. From an operator perspective, that means policy semantics should not change just because the node uses DPDK.
What The Dataplane Does Not Do
The dataplane intentionally does not:
- parse DNS requests as a policy feature
- store cluster membership or replicated admin state
- terminate management HTTPS
- own the TLS intercept CA lifecycle
That boundary is what keeps packet handling separate from service-plane and management-plane logic.
Operator Implications
- A packet-policy issue usually shows up as a source-group, rule-order, default-action, or flow state problem.
- A hostname-policy issue usually starts in DNS behavior, not in the packet engine.
- A cluster issue may stop policy from being replayed locally, but the dataplane still remains a per-node runtime.
Read Policy Model next if you want the exact rule evaluation semantics.