On Mon, Feb 08, 2021 at 06:19:07PM +0100, Łukasz Posadowski wrote:
Hi.
I have a little trouble with firewalld. I'm trying to open some ports for monitoring server, but it's in the same network as "home" zone:
Monitored host (192.168.111.60):
lukasz @ strategie 17:52:19 ~ $ -> sudo firewall-cmd --get-active home sources: 192.168.111.0/24 (open ports 22, 80, 443) monitoring sources: 192.168.111.19 (open ports: 5666) public interfaces: ens18 (no open ports)
Monitoring host (192.168.111.19):
lukasz @ potemkin 17:57:25 ~ $ -> telnet strategie.ping.local 5666 Trying 192.168.111.60... telnet: connect to address 192.168.111.60: No route to host
lukasz @ potemkin 17:57:26 ~ $ -> telnet strategie.ping.local 80 Trying 192.168.111.60... Connected to strategie.ping.local. Escape character is '^]'. ^] telnet> Connection closed.
I think there are conflicting rules on a monitored host, that:
- prevent access to 5666 from 192.168.111.0/24,
- give access to 5666 from 192.168.111.19
and packets from potemkin are routed trough a home zone.
I really would like to have dedicated "monitor" zone. Is there a way to give "monitor" zone more priority, than "home"? I may end with OpenVPN on potemkin and use 172.30.25.0/24 for monitoring, but, apart from encryption aspect, it seems a little excessive.
You can do it with rich rules, which have a priority. Basically, if you set priority to < 0, it goes into a _pre table which gets evaluated before the other zones:
Blog about it: https://firewalld.org/2018/12/rich-rule-priorities
Unfortunately, this was introduced in firewalld v0.7.0 which isn't in CentOS 7. I'm not sure if the functionality has been backported, but the firewalld.richlanguage man page on my c7 system doesn't mention it. It should work on CentOS 8+.
Another solution is to set a direct rule, which is evaluated first.
Lastly, its my experience that firewalld evaluates the configuration of zones lexically, so if the monitoring zone happens to sort (LANG=C) before the other zone, it'll be evaluated first. Don't trust that this behavior will always be the case.