Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
nftables fails to load ruleset after service restart and allows communication through ports which are not opened exclusively.
Version-Release number of selected component (if applicable):
nftables-0.9.0-3.el8.x86_64
libnftnl-1.1.1-1.el8.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Installed Red Hat Enterprise Linux release 8.0 Beta (Ootpa)
2. Installed httpd service. Access to this service is blocked from outside which is expected.
2. Stop nftables (systemctl stop nftables)
3. Start nftables (systemctl start nftables)
4. nft list ruleset <---------------------- No output
5. Access to httpd service is allowed from outside.
Actual results:
nftables not loading the rules after service restart.
Expected results:
nftables loading the rules after service restart.
Additional info:
Hi Suresh,
In RHEL8, firewalld manages the host firewall and it uses nftables as backend. The nftables package's services are not in use. If you restart that service (systemctl restart nftables), it will likely flush the nftables ruleset created by firewalld. Unless I miss something, you can reproduce the same situation in RHEL7 if firewalld is running and you restart iptables service.
I am tempted to close this as NOTABUG, but would like to hear your feedback first. What are you trying to achieve? Did you just miss that firewalld service is responsible for the nftables ruleset you're seeing or is it something else?
Cheers, Phil
Hi Phil,
thanks for this. I was also discussing this with one of our SEG (patrick) and he mentioned the same "you can reproduce the same situation in RHEL7 if firewalld is running and you restart iptables service." and I feel very novice here.
May be I should not have touched the 'nftables' services at all. But in the end, the firewalld is running with services "cockpit dhcpv6-client ssh", but still allowed http traffic. So I thought something is broken at firewalld.
Hi Suresh,
(In reply to suresh kumar from comment #4)
> May be I should not have touched the 'nftables' services at all. But in
> the end, the firewalld is running with services "cockpit dhcpv6-client
> ssh", but still allowed http traffic. So I thought something is broken at
> firewalld.
The logs you pasted don't reflect that. I see you showed ss output, but immediately before that you gave proof that nftables ruleset was empty. So please reboot the system before verifying again that http traffic is blocked by firewalld as it should. If not, this is definitely a bug.
Thanks, Phil
Hi Suresh,
(In reply to suresh kumar from comment #6)
> yes. The reboot or firewalld service restart fixes the issue.
OK, thanks for verifying. I'll hereby close the ticket as NOTABUG. In case you disagree, feel free to reopen, of course.
Thanks, Phil