NETAVARK-FIREWALLD(7)

💅 netavark-firewalld — the manual, but make it make sense

okay so bestie, this is the netavark-firewalld(7) page, and it's literally just the tea on how Netavark and firewalld vibe together. Written by Matthew Heon back in January 2025, and honestly? Iconic of him. Let's get into it 🫶

---

✨ NAME ✨

netavark-firewalld — a whole rundown of how Netavark and firewalld interact, iykyk

---

🌸 DESCRIPTION 🌸

Good news first: Netavark can be used on systems with firewalld enabled, no issue, no drama. 💖 When you're using the default nftables firewall driver, on systems where firewalld is running, firewalld will automatically be configured to allow connectivity to Podman containers. All subnets of Podman-managed networks get auto-added to the trusted zone to allow that access. Slay. No manual fiddling required.

---

🔥 Firewalld Driver

So there's also a dedicated firewalld driver in Netavark, and she's a whole thing. This driver uses the firewalld DBus API to natively interact with firewalld — very main character energy. You enable it by setting firewall_driver to firewalld in containers.conf.

The native firewalld driver offers better integration with firewalld, but presently suffers from several limitations (ngl, she's got baggage 😭):

• It does not support isolation (that's the --opt isolate= option to podman network create).
• Connections to ports forwarded by a container on the same host can only be made through the IPv4 localhost IP (127.0.0.1). Using other IPs on the host will not work, unless the connection comes from a separate host.

---

🚧 Strict Port Forwarding

Since firewalld version 2.3.0, there's a new setting, StrictForwardPorts, and you need to know about her. 💅

• She lives in /etc/firewalld/firewalld.conf
• She defaults to no (disabled)

When disabled, port forwarding with Podman works as normal — business as usual, no notes. But when it's enabled (set to yes), port forwarding with root Podman will become nonfunctional. Like, completely. Attempting to start a container or pod with the -p or -P options will return errors. 💀

When StrictForwardPorts is enabled, all port forwarding must be done through firewalld using the firewall-cmd tool. The whole point is that containers can't just allow traffic through the firewall without administrator intervention — security queen behavior, honestly.

Please note: rootless Podman is unaffected by this setting and will function as it always has. 🧚

Instead, containers should be started without forwarded ports specified, and preferably with static IPs.

To forward a port externally, run the following command — substituting the desired host and container port numbers, protocol, and the container's IP:

# firewall-cmd --permanent --zone {ZONE} --add-forward-port=port={HOST_PORT_NUMBER}:proto={PROTOCOL}:toport={CONTAINER_PORT_NUMBER}:toaddr={CONTAINER_IP}

If you're not sure which zone to use, the public zone should always work. 🫶

If the container does not have a static IP, you can find it with podman inspect:

# podman inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' {CONTAINER_NAME_OR_ID}

Once the container is stopped or removed, the rule must be manually removed with:

# firewall-cmd --permanent --zone {ZONE} --remove-forward-port=port={HOST_PORT_NUMBER}:proto={PROTOCOL}:toport={CONTAINER_PORT_NUMBER}:toaddr={CONTAINER_IP}

---

🌈 Forwarding via IPv4 localhost

To also allow forwarding via IPv4 localhost (127.0.0.1), a firewalld policy must be added, as well as a rich rule for each port requiring localhost forwarding.

Forwarding via IPv6 localhost is not possible due to kernel limitations. 😭

To add the policies required for IPv4 localhost forwarding, run these commands. This is only necessary once per system:

# firewall-cmd --permanent --new-policy localhostForward
# firewall-cmd --permanent --policy localhostForward --add-ingress-zone HOST
# firewall-cmd --permanent --policy localhostForward --add-egress-zone ANY

A further rich rule for each container is required:

# firewall-cmd --permanent --policy localhostForward --add-rich-rule='rule family=ipv4 destination address=127.0.0.0/8 forward-port port={HOST_PORT_NUMBER} protocol={PROTOCOL} to-port={CONTAINER_PORT_NUMBER} to-addr={CONTAINER_IP}'

These rules must be manually removed when the container is stopped or removed, with:

# firewall-cmd --permanent --policy localhostForward --remove-rich-rule='rule family=ipv4 destination address=127.0.0.0/8 forward-port port={HOST_PORT_NUMBER} protocol={PROTOCOL} to-port={CONTAINER_PORT_NUMBER} to-addr={CONTAINER_IP}'

The associated localhostForward policy does not need to be removed. 🎀

⭐ Please also note that, at present, it is only possible to access forwarded ports of a container on the same host via the IPv4 localhost IP (127.0.0.1), and only when the rich rule above has been applied. Accessing via an IP that is not 127.0.0.1 from the same host is presently not possible, but we hope to address this with a future firewalld release. fingers crossed bestie 🤞

💀 And one more: please note that the firewalld driver presently bypasses this protection, and will still allow traffic through the firewall when StrictForwardPorts is enabled without manual forwarding through firewall-cmd. This may be changed in a future release.

---

👀 SEE ALSO

firewalld(1), firewall-cmd(1), firewalld.conf(5), podman(1), containers.conf(5)

---

💜 AUTHORS

Matthew Heon <mheon@redhat.com> ⟨mailto:mheon@redhat.com⟩ — king behavior, fr fr 👑

---

and that's the whole page, bestie ✨ this lil writeup comes from the Firewalld section of the Netavark docs, NETAVARK-FIREWALLD(7), dated January 2025. go forth and forward your ports responsibly 💅🦋