RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1790681 - Firewall configuration stopped working after upgrade
Summary: Firewall configuration stopped working after upgrade
Keywords:
Status: CLOSED DUPLICATE of bug 1772208
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: firewalld
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Eric Garver
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-13 22:21 UTC by Orion Poplawski
Modified: 2020-01-14 00:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-14 00:11:46 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Output of "nft list table inet firewalld" from firewalld 0.7.0 (7.26 KB, text/plain)
2020-01-13 22:21 UTC, Orion Poplawski 		no flags Details
View All

Description Orion Poplawski 2020-01-13 22:21:27 UTC 
Created attachment 1652008 [details]
Output of "nft list table inet firewalld" from firewalld 0.7.0

Description of problem:

System configured with firewalld-0.6.3-7.el8.noarch (8.0) was working fine.  After upgrade to firewalld-0.7.0-5.el8.noarch (8.1) it does not.

I have two zones:

# firewall-cmd --get-active-zones
internal
  sources: 10.0.0.0/8
public
  interfaces: eth0

# firewall-cmd --list-all --zone internal
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 10.0.0.0/8
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" source address="10.0.1.39" port port="10050" protocol="tcp" accept

# firewall-cmd --list-all --zone public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client dns http https kerberos kpasswd ldap ldaps mdns ntp ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Services in the "internal" zone are allowed.  Services in the "public" zone are not.

There is only the one interface (eth0).

"nft list table inet firewalld" output is changed (new output attached), but I can't see anything obvious - but I'm not at all familiar with nftables yet.

With logging on I see:

kernel: FINAL_REJECT: IN=eth0 OUT= MAC=00:16:3e:7e:62:ab:52:54:00:37:3c:2d:08:00 SRC=10.0.1.74 DST=10.0.1.72 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30951 DF PROTO=TCP SPT=48768 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0 
kernel: FINAL_REJECT: IN=eth0 OUT= MAC=00:16:3e:7e:62:ab:b8:ae:ed:7b:6e:a1:08:00 SRC=10.0.0.99 DST=10.0.1.72 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=23141 DF PROTO=UDP SPT=123 DPT=123 LEN=56 

which both should have been allow by the public rules.
Comment 1 Orion Poplawski 2020-01-13 22:33:00 UTC 
Switching FirewallBackend to iptables does not help.
Comment 2 Orion Poplawski 2020-01-13 22:44:13 UTC 
Hmm, appears that this is expected behavior - though I swear it changed.  https://access.redhat.com/solutions/1376003
Comment 3 Akemi Yagi 2020-01-13 22:51:53 UTC 
Is it related to this by any chance? https://access.redhat.com/solutions/4586771
Comment 4 Orion Poplawski 2020-01-13 22:54:12 UTC 
No, firewalld is starting fine.

But on closer reading of https://access.redhat.com/solutions/1376003, I think this really is a regression as we should fall down to the interface zone.
Comment 5 Orion Poplawski 2020-01-13 23:00:16 UTC 
I think this is the relevant change:

--- EL8.0/0.6.3
+++ EL8.1/0.7.0
        chain raw_PREROUTING {
                type filter hook prerouting priority -290; policy accept;
                icmpv6 type { nd-router-advert, nd-neighbor-solicit } accept
                meta nfproto ipv6 fib saddr . iif oif missing drop
-               jump raw_PREROUTING_ZONES_SOURCE
                jump raw_PREROUTING_ZONES
        }
 
-       chain raw_PREROUTING_ZONES_SOURCE {
-               ip saddr 10.0.0.0/8 goto raw_PRE_internal
-       }
-
        chain raw_PREROUTING_ZONES {
+               ip saddr 10.0.0.0/8 goto raw_PRE_internal
                iifname "eth0" goto raw_PRE_public
                goto raw_PRE_public
        }
....
        chain filter_INPUT {
                type filter hook input priority 10; policy accept;
                ct state established,related accept
+               ct status dnat accept
                iifname "lo" accept
-               jump filter_INPUT_ZONES_SOURCE
                jump filter_INPUT_ZONES
                ct state invalid drop
                reject with icmpx type admin-prohibited
....
 
-       chain filter_INPUT_ZONES_SOURCE {
-               ip saddr 10.0.0.0/8 goto filter_IN_internal
-       }
-
        chain filter_INPUT_ZONES {
+               ip saddr 10.0.0.0/8 goto filter_IN_internal
                iifname "eth0" goto filter_IN_public
                goto filter_IN_public
        }
Comment 6 Orion Poplawski 2020-01-13 23:07:29 UTC 
# firewall-cmd --permanent --zone=internal --get-target
default
Comment 7 Eric Garver 2020-01-14 00:11:46 UTC 
This is a duplicate of bug 1772208.

*** This bug has been marked as a duplicate of bug 1772208 ***
Note You need to log in before you can comment on or make changes to this bug.