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



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