<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Firewall on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/firewall/</link><description>Recent content in Firewall on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/firewall/index.xml" rel="self" type="application/rss+xml"/><item><title>firewalld</title><link>https://lesitedefrancois.be/en/security/firewalld/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/firewalld/</guid><description>&lt;p&gt;&lt;strong&gt;firewalld&lt;/strong&gt; is the firewall management daemon on RHEL, CentOS Stream, Fedora, SUSE, and their derivatives, providing a higher-level policy model and a runtime-safe management API on top of &lt;strong&gt;nftables&lt;/strong&gt; (RHEL 8+ / Fedora 32+) or iptables (older systems). Its defining feature is &lt;strong&gt;runtime versus permanent configuration&lt;/strong&gt;: firewall rule changes can be applied immediately to the running system without restarting the service or dropping existing connections (&lt;code&gt;--runtime&lt;/code&gt;, the default), and separately persisted to disk so they survive reboots (&lt;code&gt;--permanent&lt;/code&gt;). This two-phase model solves the operational problem that raw nftables or iptables rule changes traditionally required either accepting a momentary policy gap during reload or building custom transaction logic. The daemon exposes its API over &lt;strong&gt;D-Bus&lt;/strong&gt;, allowing NetworkManager, libvirt, Podman, and other system components to request firewall policy changes programmatically — when a VM is started in libvirt or a container port is published in Podman, the respective tool calls firewalld over D-Bus to open the required port rather than directly manipulating nftables rules.&lt;/p&gt;</description></item><item><title>iptables</title><link>https://lesitedefrancois.be/en/security/iptables/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/iptables/</guid><description>&lt;p&gt;&lt;strong&gt;iptables&lt;/strong&gt; is the user-space command-line interface to the Linux kernel&amp;rsquo;s &lt;strong&gt;Netfilter&lt;/strong&gt; packet filtering framework, the dominant firewall tool on Linux from its introduction in 2001 until nftables began replacing it in the mid-2010s. Netfilter inserts hook points at five positions in the kernel&amp;rsquo;s IPv4 (and separately IPv6, via &lt;code&gt;ip6tables&lt;/code&gt;) packet processing path: &lt;strong&gt;PREROUTING&lt;/strong&gt; (immediately after a packet arrives, before routing), &lt;strong&gt;INPUT&lt;/strong&gt; (packets destined for the local host), &lt;strong&gt;FORWARD&lt;/strong&gt; (packets being routed through the host), &lt;strong&gt;OUTPUT&lt;/strong&gt; (packets generated by local processes), and &lt;strong&gt;POSTROUTING&lt;/strong&gt; (after routing, before transmission). At each hook point, Netfilter calls into the active &lt;strong&gt;tables&lt;/strong&gt;, each of which contains ordered &lt;strong&gt;chains&lt;/strong&gt; of &lt;strong&gt;rules&lt;/strong&gt;. A rule is a match condition (source IP, destination port, protocol, connection state, interface, packet mark, and many more via match extensions) paired with a &lt;strong&gt;target&lt;/strong&gt; — the action to take if the rule matches: &lt;code&gt;ACCEPT&lt;/code&gt;, &lt;code&gt;DROP&lt;/code&gt;, &lt;code&gt;REJECT&lt;/code&gt;, &lt;code&gt;LOG&lt;/code&gt;, &lt;code&gt;MASQUERADE&lt;/code&gt;, &lt;code&gt;DNAT&lt;/code&gt;, &lt;code&gt;SNAT&lt;/code&gt;, or a jump to a user-defined chain. Rules are evaluated in order; the first matching rule&amp;rsquo;s target is applied and evaluation stops (unless the target is &lt;code&gt;LOG&lt;/code&gt; or another non-terminating target). If no rule matches, the chain&amp;rsquo;s &lt;strong&gt;policy&lt;/strong&gt; (the default target) applies.&lt;/p&gt;</description></item><item><title>nftables</title><link>https://lesitedefrancois.be/en/security/nftables/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/nftables/</guid><description>&lt;p&gt;&lt;strong&gt;nftables&lt;/strong&gt; is the successor to &lt;strong&gt;iptables&lt;/strong&gt; within the Linux Netfilter framework, merged into the mainline kernel in 3.13 (2014) and now the default firewall backend on all major distributions — Debian 10+, Ubuntu 20.04+, RHEL 8+, Fedora 32+. It replaces not just iptables but the entire family of legacy Netfilter frontends: &lt;code&gt;ip6tables&lt;/code&gt; (IPv6), &lt;code&gt;arptables&lt;/code&gt; (ARP), and &lt;code&gt;ebtables&lt;/code&gt; (Ethernet bridging) are all unified under a single &lt;code&gt;nft&lt;/code&gt; command and a single kernel subsystem. The kernel component is a generic, protocol-independent packet classification engine; the protocol-specific logic (IPv4, IPv6, ARP, bridging) is expressed in user-space rule syntax rather than hardcoded in separate kernel modules. This unification eliminates the fragmented ruleset management of the iptables era, where a firewall with consistent IPv4/IPv6 and bridging policy required coordinating four separate tools with four separate rulesets and four separate persistence mechanisms.&lt;/p&gt;</description></item></channel></rss>