On 26. May 2020, at 23:28, Gordon Messmer
On 5/26/20 2:15 PM, Felder, Christian wrote:
>>> Sorry. You’re right and I mixed things up. Indeed there is a new rule in
PREROUTING and this is the rule which bypasses the INPUT chain.
>>> I cannot explicitly configure ports on the INPUT chain as the packets are
forwarded to the CNI-HOSTPORT-DNAT target directly.
> $ iptables -L -nv
> Chain FORWARD (policy ACCEPT 9 packets, 488 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24
> 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
> 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
> 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0
> 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0
Your FORWARD rules only govern traffic that crosses the "virbr0" interface
specifically, so anything that doesn't uses the default "ACCEPT" policy.
Set your policy to DENY, or add a REJECT rule that matches all packets at the end of that
Thanks for pointing that out. When changing the default policy to DROP (using iptables -P
FORWARD DROP) the traffic is blocked as expected.
Using iptables is deprecated in RHEL/CentOS 8 and unfortunately the default policy for
firewalld is hard-wired to ACCEPT as it has another concept
of using zones which I tried without success in this use-case so far. Note: The CNI is
added to trusted zone by default.
I think I’ll stick to the approach not publishing any services to all interfaces which
should not be exposed world-wide. When using this internally I can
still bind to loopback (127.0.0.1) and use ssh-tunnelling to get access to that service as
Thus I don’t need to fiddle too much with the firewalld configs in this scenario.
Thanks a lot for your great advice. I hope this is beneficial for someone else stumbling
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io