Description
On RockyLinux 9, trying to start a rootful container with port forwarding while using the firewalld firewall driver causes the startup to fail.
# NETAVARK_FW=firewalld podman run --rm -p=8000:80/tcp docker.io/httpd:latest
Error: netavark: Failed to update firewalld policy netavark_portfwd port forwarding rules: DBus error: org.fedoraproject.FirewallD1.Exception: INVALID_FORWARD: Policy 'netavark_portfwd': A 'forward-port' with 'to-addr' is invalid for egress zone 'HOST'
Steps to reproduce
- Prepare a RockyLinux 9 machine (I've tested both x86_64 and aarch64; doesn't seem to matter).
- Install
firewalld and podman from repository: dnf install -y firewalld podman.
- Make sure
firewalld.service is running: systemctl start firewalld.service.
- Try to start a container with
firewalld as firewall driver and observe the error.
Versions
kernel: 5.14.0-611.9.1.el9_7.aarch64
podman: 6:5.6.0-7.el9_7
netavark: 2:1.16.0-1.el9
firewalld: 1.3.4-15.el9_6
Additional notes
Interestingly, this issue does not happen on ArchLinux with podman 5.7.0, netavark 1.17.0, and firewalld 2.4.0. I self-compiled netavark 1.17.0 (with aardvark-dns 1.17.0) on RockyLinux 9 and retried, but got the same results. So it seems to me that the most likely explanation is that the firewalld policy syntax used to be stricter, but has since been relaxed some time between 1.3.4 and 2.4.0.
Description
On RockyLinux 9, trying to start a rootful container with port forwarding while using the
firewalldfirewall driver causes the startup to fail.Steps to reproduce
firewalldandpodmanfrom repository:dnf install -y firewalld podman.firewalld.serviceis running:systemctl start firewalld.service.firewalldas firewall driver and observe the error.Versions
kernel:
5.14.0-611.9.1.el9_7.aarch64podman:
6:5.6.0-7.el9_7netavark:
2:1.16.0-1.el9firewalld:
1.3.4-15.el9_6Additional notes
Interestingly, this issue does not happen on ArchLinux with podman 5.7.0, netavark 1.17.0, and firewalld 2.4.0. I self-compiled netavark 1.17.0 (with aardvark-dns 1.17.0) on RockyLinux 9 and retried, but got the same results. So it seems to me that the most likely explanation is that the firewalld policy syntax used to be stricter, but has since been relaxed some time between 1.3.4 and 2.4.0.