Rocky 10: interfaces, sources and zones — one REJECT investigated

Test scope

A Rocky Linux 10.2 Server VM with firewalld 2.4.0; ens18 is managed by NetworkManager.

Experiment: put source 192.168.2.2/32 into a new zone with 8089/tcp allowed, connect from that address, and record both the result and the kernel chain. Screenshot: public/evidence/firewalld/rocky-zone-match.png.

Symptom: the rule exists, the connection is rejected

$ firewall-cmd --get-active-zones
labzone
  sources: 192.168.2.2/32
public (default)
  interfaces: ens18
$ firewall-cmd --zone=labzone --list-all | grep -E "^  (sources|ports)"
  sources: 192.168.2.2/32
  ports: 8089/tcp

From 192.168.2.2:

$ curl -v --max-time 6 http://192.168.2.241:8089/
* connect ... failed: No route to host
curl: (7) Failed to connect ... No route to host

A No route to host returned in 0 ms is a REJECT (ICMP admin-prohibited) — not a broken network, not a dropped packet.

Tell the three failure modes apart first

Symptom	Meaning	Where to look
No route to host, 0 ms	REJECT	firewall-cmd --get-active-zones, nft chain
Connection timed out, seconds	DROP or path loss	routing, upstream ACLs
Connection refused, 0 ms	nothing listening	ss -ltn, service state

Mistaking a REJECT for a network fault is the most common detour.

The kernel chain explains it

$ nft list chain inet firewalld filter_INPUT_POLICIES
chain filter_INPUT_POLICIES {
    ip saddr 192.168.2.2 jump filter_IN_policy_allow-host-ipv6
    ip saddr 192.168.2.2 jump filter_IN_labzone
    ip saddr 192.168.2.2 reject with icmpx admin-prohibited
    iifname "ens18" jump filter_IN_policy_allow-host-ipv6
    iifname "ens18" jump filter_IN_public
    iifname "ens18" reject with icmpx admin-prohibited
}

Source and interface each form a segment ending in reject; only the segment that matches decides. Two active zones do not mean two sets of rules are combined.

Interface membership is owned by NetworkManager

$ firewall-cmd --permanent --zone=public --remove-interface=ens18
The interface is under control of NetworkManager, setting zone to default.
$ firewall-cmd --reload && firewall-cmd --get-active-zones
public (default)
  interfaces: ens18

The zone is an NM connection property; --remove-interface is rewritten on reload while NM is in control.

The correct change

nmcli -g connection.zone connection show lab-static   # current value
sudo nmcli connection modify lab-static connection.zone labzone
sudo nmcli connection up lab-static
firewall-cmd --get-active-zones                        # ens18 must move

For combined source/interface control, use firewalld 2.x policies instead of juggling zone membership.

Three commands worth remembering

firewall-cmd --get-active-zones                      # who is active, matched how
nmcli -g connection.zone connection show <connection> # NM's view
nft list chain inet firewalld filter_INPUT_POLICIES  # the final kernel order

Common traps

• Reading --list-all without --get-active-zones: the rule may live in a zone the traffic never reaches;
• Treating REJECT as a network failure: 0 ms already tells you otherwise;
• Skipping the reload and the re-check: NM restores the default zone;
• Adding rules to both the interface zone and a source zone: decide which one handles the traffic first.

Practice: locate with three commands

firewall-cmd --get-active-zones
nmcli -g connection.zone connection show lab-static
sudo nft list chain inet firewalld filter_INPUT_POLICIES | head -8

Checks:

1. Which zone lists the interface;
2. Whether NM agrees;
3. Where the iifname and ip saddr segments and their rejects sit;
4. Conclusion: this traffic is handled by the interface segment, so the source zone’s allow never applies.

FAQ

常见问题

Can one interface belong to two zones?

No. One interface belongs to one zone; use policies or rich rules for multiple sources with different treatment.

Why bring the connection up after changing the zone?

The zone is a connection property; reactivating applies it. A firewalld reload plus a re-check is the safer habit.

Is No route to host always firewalld?

Not always, but when it returns in 0 ms and the port is listening, it is almost certainly a local REJECT; confirm with the nft chain.

Next steps

• Zones and services: /en/firewalld-zones/
• Rich rules: /en/firewalld-rich-rules/
• Direct rules and policies: /en/firewalld-direct-rules/