Difference between revisions of "Netfilter hooks"
(Added reminder that nftables does not predefine any base chains.) |
|||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
''nftables'' uses mostly the same Netfilter infrastructure as legacy ''iptables''. The hook infrastructure, [http://people.netfilter.org/pablo/docs/login.pdf Connection Tracking System], NAT engine, logging infrastructure, and userspace queueing remain the same. '''Only the packet classification framework is new'''. | |||
The following schematic shows packet flows through Linux networking: | |||
https://people.netfilter.org/pablo/nf-hooks.png | |||
If you configure your Linux box to behave as router, do not forget to enable forwarding via: | |||
Traffic flowing to the local machine in the input path sees 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 a router, do not forget to enable forwarding via: | |||
echo 1 > /proc/sys/net/ipv4/ip_forward | echo 1 > /proc/sys/net/ipv4/ip_forward | ||
Then packets that are not addressed to your local system will be seen from the forward hook. Such forwarded packets follow the path: prerouting, forward and postrouting. | |||
In a major change from iptables, which predefines chains at '''every''' hook (i.e. ''INPUT'' chain in ''filter'' table), nftables predefines '''no''' chains at all. You must must explicitly create a [[Configuring_chains#Base_chain_hooks | base chain]] at each hook at which you want to filter traffic. | |||
= Ingress hook = | = Ingress hook = | ||
The ingress hook was added in Linux kernel 4.2. Unlike the other netfilter hooks, the ingress hook is attached to a particular network interface. | |||
You can use ''nftables'' with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment. | |||
The ingress hook provides an alternative to ''tc'' ingress filtering. You still need ''tc'' for traffic shaping/queue management. |
Revision as of 00:32, 12 February 2021
nftables uses mostly the same Netfilter infrastructure as legacy iptables. The hook infrastructure, Connection Tracking System, NAT engine, logging infrastructure, and userspace queueing remain the same. Only the packet classification framework is new.
The following schematic shows packet flows through Linux networking:
Traffic flowing to the local machine in the input path sees 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 a router, do not forget to enable forwarding via:
echo 1 > /proc/sys/net/ipv4/ip_forward
Then packets that are not addressed to your local system will be seen from the forward hook. Such forwarded packets follow the path: prerouting, forward and postrouting.
In a major change from iptables, which predefines chains at every hook (i.e. INPUT chain in filter table), nftables predefines no chains at all. You must must explicitly create a base chain at each hook at which you want to filter traffic.
Ingress hook
The ingress hook was added in Linux kernel 4.2. Unlike the other netfilter hooks, the ingress hook is attached to a particular network interface.
You can use nftables with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.
The ingress hook provides an alternative to tc ingress filtering. You still need tc for traffic shaping/queue management.