FIREWALLD.POLICIES(5)
π FIREWALLD.POLICIES(5) π
okay bestie, welcome to firewalld.policies β yes that's the manual name, and yes we're about to make policies make sense. i got you π«Ά
πΈ NAME πΈ
firewalld.policies β firewalld policies, fr fr
β¨ DESCRIPTION β¨
π What is a policy?
so likeβ¦ a policy applies a set of rules to traffic flowing between zones (peep firewalld.zones(5) if you need the zone lore). The policy affects traffic in a stateful unidirectional manner, e.g. zoneA to zoneB. That's literally the whole point β it lets you do asymmetric filtering policies. one-way streets, but for packets π
A policy's relationship to zones gets defined by assigning a set of ingress zones and a set of egress zones. For example, if the set of ingress zones contains "internal" and the set of egress zones contains "external" then the policy will affect all traffic flowing from the "internal" zone to the "external" zone. But β and this is the iconic part β since policies are unidirectional it will not apply to traffic flowing from "external" to "internal". the ingress set and egress set may contain multiple zones, no cap.
below is a visual representation of policy foobar followed by the CLI commands to create it. This policy would affect traffic flowing from the internal zone to the external zone. Initially, the target is set to ACCEPT to allow all traffic. This is common if the internal network is trusted. π€
+----------+ +----------+
| | policy | |
| internal | --------> | external |
| zone | foobar | zone |
| | | |
+----------+ +----------+
# firewall-cmd --permanent --new-policy foobar
# firewall-cmd --permanent --policy foobar --add-ingress-zone internal
# firewall-cmd --permanent --policy foobar --add-egress-zone external
# firewall-cmd --permanent --policy foobar --set-target ACCEPT
# firewall-cmd --reload
Perhaps it makes sense to be more restrictive. This example changes foobar so that it only allows: dns, http, and https traffic. Everything else is blocked. Clients would only be allowed to surf the web. πβ¨
# firewall-cmd --permanent --policy foobar --set-target REJECT
# firewall-cmd --permanent --policy foobar --add-service dns
# firewall-cmd --permanent --policy foobar --add-service http
# firewall-cmd --permanent --policy foobar --add-service https
# firewall-cmd --reload
π¦ Active Policies
Policies only become active if all of the following are true. like, every single one. no skipping. π
- The policy is not disabled.
- The ingress zones list contain at least one regular zone or a single symbolic zone.
- The egress zones list contain at least one regular zone or a single symbolic zone.
- For non symbolic zones, the zone must be active. That is, it must have interfaces or sources assigned to it.
If the policy is not active then the policy has no effect. π like it's justβ¦ there. vibing. doing nothing.
π Symbolic Zones
Regular zones are not enough to express every form of packet filtering. For example there is no zone to represent traffic flowing to or from the host running firewalld. As such, there are some symbolic zones to fill these gaps. However, symbolic zones are unique in that they're the only zone allowed in the ingress or egress zone sets. For example, you cannot use "public" and "HOST" in the ingress zones. pick a lane bestie π€
Symbolic zones:
HOST
This symbolic zone is for traffic flowing to or from the host running firewalld. This corresponds to netfilter (iptables/nftables) chains INPUT and OUTPUT. π
- If used in the egress zones list it will apply to traffic on the
INPUTchain. - If used in the ingress zones list it will apply to traffic on the
OUTPUTchain.
ANY
This symbolic zone behaves like a wildcard for the ingress and egress zones. With the exception that it does not include "HOST". It's useful if you want a policy to apply to every zone. β¨
- If used in the ingress zones list it will apply for traffic originating from any zone.
- If used in the egress zones list it will apply for traffic destined to any zone.
π Predefined Policies
firewalld ships with some predefined policies. These may or may not be active by default. For details see the description of each policy. iykyk π¦
allow-host-ipv6
π Similarity to Zones
Policies are similar to zones in that they are an attachment point for firewalld's primitives: services, ports, forward ports, etc. This is not a coincidence. Policies are a generalization of how zones have traditionally achieved filtering. In fact, in modern firewalld zones are internally implemented as a set of policies. the family tree is real π³
The main difference between policies and zones is that policies allow filtering in all directions: input, output, and forwarding. With a couple of exceptions zones only allow input filtering which is sufficient for an end station firewalling. However, for network level filtering or filtering on behalf of virtual machines and containers something more flexible, i.e. policies, are needed. main character energy tbh π
π₯ SEE ALSO π₯
firewall-applet(1), firewalld(1), firewall-cmd(1), firewall-config(1), firewalld.conf(5), firewalld.direct(5), firewalld.dbus(5), firewalld.icmptype(5), firewall-offline-cmd(1), firewalld.richlanguage(5), firewalld.service(5), firewalld.zone(5), firewalld.zones(5), firewalld.policy(5), firewalld.policies(5), firewalld.ipset(5), firewalld.helper(5)
π NOTES π
firewalld home page:
π«Ά AUTHORS π«Ά
Thomas Woerner <twoerner@redhat.com> Developer
Jiri Popelka <jpopelka@redhat.com> Developer
Eric Garver <eric@garver.life> Developer
and that's the whole page, bestie!! this was firewalld version 2.5.2, brought to you by the firewalld.policies manual β go forth and filter asymmetrically, you absolute icon πβ¨π
π¦ where this page comes from
- arch rolling: firewalld 2.5.2-1 Β· GPL-2.0-or-later
- nixpkgs unstable: firewalld 2.5.2
- ubuntu stonking: firewalld 2.5.2-1 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms