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