The beginning of the end of iptables: Difference between revisions

(2 intermediate revisions by the same user not shown)

Line 1:

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

'''[[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 ~~functionality~~ (the "Illithid" traffic shaper at Microsoft).

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.

Line 19:

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.

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're 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>:

@@ Line 1: / Line 1: @@
-'''[[Dankblog|dankblog!]] 2024-04-19, 2243 EST, at [[Viewpoint|the danktower]]'''
+'''[[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 functionality (the "Illithid" traffic shaper at Microsoft).
+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.
@@ Line 19: / Line 19: @@
 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.
+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're 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>:

The beginning of the end of iptables: Difference between revisions

Dank (talk | contribs)