Re: Host in source range of two zones being rejected

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(a)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(a)redhat.com&gt; 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(a)lists.fedorahosted.org > > To unsubscribe send an email to firewalld-users-leave@lists. > fedorahosted.org > _______________________________________________ > firewalld-users mailing list -- firewalld-users(a)lists.fedorahosted.org > To unsubscribe send an email to firewalld-users-leave@lists. > fedorahosted.org >

_______________________________________________ firewalld-users mailing list -- firewalld-users(a)lists.fedorahosted.org To unsubscribe send an email to firewalld-users-leave(a)lists.fedorahosted.org