On 2019-11-05 01:00, Alexander E. Patrakov wrote:
I have tried Podman in Fedora 31. Not a rootless setup.
IP and netmask of the Fedora machine in my network: 192.168.5.130/24.
Podman creates, on the start of the first container, its default
cni-podman0 bridge with IP and netmask 10.88.0.1/16.
I wanted to play through a situation when we are migrating from a
service (let's say, 9999/tcp) formerly provided by some software
installed directly on the host to the same service provided by the
same software, but in a podman container. And this software needs to
be firewalled: there is a whitelist of IP addresses (let's say
18.104.22.168 and 192.168.5.44) that have the privilege to talk to
With the old, non-containerized setup, implementing this kind of
whitelist is trivial. Add a new firewalld zone, add thenecessary ports
and whitelisted client IPs to it, set the target to REJECT or DROP,
done. However, once I switch to a containerized service, the firewall
becomes ineffective, because the packets hit the FORWARD chain, not
INPUT. I could not find a good solution that works in terms of the
exposed port (i.e. 9999, even if inside the container a different port
is used). I could either add iptables rules (yuck... firewalld exists
for a reason) to "raw" or "mangle" tables (but then I cannot reject),
or do something in the "filter" table with "-p tcp -m tcp -m conntrack
--ctorigdstport 9999" (that's better).
There's an open feature request to add a chain for user-specified
IPTables rules that act on containers, such that they will be
preserved across container start/stop - and I think that without this
(which is not yet implemented) you can't reliable manually configure
IPTables rules for containers, because start/stop can mangle your
I think that firewald could see some improvement here. In order to
apply a whitelist of hosts that can connect, I should not need to care
whether the service is provided by something running on the host, or
by a container.
OK, another crazy idea: is it possible to use slirp4netns instead of
the default bridge for root-owned containers, just to avoid these
INPUT-vs-FORWARD firewall troubles?
Yes - this is possible. I believe `--net=slirp4netns` should do this.
Alexander E. Patrakov
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io