firewalld public zone and internal zone clash?

Issues related to configuring your network
User avatar
jlehtone
Posts: 4530
Joined: 2007/12/11 08:17:33
Location: Finland

Re: firewalld public zone and internal zone clash?

Post by jlehtone » 2020/01/18 12:37:25

Lets recap, the 8.1 has:

Code: Select all

CentOS 8.1-1911# rpm -q firewalld
firewalld-0.7.0-5.el8.noarch

chain filter_INPUT {
		type filter hook input priority 10; policy accept;
		ct state established,related accept
		ct status dnat accept
		iifname "lo" accept
		jump filter_INPUT_ZONES
		ct state invalid drop
		reject with icmpx type admin-prohibited
	}

	chain filter_INPUT_ZONES {
		ip saddr 192.168.1.2 goto filter_IN_ssh
		iifname "enp0s3" goto filter_IN_public
		goto filter_IN_public
	}
While the 8.0 (and 7) had:

Code: Select all

CentOS 8.0-1905# rpm -q firewalld
firewalld-0.6.3-7.el8.noarch

	chain filter_INPUT {
		type filter hook input priority 10; policy accept;
		ct state established,related accept
		iifname "lo" accept
		jump filter_INPUT_ZONES_SOURCE
		jump filter_INPUT_ZONES
		ct state invalid drop
		reject with icmpx type admin-prohibited
	}

	chain filter_INPUT_ZONES_SOURCE {
		ip saddr 192.168.1.2 goto filter_IN_internal
	}

	chain filter_INPUT_ZONES {
		iifname "enp3s0" goto filter_IN_public
		goto filter_IN_public
	}
From rpm -q --changelog firewalld:

Code: Select all

* Tue Aug 13 2019 Eric Garver <egarver@redhat.com> - 0.7.0-5
- bump nftables version requirements

* Tue Aug 06 2019 Eric Garver <egarver@redhat.com> - 0.7.0-4
- backport patches to sort source-based zone dispatch by zone name

* Tue Jul 23 2019 Eric Garver <egarver@redhat.com> - 0.7.0-3
- backport patch to show service includes in service output
- backport patches to fix dbus API break

* Thu Jun 13 2019 Eric Garver <egarver@redhat.com> - 0.7.0-2
- package rebuild

* Wed Jun 12 2019 Eric Garver <egarver@redhat.com> - 0.7.0-1
- rebase to v0.7.0

* Sun Jan 13 2019 Eric Garver <egarver@redhat.com> - 0.6.3-7
The difference is clear.
  • firewalld-0.6 had a separate INPUT_ZONES_SOURCE.
    You had internal in there. Internal did not handle every packet.
    The fall-through packets continued from INPUT, where the next rule is INPUT_ZONES and IN_public within it.
  • firewalld-0.7 has both source-based zones and interface-based zones in the INPUT_ZONES.
    The fall-through packets continue from INPUT, skipping all other zones.
In other words, if you want 192.168.1.2 to access both ssh and http, then you have to explicitly allow both in the 'internal' rather than relying that any other zone would catch unhandled packets after the 'internal'.

I don't think that there were nor are a bug in this. Rather that upstream decided to improve their design with the 0.7.

mutex77
Posts: 5
Joined: 2012/11/02 18:46:28

Re: firewalld public zone and internal zone clash?

Post by mutex77 » 2020/01/21 21:50:19

I apologize, I didnt see your reply to just now

The reason I wanted to do all of this was I wanted everyone to access http, and only my internal network (lets say 192.168.1.2) to access ssh. The way I always did that on CentOS7 was to use 2 seperate zones. Like here:
https://www.linuxjournal.com/content/un ... igurations

So can I allow http to everyone but just allow ssh to 192.168.1.2 with firewalld? It seemed like you were saying that the other zones after internal would be skipped...

User avatar
jlehtone
Posts: 4530
Joined: 2007/12/11 08:17:33
Location: Finland

Re: firewalld public zone and internal zone clash?

Post by jlehtone » 2020/01/22 05:46:51

You can.

Zone 1: source 192.168.x.y/z, service http, ssh
Zone 2: interface, service http

With this setup Zone 2 handles everything except from 192.168.x.y/z.
Therefore, every packet enters via one of the two zones.
Both zones allow http and therefore http from everywhere is allowed.

Post Reply