Firewall in Rocky 9 issue


I’m having very odd issue with firewalld.

So connection from outside router using VPN is can’t connect to the server.

This is my firewall rule in server:
br0 is bridge interface that bridging with virtual server inside server.
eno1 is connected to router.
eno2 is not used.
eno3 is connected to other server
eno 4 is connected to Public IP

nmcli c
eno4 479875f5-537d-4aba-95d5-e0d96b4635e5 ethernet eno4
br0 7a010243-b220-4b2b-9357-d5998c6d8e80 bridge br0
eno2 0bf0f8ff-0dc6-4db4-ab85-d91643ef2386 ethernet eno2
eno3 6bc358b6-1193-3f7e-a16e-4c06a6377d3e ethernet eno3
lo a767791c-cd40-499c-a667-16706ffdd429 loopback lo
virbr0 b9f12251-f2e8-49b8-9799-19ae3542e53b bridge virbr0
vnet0 a1c87b39-21e9-44b2-bdec-0acd4416f85a tun vnet0
bridge-slave-eno1 f59f3584-004c-4700-bdc9-ea29882fe960 ethernet eno1

firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: br0 eno1 eno2 eno3 eno4
services: cockpit dhcpv6-client freeipa-ldap freeipa-ldaps ssh
ports: 1812/udp 1813/udp 8069/tcp 8072/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 3268/tcp 138/udp 139/udp 389/udp 445/udp 8086/tcp
forward: yes
masquerade: no
rich rules:

this happen when I tried to remove interface eno4 from public zone because I want use different zone for eno4 who is using Public IP

sudo firewall-cmd --zone=public --remove-interface=eno4 --permanent

but every time I run that cmd, when I see in the list, it’s still in public zone
and then I tried using this command:

sudo firewall-cmd --zone=public --remove-interface=eno4 --runtime-to-permanen
sudo firewall-cmd --runtime-to-permanen

After his connection from outside router that using VPN can’t connect to server.
I can’t find any solutions why this is happen.

Any help is very appreciate as not really familliar with firewalld.

Thank you

Two things:

  • Every interface must be on some zone. Therefore, one cannot “remove” – one has to “set” the interface to new zone. Besides, the “public” in the default; if interface is not explicitly in any zone, then it is in the default …
  • Use NetworkManager to set the zone of the connection:
    nmcli con mod ${connection_of_eno4} ${newzone}

Hi jlehtone,

Yes, I already add the zone again but still no luck.

nmcli -p con show br0|grep public

nmcli -p con show eno4|grep public

All interface that are missing I had added it again but still no luck.

firewall-cmd --get-active-zones
interfaces: virbr0
interfaces: br0 eno4 eno3 eno2 eno1

Thank you

Did you already tell what zone you want to use and was it the one that you did add?

This is how I would put eno4 to zone ‘external’ and check what happens:

nmcli -f con show eno4
nft list ruleset | grep eno4
nmcli con mod eno4 external
nmcli -f con show eno4
nft list ruleset | grep eno4

Once you do get the connection to a different zone than the ‘public’, you have to do (up to two) things:

  • Modify the new zone (e.g. ‘external’) to allow the VPN tunnel
  • Add FirewallD policies that define how/if traffic is allowed (to be routed/forwarded) between zones

Hi jlehtone,

After broken the connection, I added back eno4 to public zone just to hope it will back again as before I removed eno4 from public.

Yes, before I broke it, I want eno4 in external zone.
But now I just want to back it to public first before I decided moving to new zone.

nmcli -f con show eno4 public

nft list ruleset | grep eno4
iifname “eno4” goto mangle_PRE_public
iifname “eno4” goto nat_PRE_public
oifname “eno4” goto nat_POST_public
iifname “eno4” goto filter_IN_public
iifname “eno4” goto filter_FWD_public
oifname “eno4” accept

as reference this is for br0:

nft list ruleset | grep br0
iifname “virbr0” udp dport 53 counter packets 0 bytes 0 accept
iifname “virbr0” tcp dport 53 counter packets 0 bytes 0 accept
iifname “virbr0” udp dport 67 counter packets 0 bytes 0 accept
iifname “virbr0” tcp dport 67 counter packets 0 bytes 0 accept
oifname “virbr0” udp dport 53 counter packets 0 bytes 0 accept
oifname “virbr0” tcp dport 53 counter packets 0 bytes 0 accept
oifname “virbr0” udp dport 68 counter packets 0 bytes 0 accept
oifname “virbr0” tcp dport 68 counter packets 0 bytes 0 accept
iifname “virbr0” ip saddr counter packets 0 bytes 0 accept
iifname “virbr0” counter packets 0 bytes 0 reject
oifname “virbr0” ip daddr ct state related,established counter packets 0 bytes 0 accept
oifname “virbr0” counter packets 0 bytes 0 reject
iifname “virbr0” oifname “virbr0” counter packets 0 bytes 0 accept
oifname “virbr0” udp dport 68 counter packets 0 bytes 0 # CHECKSUM fill
iifname “br0” goto mangle_PRE_public
iifname “virbr0” goto mangle_PRE_libvirt
iifname “br0” goto nat_PRE_public
iifname “virbr0” goto nat_PRE_libvirt
oifname “br0” goto nat_POST_public
oifname “virbr0” goto nat_POST_libvirt
iifname “br0” goto filter_IN_public
iifname “virbr0” goto filter_IN_libvirt
iifname “br0” goto filter_FWD_public
iifname “virbr0” goto filter_FWD_libvirt
oifname “br0” accept

So. help me to back it to public zone first please.
My subnet is
My server IP
My second server IP

Second server is normal, can be accessed from outside route using VPN.
As information, I have subnet that I used for openvpn user and work normal when user outside LAN connect to this subnet.

But other subnet can’t connect to only as other IP in this subnet accessable.

Other subnet is using openvpn too.

In my mind, I thought to remove firewald and reinstall again in hope it will back to normal but I’m afraid will make worse.

Btw, I tried stop the firewalld service too but no luck, so don’t know what bloking other subnet to this server.

Thank you

Everything that you have shown indicates that the eno4 is in zone public.

Have you restarted the relevant services or whole server? A service that listens on port (like openvpn) could be affected by interfaces going down and up, so “fall off the boat” due to runtime changes. (Although, changes in firewall rules ought to not affect.)

All FirewallD customizations are stored under /etc/firewalld/, so cleaning there would “reset to defaults”, except the ‘’ that is stored in connections.

It would probably help to modify the ‘external’ zone (and policies) before you assign it to use in eno4.

I think I find what is the culprit.
It’s the routing.

After I deactivated the eno4, it’s normal.

So sorry for the trouble.

Seen now I have to configure the routing so it will work both with interface br0 and eno4.

Thank you

Routing has three components:


The net.ipv4.ip_forward has to be 1 for at least IPv4 traffic to be forwarded from one interface to another. The ‘external’ zone seems to set that when active, but otherwise one has to set it explicitly.

Was net.ipv4.ip_forward affected by your earlier changes?


The firewall rules dictate whether the forwarded packets are allowed to pass through, or are dropped.
The default is to allow replies on existing connections and one has to explicitly allow just the desired new connections.

In some cases it might be necessary to have dNAT or sNAT (aka masquerade) as well. (The ‘external’ enables that too for its interfaces.)

Shutting down FirewallD removes all filtering. Therefore, everything gets through and is not blocked; no effect on routing. It also removes NAT rules and if connections did depend on NAT, then that disturbs routed traffic.


Routes dictate where the packets are delivered to. To this machine or via which interface.

When interface gets IP address, the system gets a link-local route to the subnet that the address is member of. The machine may also (optionally) get a default route and static routes.

Logically, machine has at most one (active) default route. A “roadwarrior” VPN config changes default route when tunnel interface activates – “everything” outbound is sent via the tunnel. However, the VPN process must still continue to talk to the VPN partner through original interface.

One can see routes with ip ro (and also in output of nmcli).

Hi jlehtone,

yes, the server already had this setting.

Thank you for the explanation about routing.
It’s long time since I done some routing in server as most routing in our place is handle by mikrotik.

One again, thank you very much for the help