New subject: Networking / CNI and firewalld (iptables)

Tuesday, 26 May 2020

(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. 

2024

2023

2022

2021

2020

2019

Re: Networking / CNI and firewalld (iptables)