On 26. May 2020, at 22:59, Gordon Messmer <gordon.messmer@gmail.com> wrote:

(moving thread back to list, excuse the lack of trimming)

On 5/26/20 1:18 PM, Felder, Christian wrote:

On 26. May 2020, at 19:43, Gordon Messmer <gordon.messmer@gmail.com <mailto:gordon.messmer@gmail.com>> wrote:

On 5/26/20 1:51 AM, Felder, Christian wrote:

When using podman run -p … DNAT rules in the forward chain are automatically created for allowing traffic to the container/pod.

I think you might be mixing up two different things.  When I run "podman run -p" I see a new rule in the PREROUTING chain of the "nat" table.  I don't see any rules in the FORWARD chain of the "filter" table.

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.

Because you're doing DNAT, you should be looking at the FORWARD chain, not the INPUT chain.  As far as I can tell, testing on my system, the FORWARD chain requires an explicit rule to allow external access to container-published ports.

I do have a system that doesn't require an explicit rule, because the destination network is part of firewalld's "trusted" zone.  It seems likely that you also have a rule that is allowing forwarded traffic.  Can you post the complete output of "iptables -L -nv" and "iptables -L -nv -t nat" somewhere that we can view them, if you don't see the rule now?  (ip6tables if you're testing connections from an external host over IPv6, of course)

There are no DNAT rules in the FORWARD chain.

I mixed this up with adding an explicit rule to the top of the FORWARD chain as described in this firewalld issue regarding docker.
https://github.com/firewalld/firewalld/issues/556

e.g. firewall-cmd --direct --add-passthrough ipv4 -I FORWARD 1 -s 10.88.2.0/24 -p tcp --dport 636 -j DROP

but this wouldn’t help either. Let’s forget about that ;-)

Unfortunately this bypasses the input chain which is usually used to explicitly allowing external traffic for a specific service/port.
Using podman run -p … the port is world-wide accessible though.

That isn't true on my system, as far as I can tell.

One solution is to just bind to the loopback interface using -p 127.0.0.1:XXX:XXX which will ensure that the port is just available on the
host system but on the other hand this does not allow using ssh tunnelling for authorised external access.

Why wouldn't it allow ssh tunneling?

You’re right I can tunnel traffic to it, e.g. using

ssh -M -S ~/.ssh/ssh-ldap3 -f root@centos-8 -L 6636:localhost:636 -N

which would allow me to access the container from my system on port 6636 which runs on port 636 on the host centos-8.



My conclusion:

It’s probably the easiest option to publish to loopback if I wan’t to limit access just to the host whereas publishing to all interfaces
would still allow external traffic as well without explicitly configuring the firewall because of the PREROUTING mechanism.
I can still ssh-tunnel traffic to that service when binding to loopback.

Imho people may not be aware of the INPUT chain being bypassed.

_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io