Allowing ip address access to additional ports

[Nathanael Noblet]

Hello,

I think I misunderstood something about how firewalld works and need
to make a change to some rules but I'm not sure how to go about it.

I have srv1 and srv2. Srv1 hosts a web/db etc. Srv2 is a DB
replication server so it connects to srv1 and is replicating the DB
there. To do so I created a zone db-access, I added the port and as
well as a number of source ip address which should be allowed to
connect to that port.

However, what that has resulted in is that srv2 can *only* connect
to the srv1 on the db-access port. So ssh, web requests from srv2 to
srv1 fail with no route to host while ping functions normally.

How was I supposed to setup the firewall so that by default
everything goes through the public zone, however if you match the
source IP you're also allowed additional ports?

Sincerely,

[Andrei Borzenkov]

On 28.06.2024 01:22, Nathanael Noblet wrote:
> Hello,
> I think I misunderstood something about how firewalld works and need
>
> to make a change to some rules but I'm not sure how to go about it.
> I have srv1 and srv2. Srv1 hosts a web/db etc. Srv2 is a DB
>
> replication server so it connects to srv1 and is replicating the DB
> there. To do so I created a zone db-access, I added the port and as
> well as a number of source ip address which should be allowed to
> connect to that port.
> However, what that has resulted in is that srv2 can *only* connect
>
> to the srv1 on the db-access port. So ssh, web requests from srv2 to
> srv1 fail with no route to host while ping functions normally.
> How was I supposed to setup the firewall so that by default
>
> everything goes through the public zone, however if you match the
> source IP you're also allowed additional ports?

Use rich rules in the public zone to restrict additional ports to the 
selected source address(es).

[Eric Garver]

On Thu, Jun 27, 2024 at 04:22:05PM -0600, Nathanael Noblet wrote:
> Hello,
>
> I think I misunderstood something about how firewalld works and need
> to make a change to some rules but I'm not sure how to go about it.
>
> I have srv1 and srv2. Srv1 hosts a web/db etc. Srv2 is a DB
> replication server so it connects to srv1 and is replicating the DB
> there. To do so I created a zone db-access, I added the port and as
> well as a number of source ip address which should be allowed to
> connect to that port.
>
> However, what that has resulted in is that srv2 can *only* connect
> to the srv1 on the db-access port. So ssh, web requests from srv2 to
> srv1 fail with no route to host while ping functions normally.
>
> How was I supposed to setup the firewall so that by default
> everything goes through the public zone, however if you match the
> source IP you're also allowed additional ports?

You are correct that you have a fundamental misunderstanding.

Zones separate your network. Traffic goes to _one and only one_ zone. So
when you did '--zone db-access --add-source=<addr of srv2>' you
reassigned _all_ the traffic from srv2 to the db-access zone. srv2
traffic will not enter any other zone (including those that allow ssh).

You should read the concepts here:

https://firewalld.org/documentation/concepts.html

Your use case is common. There are actually a few ways you can address
it. I'll order them from easy to advanced.

1. add all the other services to the db-access zone

- e.g. 'firewall-cmd --permanent --zone db-access --add-service ssh'

2. use a rich rule

- remove the db-access zone
- use a rich rule to give select access to a service to specific hosts
- e.g. "firewall-cmd --permanent --add-rich-rule='rule family=ipv4 port port=1234 protocol=tcp source address=1.2.3.4 accept"

3. use a policy for your common services

- this is the most flexible but introduces new concepts (policy)
- I won't give CLI examples, but the idea is that policies allow you to
  apply a policy (set of rules) to multiple situations, e.g. public zone
  --> host, and db-access zone --> host.
- https://firewalld.org/2020/09/policy-objects-introduction

[Kenneth Porter]

Coming from iptables, the zone concept was quite alien to me. But I 
found a blog entry that explained that packets are first classified by 
zone, then by interface. And I see now that zones can be ordered:

https://firewalld.org/2023/04/zone-priorities

[Andrei Borzenkov]

On 28.06.2024 18:58, Kenneth Porter wrote:
> Coming from iptables, the zone concept was quite alien to me. But I
> found a blog entry that explained that packets are first classified by
> zone, then by interface.

Huh? You probably mean source zone vs. interface zone. The packet cannot 
be "classified by zone" as "zone" does not exist on this level. Packet 
properties (source address or ingress interface) are used to associate 
packet with a zone.
> And I see now that zones can be ordered:
>
> https://firewalld.org/2023/04/zone-priorities

It does not change the fact that each packet belongs to one and only one 
zone.

[Kenneth Porter]

On 6/28/2024 9:16 AM, Andrei Borzenkov wrote:
> Huh? You probably mean source zone vs. interface zone. The packet 
> cannot be "classified by zone" as "zone" does not exist on this level. 
> Packet properties (source address or ingress interface) are used to 
> associate packet with a zone.

Thanks, that's much better. What is an egress zone? Can packets enter in 
one zone and exit in another?

With iptables, I had a diagram that showed where all the filters hook in 
as a packet passes through the system.

[Kenneth Porter]

On 6/28/2024 9:36 AM, Kenneth Porter wrote:
> What is an egress zone? Can packets enter in one zone and exit in another?

Ah, looking at your earlier link, I see that policies control forwarding 
for router applications.

[Nathanael Noblet]

Hello,

This has all been very useful information! Thank you very much!

Nathanael

---- On Fri, 28 Jun 2024 09:58:16 -0600 [e-mail] wrote ----

Coming from iptables, the zone concept was quite alien to me. But I
found a blog entry that explained that packets are first classified by
zone, then by interface. And I see now that zones can be ordered:

https://firewalld.org/2023/04/zone-priorities

--
_______________________________________________
firewalld-users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue