Bug 2029211
| Summary: | firewalld - new (mis)behaviour - when a box want's to be a gateway | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | lejeczek <peljasz> |
| Component: | firewalld | Assignee: | Eric Garver <egarver> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons |
| Severity: | high | Docs Contact: | Jaroslav Klech <jklech> |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | bstinson, egarver, jklech, jwboyer, mmuehlfe, pasik, snemec, todoleza |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: |
.Changed behavior in `firewalld` when transmitting packets between zones
In zone-based firewalls, packets enter only one zone. Implicit packet transmission is the concept violation and can allow traffic or services unexpectedly. In Red Hat Enterprise Linux 9 the `firewalld` service no longer allows implicit packet transmission between two different zones.
For more information about this change, see link:https://access.redhat.com/articles/6570501[Changed behavior in `firewalld` when transmitting packets between zones] Knowledge Article.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-12-06 13:26:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
lejeczek
2021-12-05 19:54:19 UTC
(In reply to lejeczek from comment #0) > Is that really the intention with firewalld-1.0.0-2.el9.noarch Yes. See bug 2020974 comment 1. Solution: `firewalld-cmd --permanent --zone <zone> --add-forward` Nope. The zone (and most by default I think) have forwarding already: -> $ firewall-cmd --zone=external --list-all external (active) target: default icmp-block-inversion: no interfaces: virgincable sources: services: http https ipsec rsyncd ssh ports: 9001/tcp 22067/tcp 22070/tcp 8443/tcp protocols: forward: yes masquerade: yes forward-ports: port=18080:proto=tcp:toport=18080:toaddr=10.3.1.10 source-ports: icmp-blocks: rich rules: unless I add other(s) iface(s) via/from which I want communicate to the outside word (virgincable iface) to that zone, there is no traffic passing through: ... From 10.3.1.100 icmp_seq=238 Packet filtered ... I tried some rules for that zone, one basic such as here: rule priority="-32768" family="ipv4" source address="10.3.1.0/24" masquerade But none of those worked and.. naturally I'd be nice(desired & expected) to not have to tamper with nft directly for such a basic concept as "gateway" regards, L. You need to explicitly allow the forwarding between zones. It sounds like your were relying on the "fall through" behavior mentioned the commit [1] - see the paragraph that starts with "Secondly". The commit changes the behavior of the "default" --set-target. As the commit notes, this "fall through" behavior was unexpected. Packets should not implicitly flow between zones. That's a violation of the zone concept.
The solution is to explicitly allow forwarding between the zones. This can be done in two ways:
1. use the `trusted` zone on the LAN side
- trusted uses --set-target=ACCEPT, so the forwarded traffic is allowed
- this is what podman, libvirt, etc use.
2. use a policy to allow the forwarded traffic
# firewall-cmd --permanent --new-policy masqueradePolicy
# firewall-cmd --permanent --policy masqueradePolicy --add-ingress-zone public
# firewall-cmd --permanent --policy masqueradePolicy --add-egress-zone external
# firewall-cmd --permanent --policy masqueradePolicy --add-masquerade
---
[1]: https://github.com/firewalld/firewalld/commit/f2896e43c3a548a299f87675a01e1a421b8897b8
Additionally, the upstream blog about v1.0.0 may be useful to skim. https://firewalld.org/2021/06/the-upcoming-1-0-0 Guys, put it every place an admin might go first to look for what-is-new, be it change-logs, blogs, official manuals, etc. I see many admins if not all! the admins, will stumble over it day-0, as all this time - Centos for certain - between-zone communication just worked (still does with CentOS 8 Stream's firewalld) without lifting a finger. many thanks, L (In reply to lejeczek from comment #5) > Guys, put it every place an admin might go first to look for what-is-new, be > it change-logs, blogs, official manuals, etc. I linked the commit and the blog already. It's also in the upstream release notes. I'm flagging this bug for a RHEL-9.0 release note. |