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:

  • Drop
  • Forward
  • ToHost

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 tun or tap
  • 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.