4:59 p.m.
(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(a)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.