I have a rootless podman container bound to 127.0.0.1:10080, and I would like to forward external traffic to port 80 to go to that container, which I have been unable to accomplish:
[me@certvault ~]$ curl -sS http://127.0.0.1:10080 >/dev/null
[me@certvault ~]$ curl -sS http://127.0.0.1:80 >/dev/null
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused
[me@certvault ~]$ sudo firewall-cmd --list-forward-ports
[me@certvault ~]$ sudo firewall-cmd --add-forward-port=port=80:proto=tcp:toport=10080:toaddr=127.0.0.1
success
[me@certvault ~]$ sudo firewall-cmd --list-forward-ports
port=80:proto=tcp:toport=10080:toaddr=127.0.0.1
[me@certvault ~]$ curl -sS http://127.0.0.1:80 >/dev/null
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused
[me@certvault ~]$ curl -sS http://127.0.0.1:10080 >/dev/null
As you can see, everything works fine other than the redirection of traffic to the container. If I remove the restriction of the container and the rule to 127.0.0.1, everything works, so I would think the base setup and idea are solid. But I don't want to expose the containers custom port to the world just to redirect traffic to it, and it doesn't seem to make sense that that would be necessary. Once the outside world reaches port 80, it should not need to even know about port 10080.
This command is adding a forward port for the default zone. That will forward ports for traffic that ingress the default zone, e.g. public. This hits the
PREROUTINGchains/hooks for iptables/nftables.Your example
Is presumably executed from the host running firewalld. As such, the traffic never hits the
PREROUTINGchain/hook in the kernel. It will hitOUTPUTinstead!Try your curl test from a different machine; not the one running firewalld.
IF you want it to also work from the same machine that is running firewalld, then that can be achieved using a policy in firewalld v1.1.0 or later. In fact, this is what podman's new network plugin, netavark, does.