I'm trying to define 2 zones, one being a subset of another. I'd like to allow a range of ports to the wider zone, and then some additional ports to the narrower zone. When I try to do this, I get "Unable to connect to remote host: No route to host". If I look at the underlying iptables, it seems to follow the wider chain, but never goes back to try the narrower chain.
Here's what I did. I'm just using port 111/tcp as a test, since this is a brand new host and 111 and 22 are the only listening ports.
To start, verify that I can't connect to 111:
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
Create the wider zone for our network and allow 111
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=uwo success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo --add-source= 129.100.0.0/16 success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo --add-port=111/tcp success [root@jiradev aculver]# firewall-cmd --reload success
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... Connected to jiradev.its.uwo.ca. Escape character is '^]'.
Now add a narrower zone, which will represent our department's administrative workstations
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=net6 success [root@jiradev aculver]# firewall-cmd --permanent --zone=net6 --add-source= 129.100.6.0/24 success [root@jiradev aculver]# firewall-cmd --reload
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
I would think that the uwo zone should still apply, since I'm still connecting from a host defined in the source of that zone. But as soon as I create this second zone and give it a (narrower) source that also matches the IP that I'm connecting from, it seems to use only that zone, ignoring the first zone with the broader source.
Am I doing something wrong? How can I make this work?
I've tried to search for a solution to this, but without any error messages or having any keywords to search on, it's hard to even find others who have run into this problem. A coworker of mine has also run into this same problem, so I can't be the first.
Here's the resulting config (the rich rules are from our default build scripts. We'd like to replace them with zones if we can solve this current problem):
[root@jiradev aculver]# firewall-cmd --zone=uwo --list-all uwo (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.0.0/16 services: ports: 111/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# firewall-cmd --zone=net6 --list-all net6 (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.6.0/24 services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N FORWARD_IN_ZONES -N FORWARD_IN_ZONES_SOURCE -N FORWARD_OUT_ZONES -N FORWARD_OUT_ZONES_SOURCE -N FORWARD_direct -N FWDI_net6 -N FWDI_net6_allow -N FWDI_net6_deny -N FWDI_net6_log -N FWDI_public -N FWDI_public_allow -N FWDI_public_deny -N FWDI_public_log -N FWDI_uwo -N FWDI_uwo_allow -N FWDI_uwo_deny -N FWDI_uwo_log -N FWDO_net6 -N FWDO_net6_allow -N FWDO_net6_deny -N FWDO_net6_log -N FWDO_public -N FWDO_public_allow -N FWDO_public_deny -N FWDO_public_log -N FWDO_uwo -N FWDO_uwo_allow -N FWDO_uwo_deny -N FWDO_uwo_log -N INPUT_ZONES -N INPUT_ZONES_SOURCE -N INPUT_direct -N IN_net6 -N IN_net6_allow -N IN_net6_deny -N IN_net6_log -N IN_public -N IN_public_allow -N IN_public_deny -N IN_public_log -N IN_uwo -N IN_uwo_allow -N IN_uwo_deny -N IN_uwo_log -N OUTPUT_direct -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i ens160 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_IN_ZONES_SOURCE -s 129.100.6.0/24 -g FWDI_net6 -A FORWARD_IN_ZONES_SOURCE -s 129.100.0.0/16 -g FWDI_uwo -A FORWARD_OUT_ZONES -o ens160 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FORWARD_OUT_ZONES_SOURCE -d 129.100.6.0/24 -g FWDO_net6 -A FORWARD_OUT_ZONES_SOURCE -d 129.100.0.0/16 -g FWDO_uwo -A FWDI_net6 -j FWDI_net6_log -A FWDI_net6 -j FWDI_net6_deny -A FWDI_net6 -j FWDI_net6_allow -A FWDI_net6 -p icmp -j ACCEPT -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCEPT -A FWDI_uwo -j FWDI_uwo_log -A FWDI_uwo -j FWDI_uwo_deny -A FWDI_uwo -j FWDI_uwo_allow -A FWDI_uwo -p icmp -j ACCEPT -A FWDO_net6 -j FWDO_net6_log -A FWDO_net6 -j FWDO_net6_deny -A FWDO_net6 -j FWDO_net6_allow -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A FWDO_uwo -j FWDO_uwo_log -A FWDO_uwo -j FWDO_uwo_deny -A FWDO_uwo -j FWDO_uwo_allow -A INPUT_ZONES -i ens160 -g IN_public -A INPUT_ZONES -g IN_public -A INPUT_ZONES_SOURCE -s 129.100.6.0/24 -g IN_net6 -A INPUT_ZONES_SOURCE -s 129.100.0.0/16 -g IN_uwo -A IN_net6 -j IN_net6_log -A IN_net6 -j IN_net6_deny -A IN_net6 -j IN_net6_allow -A IN_net6 -p icmp -j ACCEPT -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -s 172.20.0.0/22 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.6.0/26 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.233/32 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.6.192/27 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_uwo -j IN_uwo_log -A IN_uwo -j IN_uwo_deny -A IN_uwo -j IN_uwo_allow -A IN_uwo -p icmp -j ACCEPT -A IN_uwo_allow -p tcp -m tcp --dport 111 -m conntrack --ctstate NEW -j ACCEPT
Thanks, Andrew
On Mon, Nov 20, 2017 at 04:24:52PM -0500, Andrew Culver wrote:
I'm trying to define 2 zones, one being a subset of another. I'd like to allow a range of ports to the wider zone, and then some additional ports to the narrower zone. When I try to do this, I get "Unable to connect to remote host: No route to host". If I look at the underlying iptables, it seems to follow the wider chain, but never goes back to try the narrower chain.
Here's what I did. I'm just using port 111/tcp as a test, since this is a brand new host and 111 and 22 are the only listening ports.
To start, verify that I can't connect to 111:
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
Create the wider zone for our network and allow 111
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=uwo success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo --add-source= 129.100.0.0/16 success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo --add-port=111/tcp success [root@jiradev aculver]# firewall-cmd --reload success
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... Connected to jiradev.its.uwo.ca. Escape character is '^]'.
Now add a narrower zone, which will represent our department's administrative workstations
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=net6 success [root@jiradev aculver]# firewall-cmd --permanent --zone=net6 --add-source= 129.100.6.0/24 success [root@jiradev aculver]# firewall-cmd --reload
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
I would think that the uwo zone should still apply, since I'm still connecting from a host defined in the source of that zone. But as soon as I create this second zone and give it a (narrower) source that also matches the IP that I'm connecting from, it seems to use only that zone, ignoring the first zone with the broader source.
Am I doing something wrong? How can I make this work?
Packets may only belong to one zone. In your case, traffic from 129.0.6.0/24 will always go to and only to zone net6. Packets will not fallback to the wider zone (uwo). This is not a bug and is intentional.
You can see in your iptables output below that it does a _goto_ IN_net6 from the INPUT_ZONES_SOURCE chain. This means it will not continue on to the IN_uwo chain, but will instead fallback to the INPUT chain. See the -g option in the iptables man page.
Also see quote from [0]:
"A firewall zone defines the trust level for a connection, interface or source address binding. This is a one to many relation, which means that a connection, interface or source can only be part of one zone, but a zone can be used for many network connections, interfaces and sources."
[0] http://www.firewalld.org/documentation/zone/
I've tried to search for a solution to this, but without any error messages or having any keywords to search on, it's hard to even find others who have run into this problem. A coworker of mine has also run into this same problem, so I can't be the first.
Here's the resulting config (the rich rules are from our default build scripts. We'd like to replace them with zones if we can solve this current problem):
[root@jiradev aculver]# firewall-cmd --zone=uwo --list-all uwo (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.0.0/16 services: ports: 111/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# firewall-cmd --zone=net6 --list-all net6 (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.6.0/24 services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N FORWARD_IN_ZONES -N FORWARD_IN_ZONES_SOURCE -N FORWARD_OUT_ZONES -N FORWARD_OUT_ZONES_SOURCE -N FORWARD_direct -N FWDI_net6 -N FWDI_net6_allow -N FWDI_net6_deny -N FWDI_net6_log -N FWDI_public -N FWDI_public_allow -N FWDI_public_deny -N FWDI_public_log -N FWDI_uwo -N FWDI_uwo_allow -N FWDI_uwo_deny -N FWDI_uwo_log -N FWDO_net6 -N FWDO_net6_allow -N FWDO_net6_deny -N FWDO_net6_log -N FWDO_public -N FWDO_public_allow -N FWDO_public_deny -N FWDO_public_log -N FWDO_uwo -N FWDO_uwo_allow -N FWDO_uwo_deny -N FWDO_uwo_log -N INPUT_ZONES -N INPUT_ZONES_SOURCE -N INPUT_direct -N IN_net6 -N IN_net6_allow -N IN_net6_deny -N IN_net6_log -N IN_public -N IN_public_allow -N IN_public_deny -N IN_public_log -N IN_uwo -N IN_uwo_allow -N IN_uwo_deny -N IN_uwo_log -N OUTPUT_direct -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i ens160 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_IN_ZONES_SOURCE -s 129.100.6.0/24 -g FWDI_net6 -A FORWARD_IN_ZONES_SOURCE -s 129.100.0.0/16 -g FWDI_uwo -A FORWARD_OUT_ZONES -o ens160 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FORWARD_OUT_ZONES_SOURCE -d 129.100.6.0/24 -g FWDO_net6 -A FORWARD_OUT_ZONES_SOURCE -d 129.100.0.0/16 -g FWDO_uwo -A FWDI_net6 -j FWDI_net6_log -A FWDI_net6 -j FWDI_net6_deny -A FWDI_net6 -j FWDI_net6_allow -A FWDI_net6 -p icmp -j ACCEPT -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCEPT -A FWDI_uwo -j FWDI_uwo_log -A FWDI_uwo -j FWDI_uwo_deny -A FWDI_uwo -j FWDI_uwo_allow -A FWDI_uwo -p icmp -j ACCEPT -A FWDO_net6 -j FWDO_net6_log -A FWDO_net6 -j FWDO_net6_deny -A FWDO_net6 -j FWDO_net6_allow -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A FWDO_uwo -j FWDO_uwo_log -A FWDO_uwo -j FWDO_uwo_deny -A FWDO_uwo -j FWDO_uwo_allow -A INPUT_ZONES -i ens160 -g IN_public -A INPUT_ZONES -g IN_public -A INPUT_ZONES_SOURCE -s 129.100.6.0/24 -g IN_net6 -A INPUT_ZONES_SOURCE -s 129.100.0.0/16 -g IN_uwo -A IN_net6 -j IN_net6_log -A IN_net6 -j IN_net6_deny -A IN_net6 -j IN_net6_allow -A IN_net6 -p icmp -j ACCEPT -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -s 172.20.0.0/22 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.6.0/26 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.233/32 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.6.192/27 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p icmp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p udp -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p tcp -m conntrack --ctstate NEW -j ACCEPT -A IN_uwo -j IN_uwo_log -A IN_uwo -j IN_uwo_deny -A IN_uwo -j IN_uwo_allow -A IN_uwo -p icmp -j ACCEPT -A IN_uwo_allow -p tcp -m tcp --dport 111 -m conntrack --ctstate NEW -j ACCEPT
Thanks, Andrew
firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org
Hi Eric,
Thanks for the reply. I did some additional searching last night after posting my question and others seems to be suggesting the same thing, but I couldn't find it explicitly stated anywhere.
Why does firewalld use a _goto_ in the INPUT_ZONES_SOURCE chain instead of using a _jump_? This would allow a source to match multiple zones. This could at least be an option on firewalld to give the administrator the choice, since it's something that the underlying iptables CAN do.
It would make more sense from a design perspective as well. My case is a common example: wanting to open some ports to a broad network range, but also wanting to open additional ports to a subset of that range without having to redefine all the ports from the broader range. The IP _is_ in the larger range, so the rules of the larger range _should_ apply to it. This seems like something that a firewall solution should easily be able to do, but by using a goto instead of a jump, this is not possible. I'd have to add the services/ports to every narrow range zone that falls inside of the larger range. This means updating multiple zones whenever I add/remove a service or port to the broader zone, which seems unnecessary.
Thanks, Andrew
*Andrew Culver* System Administrator Western Technology Services https://www.uwo.ca/wts University of Western Ontario https://www.uwo.ca e: aculver@uwo.ca p: 519-661-2111 x80265 <15196612111,80265> cal: html http://goo.gl/wVoDlo | ics http://goo.gl/ncUjV0
On Mon, Nov 20, 2017 at 7:33 PM, Eric Garver egarver@redhat.com wrote:
On Mon, Nov 20, 2017 at 04:24:52PM -0500, Andrew Culver wrote:
I'm trying to define 2 zones, one being a subset of another. I'd like to allow a range of ports to the wider zone, and then some additional ports
to
the narrower zone. When I try to do this, I get "Unable to connect to remote host: No route to host". If I look at the underlying iptables, it seems to follow the wider chain, but never goes back to try the narrower chain.
Here's what I did. I'm just using port 111/tcp as a test, since this is a brand new host and 111 and 22 are the only listening ports.
To start, verify that I can't connect to 111:
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
Create the wider zone for our network and allow 111
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=uwo success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo
--add-source=
129.100.0.0/16 success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo --add-port=111/tcp success [root@jiradev aculver]# firewall-cmd --reload success
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... Connected to jiradev.its.uwo.ca. Escape character is '^]'.
Now add a narrower zone, which will represent our department's administrative workstations
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=net6 success [root@jiradev aculver]# firewall-cmd --permanent --zone=net6
--add-source=
129.100.6.0/24 success [root@jiradev aculver]# firewall-cmd --reload
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
I would think that the uwo zone should still apply, since I'm still connecting from a host defined in the source of that zone. But as soon
as I
create this second zone and give it a (narrower) source that also matches the IP that I'm connecting from, it seems to use only that zone, ignoring the first zone with the broader source.
Am I doing something wrong? How can I make this work?
Packets may only belong to one zone. In your case, traffic from 129.0.6.0/24 will always go to and only to zone net6. Packets will not fallback to the wider zone (uwo). This is not a bug and is intentional.
You can see in your iptables output below that it does a _goto_ IN_net6 from the INPUT_ZONES_SOURCE chain. This means it will not continue on to the IN_uwo chain, but will instead fallback to the INPUT chain. See the -g option in the iptables man page.
Also see quote from [0]:
"A firewall zone defines the trust level for a connection, interface or source address binding. This is a one to many relation, which means that a connection, interface or source can only be part of one zone, but a zone can be used for many network connections, interfaces and sources."[0] http://www.firewalld.org/documentation/zone/
I've tried to search for a solution to this, but without any error
messages
or having any keywords to search on, it's hard to even find others who
have
run into this problem. A coworker of mine has also run into this same problem, so I can't be the first.
Here's the resulting config (the rich rules are from our default build scripts. We'd like to replace them with zones if we can solve this
current
problem):
[root@jiradev aculver]# firewall-cmd --zone=uwo --list-all uwo (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.0.0/16 services: ports: 111/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# firewall-cmd --zone=net6 --list-all net6 (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.6.0/24 services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N FORWARD_IN_ZONES -N FORWARD_IN_ZONES_SOURCE -N FORWARD_OUT_ZONES -N FORWARD_OUT_ZONES_SOURCE -N FORWARD_direct -N FWDI_net6 -N FWDI_net6_allow -N FWDI_net6_deny -N FWDI_net6_log -N FWDI_public -N FWDI_public_allow -N FWDI_public_deny -N FWDI_public_log -N FWDI_uwo -N FWDI_uwo_allow -N FWDI_uwo_deny -N FWDI_uwo_log -N FWDO_net6 -N FWDO_net6_allow -N FWDO_net6_deny -N FWDO_net6_log -N FWDO_public -N FWDO_public_allow -N FWDO_public_deny -N FWDO_public_log -N FWDO_uwo -N FWDO_uwo_allow -N FWDO_uwo_deny -N FWDO_uwo_log -N INPUT_ZONES -N INPUT_ZONES_SOURCE -N INPUT_direct -N IN_net6 -N IN_net6_allow -N IN_net6_deny -N IN_net6_log -N IN_public -N IN_public_allow -N IN_public_deny -N IN_public_log -N IN_uwo -N IN_uwo_allow -N IN_uwo_deny -N IN_uwo_log -N OUTPUT_direct -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i ens160 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_IN_ZONES_SOURCE -s 129.100.6.0/24 -g FWDI_net6 -A FORWARD_IN_ZONES_SOURCE -s 129.100.0.0/16 -g FWDI_uwo -A FORWARD_OUT_ZONES -o ens160 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FORWARD_OUT_ZONES_SOURCE -d 129.100.6.0/24 -g FWDO_net6 -A FORWARD_OUT_ZONES_SOURCE -d 129.100.0.0/16 -g FWDO_uwo -A FWDI_net6 -j FWDI_net6_log -A FWDI_net6 -j FWDI_net6_deny -A FWDI_net6 -j FWDI_net6_allow -A FWDI_net6 -p icmp -j ACCEPT -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCEPT -A FWDI_uwo -j FWDI_uwo_log -A FWDI_uwo -j FWDI_uwo_deny -A FWDI_uwo -j FWDI_uwo_allow -A FWDI_uwo -p icmp -j ACCEPT -A FWDO_net6 -j FWDO_net6_log -A FWDO_net6 -j FWDO_net6_deny -A FWDO_net6 -j FWDO_net6_allow -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A FWDO_uwo -j FWDO_uwo_log -A FWDO_uwo -j FWDO_uwo_deny -A FWDO_uwo -j FWDO_uwo_allow -A INPUT_ZONES -i ens160 -g IN_public -A INPUT_ZONES -g IN_public -A INPUT_ZONES_SOURCE -s 129.100.6.0/24 -g IN_net6 -A INPUT_ZONES_SOURCE -s 129.100.0.0/16 -g IN_uwo -A IN_net6 -j IN_net6_log -A IN_net6 -j IN_net6_deny -A IN_net6 -j IN_net6_allow -A IN_net6 -p icmp -j ACCEPT -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -s 172.20.0.0/22 -p tcp -m tcp --dport 22 -m
conntrack
--ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p udp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p udp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p udp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p udp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p icmp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p tcp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.6.0/26 -p tcp -m tcp --dport 22 -m
conntrack
--ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.233/32 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p tcp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p tcp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.6.192/27 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p icmp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p udp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p icmp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p icmp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p tcp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p tcp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p udp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p tcp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_uwo -j IN_uwo_log -A IN_uwo -j IN_uwo_deny -A IN_uwo -j IN_uwo_allow -A IN_uwo -p icmp -j ACCEPT -A IN_uwo_allow -p tcp -m tcp --dport 111 -m conntrack --ctstate NEW -j ACCEPT
Thanks, Andrew
firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.
fedorahosted.org _______________________________________________ firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists. fedorahosted.org
On Tue, Nov 21, 2017 at 10:07:54AM -0500, Andrew Culver wrote:
Hi Eric,
Thanks for the reply. I did some additional searching last night after posting my question and others seems to be suggesting the same thing, but I couldn't find it explicitly stated anywhere.
Why does firewalld use a _goto_ in the INPUT_ZONES_SOURCE chain instead of using a _jump_? This would allow a source to match multiple zones. This could at least be an option on firewalld to give the administrator the choice, since it's something that the underlying iptables CAN do.
I wasn't around during the early days so I can only speculate. In my opinion it's to prevent accidents. With many zones it can be very tricky to track which rules a packet will hit if it may fall through to other zones. It also goes against the premise of "zones" - to keep different types of traffic completely separate.
There are alternatives to doing the zone fall-though. You can use a single zone with rich rules and ipsets. The common services/ports can be at the end. These should be added to iptables in the order they appear in the configuration. You could also used direct rules. e.g. source ipset=narrow_range service=ssh accept source ipset=wide_range service=http accept
It would make more sense from a design perspective as well. My case is a
I disagree as it violates the concepts of zones.
common example: wanting to open some ports to a broad network range, but also wanting to open additional ports to a subset of that range without having to redefine all the ports from the broader range. The IP _is_ in the larger range, so the rules of the larger range _should_ apply to it. This seems like something that a firewall solution should easily be able to do, but by using a goto instead of a jump, this is not possible. I'd have to add the services/ports to every narrow range zone that falls inside of the larger range. This means updating multiple zones whenever I add/remove a service or port to the broader zone, which seems unnecessary.
Thanks, Andrew
*Andrew Culver* System Administrator Western Technology Services https://www.uwo.ca/wts University of Western Ontario https://www.uwo.ca e: aculver@uwo.ca p: 519-661-2111 x80265 <15196612111,80265> cal: html http://goo.gl/wVoDlo | ics http://goo.gl/ncUjV0
On Mon, Nov 20, 2017 at 7:33 PM, Eric Garver egarver@redhat.com wrote:
On Mon, Nov 20, 2017 at 04:24:52PM -0500, Andrew Culver wrote:
I'm trying to define 2 zones, one being a subset of another. I'd like to allow a range of ports to the wider zone, and then some additional ports
to
the narrower zone. When I try to do this, I get "Unable to connect to remote host: No route to host". If I look at the underlying iptables, it seems to follow the wider chain, but never goes back to try the narrower chain.
Here's what I did. I'm just using port 111/tcp as a test, since this is a brand new host and 111 and 22 are the only listening ports.
To start, verify that I can't connect to 111:
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
Create the wider zone for our network and allow 111
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=uwo success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo
--add-source=
129.100.0.0/16 success [root@jiradev aculver]# firewall-cmd --permanent --zone=uwo --add-port=111/tcp success [root@jiradev aculver]# firewall-cmd --reload success
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... Connected to jiradev.its.uwo.ca. Escape character is '^]'.
Now add a narrower zone, which will represent our department's administrative workstations
[root@jiradev aculver]# firewall-cmd --permanent --new-zone=net6 success [root@jiradev aculver]# firewall-cmd --permanent --zone=net6
--add-source=
129.100.6.0/24 success [root@jiradev aculver]# firewall-cmd --reload
aculver@aculver ~ $ telnet jiradev.its.uwo.ca 111 Trying 129.100.58.223... telnet: Unable to connect to remote host: No route to host
I would think that the uwo zone should still apply, since I'm still connecting from a host defined in the source of that zone. But as soon
as I
create this second zone and give it a (narrower) source that also matches the IP that I'm connecting from, it seems to use only that zone, ignoring the first zone with the broader source.
Am I doing something wrong? How can I make this work?
Packets may only belong to one zone. In your case, traffic from 129.0.6.0/24 will always go to and only to zone net6. Packets will not fallback to the wider zone (uwo). This is not a bug and is intentional.
You can see in your iptables output below that it does a _goto_ IN_net6 from the INPUT_ZONES_SOURCE chain. This means it will not continue on to the IN_uwo chain, but will instead fallback to the INPUT chain. See the -g option in the iptables man page.
Also see quote from [0]:
"A firewall zone defines the trust level for a connection, interface or source address binding. This is a one to many relation, which means that a connection, interface or source can only be part of one zone, but a zone can be used for many network connections, interfaces and sources."[0] http://www.firewalld.org/documentation/zone/
I've tried to search for a solution to this, but without any error
messages
or having any keywords to search on, it's hard to even find others who
have
run into this problem. A coworker of mine has also run into this same problem, so I can't be the first.
Here's the resulting config (the rich rules are from our default build scripts. We'd like to replace them with zones if we can solve this
current
problem):
[root@jiradev aculver]# firewall-cmd --zone=uwo --list-all uwo (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.0.0/16 services: ports: 111/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# firewall-cmd --zone=net6 --list-all net6 (active) target: default icmp-block-inversion: no interfaces: sources: 129.100.6.0/24 services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@jiradev aculver]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N FORWARD_IN_ZONES -N FORWARD_IN_ZONES_SOURCE -N FORWARD_OUT_ZONES -N FORWARD_OUT_ZONES_SOURCE -N FORWARD_direct -N FWDI_net6 -N FWDI_net6_allow -N FWDI_net6_deny -N FWDI_net6_log -N FWDI_public -N FWDI_public_allow -N FWDI_public_deny -N FWDI_public_log -N FWDI_uwo -N FWDI_uwo_allow -N FWDI_uwo_deny -N FWDI_uwo_log -N FWDO_net6 -N FWDO_net6_allow -N FWDO_net6_deny -N FWDO_net6_log -N FWDO_public -N FWDO_public_allow -N FWDO_public_deny -N FWDO_public_log -N FWDO_uwo -N FWDO_uwo_allow -N FWDO_uwo_deny -N FWDO_uwo_log -N INPUT_ZONES -N INPUT_ZONES_SOURCE -N INPUT_direct -N IN_net6 -N IN_net6_allow -N IN_net6_deny -N IN_net6_log -N IN_public -N IN_public_allow -N IN_public_deny -N IN_public_log -N IN_uwo -N IN_uwo_allow -N IN_uwo_deny -N IN_uwo_log -N OUTPUT_direct -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i lo -j ACCEPT -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i ens160 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_IN_ZONES_SOURCE -s 129.100.6.0/24 -g FWDI_net6 -A FORWARD_IN_ZONES_SOURCE -s 129.100.0.0/16 -g FWDI_uwo -A FORWARD_OUT_ZONES -o ens160 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FORWARD_OUT_ZONES_SOURCE -d 129.100.6.0/24 -g FWDO_net6 -A FORWARD_OUT_ZONES_SOURCE -d 129.100.0.0/16 -g FWDO_uwo -A FWDI_net6 -j FWDI_net6_log -A FWDI_net6 -j FWDI_net6_deny -A FWDI_net6 -j FWDI_net6_allow -A FWDI_net6 -p icmp -j ACCEPT -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACCEPT -A FWDI_uwo -j FWDI_uwo_log -A FWDI_uwo -j FWDI_uwo_deny -A FWDI_uwo -j FWDI_uwo_allow -A FWDI_uwo -p icmp -j ACCEPT -A FWDO_net6 -j FWDO_net6_log -A FWDO_net6 -j FWDO_net6_deny -A FWDO_net6 -j FWDO_net6_allow -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A FWDO_uwo -j FWDO_uwo_log -A FWDO_uwo -j FWDO_uwo_deny -A FWDO_uwo -j FWDO_uwo_allow -A INPUT_ZONES -i ens160 -g IN_public -A INPUT_ZONES -g IN_public -A INPUT_ZONES_SOURCE -s 129.100.6.0/24 -g IN_net6 -A INPUT_ZONES_SOURCE -s 129.100.0.0/16 -g IN_uwo -A IN_net6 -j IN_net6_log -A IN_net6 -j IN_net6_deny -A IN_net6 -j IN_net6_allow -A IN_net6 -p icmp -j ACCEPT -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACCEPT -A IN_public_allow -s 172.20.0.0/22 -p tcp -m tcp --dport 22 -m
conntrack
--ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p udp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p udp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p udp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p udp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p icmp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p tcp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.6.0/26 -p tcp -m tcp --dport 22 -m
conntrack
--ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.233/32 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p tcp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p tcp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.6.192/27 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p icmp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.3.116/32 -p udp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 129.100.254.11/32 -p icmp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.254.10/32 -p icmp -m conntrack --ctstate
NEW
-j ACCEPT -A IN_public_allow -s 129.100.3.110/32 -p tcp -m conntrack --ctstate
NEW -j
ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p tcp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_public_allow -s 172.29.17.37/32 -p udp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_public_allow -s 172.29.17.38/32 -p tcp -m conntrack --ctstate NEW
-j
ACCEPT -A IN_uwo -j IN_uwo_log -A IN_uwo -j IN_uwo_deny -A IN_uwo -j IN_uwo_allow -A IN_uwo -p icmp -j ACCEPT -A IN_uwo_allow -p tcp -m tcp --dport 111 -m conntrack --ctstate NEW -j ACCEPT
Thanks, Andrew
firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.
fedorahosted.org _______________________________________________ firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists. fedorahosted.org
firewalld-users mailing list -- firewalld-users@lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave@lists.fedorahosted.org
firewalld-users@lists.fedorahosted.org
-
Andrew Culver -
Eric Garver