View source for The beginning of the end of iptables

'''[[Dankblog|dankblog!]] 2024-04-19, 2334 EST, at [[Viewpoint|the danktower]]'''

when i was but a wee lad, Linux was circling around a sensible packet filtering infrastructure. there had been the generally unacceptable <tt>ipfwadm</tt> in 2.0, pretty clearly behind OpenBSD's PF (later brought into FreeBSD 5.2) and FreeBSD's IPFW. Rusty Russell (whom we haven't heard much from recently--I wonder where he's gone) implemented the stateless <tt>ipchains</tt> in 2.2, and then replaced it in 2.4 with [[iptables]], a full-featured solution that stood for a decade. i memorized the entirety of iptables early on, and it served me very well in my career. indeed, even in 2022 i was employing obscure iptables functionality in conjunction with eBPF to implement advanced, novel warez (the "Illithid" traffic shaper at Microsoft).

kernel 3.13 introduced "nftables", controlled by the <tt>nft</tt> userspace binary. nftables unifies the packet filtering space, previously split among iptables, ip6tables, ebtables (for bridging), and arptables, combining the existing Netfilter netstack hooks with a virtual machine. nftables supported a compatibility layer for the vast majority (by popularity) of iptables functionality: for at least the past five years, if you've been using <tt>iptables</tt>, you've most likely been using <tt>iptables-nft</tt>, and actually creating nftables rulesets (<tt>iptables-legacy</tt> has continued to use the legacy kernel infrastructure). there are four sets of <tt>-nft</tt> and <tt>-legacy</tt> for the four elements of the space.

<pre>
[schwarzgerat](0) $ readlink -f $(command -v iptables)
/usr/sbin/xtables-nft-multi
[schwarzgerat](0) $ iptables -V
iptables v1.8.10 (nf_tables)
[schwarzgerat](0) $ iptables-nft -V
iptables v1.8.10 (nf_tables)
[schwarzgerat](0) $ iptables-legacy -V
iptables v1.8.10 (legacy)
[schwarzgerat](0) $ 
</pre>

from the userspace perspective, major advantages of nftables include the unified approach (no more IPv4/IPv6 duplication!) and the ability to monitor changes to the ruleset. from the developer's perspective, addition/deletion of rules now operates on a single rule at a time, rather than requiring a complete replacement of the ruleset to make any change.

so, for the majority of iptables users who are just <tt>DROP</tt>ping most incoming traffic and possibly jumping to <tt>MASQUERADE</tt> on an outgoing interface or two, maybe <tt>DNAT</tt>ting to a [[Docker]], the move to nftables has been entirely under-the-hood, and many were probably unaware of the switch. i've used <tt>nft</tt> a few times, but there's twenty-five years of <tt>iptables</tt> muscle memory present, so i've largely continued to make use of that model.

recently, however, i've been trying to make more use of <tt>systemd-networkd</tt>. part of this was using <tt>IPMasquerade=ipv4</tt> in a <tt>systemd.network</tt> unit, rather than hooking an <tt>iptables -w -t nat -I POSTROUTING -o iface -j MASQUERADE</tt> to the interface in some ad hoc manner as i've always done (usually a <tt>pre-up</tt> rule in debian's <tt>/etc/network/interfaces</tt> or its non-union redhat equivalent). it worked just as expected, until i ran <tt>iptables -t nat -L -v -n</tt>:

<pre>
[qgp](0) $ sudo iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
[qgp](0) $
</pre>

whaaaaaaaaaaaat? where's my <tt>POSTROUTING</tt> rule? i quickly verified via inspection that ipv4 masquerading was taking place as expected. no iptables rule listed, though! i checked <tt>nft list ruleset</tt>:

<pre>
table ip io.systemd.nat {
	set masq_saddr {
		type ipv4_addr
		flags interval
		elements = { 192.168.88.0/24, 192.168.90.0/24,
--
		type nat hook postrouting priority srcnat + 1; policy accept;
		ip saddr @masq_saddr masquerade
	}
}
table ip6 io.systemd.nat {
	set masq_saddr {
		type ipv6_addr
		flags interval
	}
--
		type nat hook postrouting priority srcnat + 1; policy accept;
		ip6 saddr @masq_saddr masquerade
	}
}
[qgp](0) $ 
</pre>

well, there's my masquerade configuration. and note that, true to form, nft appears to now be masquerading for both ipv4 and ipv6, which i didn't intend, did not want, and did not expect based off the <tt>systemd-networkd</tt> directive <tt>IPMasquerade=ipv4</tt> (this is presumably either a bug in <tt>systemd-networkd</tt>, or (more likely) i'm misunderstanding the output). since v248, [https://github.com/systemd/systemd/blob/5efbd0bf897a990ebe43d7dc69141d87c404ac9a/src/shared/firewall-util.c#L29-L36 systemd has used nftables directly when available]. this bypasses the <tt>ip filter</tt> and <tt>ip6 filter</tt> tables managed by <tt>iptables-nft</tt>, and thus doesn't show up using <tt>iptables-nft</tt>. 

systemd-hating retards ought know that this move is mirrored in docker, libvirtd, podman, and other tools, so it's pretty inescapable.

which means i finally, after a decade plus, need to start using <tt>nft</tt> and abandon <tt>iptables</tt>, even in its <tt>iptables-nft</tt> incarnation. bah!

==See also==
* [[iptables]]
* [[nftables]]
* ArchWiki's [https://wiki.archlinux.org/title/nftables nftables] page
* [https://github.com/NixOS/nixpkgs/issues/156041 NixOS issue #156041]

'''previously: "[[Io_uring_and_xdp_enter_2024|Io uring and xdp enter 2024]]" 2024-02-15'''

[[Category:Blog]]