Netfilter hooks
If you are familiar with Netfilter, don't worry, most of the infrastructure remains the same. nftables reuses the existing hook infrastructure, Connection Tracking System, NAT engine, logging infrastructure, userspace queueing and so on. Therefore, we have only replaced the packet classification framework.
For those unfamiliar with Netfilter, we provide ASCII art to represent our hooks:
Local process ^ | .-----------. .-----------. | | | Routing | | |-----> input / \---> | Decision |----> output \ --> prerouting --->| Routing | .-----------. \ | Decision | --> postrouting | | / | |---------------> forward --------------------------- .-----------.
Basically, traffic flowing to the local machine in the input path see the prerouting and input hooks. Then, the traffic that is generated by local processes follows the output and postrouting path.
If you configure your Linux box to behave as router, do not forget to enable forwarding via:
echo 1 > /proc/sys/net/ipv4/ip_forward
And then, the packets that are not addressed to your local system will be seen from the forward hook. In summary, packets that are not addressed to local processes follow this path: prerouting, forward and postrouting.
Ingress hook
Since Linux kernel 4.2, Netfilter also comes with an ingress hook that you can use from nftables. So the big picture now look like this:
.-----------. | |-----> input ... ---> ingress ---> prerouting --->| Routing | | Decision | | | | |-----> forward ... .-----------.
You can use this new ingress hook to filter traffic from Layer 2. This new hook comes before prerouting, so this allows you to enforce very early filtering policies. This new hook basically provides an alternative to tc ingress filtering. You still need tc for traffic shaping/queue management.