Netfilter hooks

From nftables wiki
Revision as of 03:09, 8 February 2021 by Pablo (talk | contribs) (add schematic to represent hooks (contributed by Francisco Javier Rodríguez López))
Jump to navigation Jump to search

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 the following schematic for the packet flow paths through Linux networking:

nf-hooks.png

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.