Bug 1644432 - firewalld refused to load public rules
Summary: firewalld refused to load public rules
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 29
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Eric Garver
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-30 19:57 UTC by Jonathan Briggs
Modified: 2019-10-22 02:52 UTC (History)
7 users (show)

Fixed In Version: firewalld-0.6.3-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-04 06:51:43 UTC
Type: Bug


Attachments (Terms of Use)
Today's firewalld debug log (305.89 KB, text/plain)
2018-10-30 19:57 UTC, Jonathan Briggs
no flags Details
0.6.3 debug log (62.70 KB, text/plain)
2018-11-06 00:40 UTC, Rick Dicaire
no flags Details
/etc/firewalld/zones/public.xml (1.62 KB, application/xml)
2018-11-09 19:52 UTC, Rick Dicaire
no flags Details

Description Jonathan Briggs 2018-10-30 19:57:04 UTC
Created attachment 1499076 [details]
Today's firewalld debug log

Description of problem:
After upgrading a server to Fedora 29 it refused to open the firewall for the public server ports. Investigation showed firewalld failures. 

(Unrelated to firewalld the other error was that the Ethernet interface name changed _yet_again_ and had to be manually updated in /etc/firewalld/zones/public.xml. I think this is now every other Fedora release that likes to move this name around. If it is supposed to be a stable position on the PCI bus why is it enp3s0 yesterday, p32p1 a couple years ago and enp8s0 now?)

I was able to work around the bug by manually setting FirewallBackend=nftables in the configuration file. Although now it seems all of my virbr0 rules are failing.

Version-Release number of selected component (if applicable):
firewalld-0.6.2-1.fc29.noarch

Steps to Reproduce:
1. Install Fedora 28
2. Set some custom firewall rules on public.
3. Upgrade to Fedora 29.

Actual results:
No firewall rules from the public zone.

I will attach today's firewalld.log entries. I had it in debug mode.

The main error appears to be misnamed chains, like this: 
2018-10-30 12:11:42 ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.0 (legacy): goto 'PRE_public' is not a chain

Comment 1 Christopher Engelhard 2018-10-31 21:51:40 UTC
This looks like the error reported upstream in Issue 374 [1]. It has been fixed in 0.6.3 [2]. Installing that version fixed this error (and the related issues with ipsets) for me.

0.6.3 worked without issues both in Rawhide and on Fedora 29, so I suggest pushing that into the repositories.

Comment 2 Christopher Engelhard 2018-10-31 21:52:52 UTC
I'm an idiot, forgot the links.

[1] https://github.com/firewalld/firewalld/issues/374
[2] https://github.com/firewalld/firewalld/compare/v0.6.2...v0.6.3

Comment 3 Eric Garver 2018-11-01 12:31:37 UTC
I agree with Christopher. I'll update firewalld to v0.6.3 when I get a chance.

Comment 4 Fedora Update System 2018-11-01 13:10:53 UTC
firewalld-0.6.3-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-77c401b989

Comment 5 Fedora Update System 2018-11-01 15:41:22 UTC
firewalld-0.6.3-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-77c401b989

Comment 6 Rick Dicaire 2018-11-04 01:05:51 UTC
Updating to 0.6.3 in testing did not solve problem.

Nov 03 16:58:43 hostname firewalld[708]: ERROR: argument of type 'Rich_Destination' is not iterable
Nov 03 16:58:43 hostname firewalld[708]: ERROR: COMMAND_FAILED: argument of type 'Rich_Destination' is not iterable
Nov 03 16:58:44 hostname firewalld[708]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.0 (legacy): goto 'PRE_public' is not a chain
                                             
                                             Error occurred at line: 2
                                             Try `iptables-restore -h' or 'iptables-restore --help' for more information.
Nov 03 16:58:44 daw.diix.org firewalld[708]: ERROR: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore v1.8.0 (legacy): goto 'PRE_public' is not a chain
                                             
                                             Error occurred at line: 2
                                             Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.
Nov 03 16:58:44 daw.diix.org firewalld[708]: ERROR: COMMAND_FAILED: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore v1.8.0 (legacy): goto 'PRE_public' is not a chain
                                             
                                             Error occurred at line: 2
                                             Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.

Comment 7 Rick Dicaire 2018-11-04 01:30:13 UTC
Forgot to mention, I had done un upgrade from 28 -> 29.

Comment 8 Rick Dicaire 2018-11-04 02:44:16 UTC
Adding FirewallBackend=iptables on bother versions 0.6.2 and 0.6.3 didnt work either.

Comment 9 Fedora Update System 2018-11-04 06:51:43 UTC
firewalld-0.6.3-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 Rick Dicaire 2018-11-04 14:29:29 UTC
Same errors as above.

Comment 11 Rick Dicaire 2018-11-05 14:26:35 UTC
Besides the above errors, is there any additional information I can provide?

Comment 12 Eric Garver 2018-11-05 15:09:23 UTC
(In reply to Rick Dicaire from comment #11)
> Besides the above errors, is there any additional information I can provide?

Did the v0.6.3 update not work? Did you restart firewalld? Can you check the logs again, maybe you have a different issues now.

Comment 13 Rick Dicaire 2018-11-05 15:51:36 UTC
The upgrade to 0.6.3 itself was successful, but it did not resolve the problem.
First I tried 0.6.3 from testing. Same errors. Then I downgraded back to 0.6.2. Same errors. When 0.6.3 was pushed to prod I upgraded again. Same errors. I rebooted after each upgrade/downgrade/upgrade just to ensure I as flushing any potential conflicts.

Comment 14 Eric Garver 2018-11-05 17:12:17 UTC
The errors you show in comment 6 aren't helpful because firewalld batches commands with iptables-restore (which has terrible error reporting). Can you enable debug and post the log? You can also set IndividualCalls=yes it /etc/firewalld/firewalld.conf to get more explicit calls/errors.

Comment 15 Rick Dicaire 2018-11-06 00:40:36 UTC
Created attachment 1502244 [details]
0.6.3 debug log

Comment 16 Rick Dicaire 2018-11-06 00:41:03 UTC
I have attached my debug log.

Comment 17 Rick Dicaire 2018-11-07 22:37:50 UTC
Any update?

Comment 18 Rick Dicaire 2018-11-09 15:50:30 UTC
Hi, do you need any more information from me?

Comment 19 Eric Garver 2018-11-09 16:40:55 UTC
(In reply to Rick Dicaire from comment #18)
> Hi, do you need any more information from me?

You are experiencing a different issue. It looks like you may have a rich rule triggering things complaint from iptables:

ValueError: '/usr/sbin/iptables -w10 -A IN_public_log -t filter -p tcp --dport 80 -d destination address="192.168.20.1" -d 192.168.20.1 -m set ! --match-set home src -m conntrack --ctstate NEW,UNTRACKED -j LOG --log-prefix 'TL0G_80: ' --log-level warning' failed: iptables v1.8.0 (legacy): multiple -d flags not allowed
Try `iptables -h' or 'iptables --help' for more information.

Can you show me the rich rule you're using that matches source address 192.168.20.1?

Comment 20 Rick Dicaire 2018-11-09 17:37:46 UTC
What file contains that information?

Comment 21 Eric Garver 2018-11-09 19:29:04 UTC
(In reply to Rick Dicaire from comment #20)
> What file contains that information?

I think it would be in /etc/firewalld/zones/public.xml

Comment 22 Rick Dicaire 2018-11-09 19:52:56 UTC
Created attachment 1503833 [details]
/etc/firewalld/zones/public.xml

Here's my public.xml.

Comment 23 Rick Dicaire 2018-11-11 14:48:53 UTC
I removed the last rule in public.xml, and firewalld reloaded successfully.

Comment 24 Eric Garver 2018-11-15 20:37:55 UTC
(In reply to Rick Dicaire from comment #23)
> I removed the last rule in public.xml, and firewalld reloaded successfully.

Can you file a separate BZ and post this config? There appears to be an issue handling that particular rich rule.

Comment 25 Zdenek Dohnal 2019-03-12 13:17:12 UTC
I hit the same problem as Rick - is the bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1650995 the one you created for the issue, Rick?

Comment 26 Rick Dicaire 2019-03-12 14:07:43 UTC
Zdenek, yes. As noted above, I removed the offending entry from the XML file and was able to successfully start firewalld. https://bugzilla.redhat.com/show_bug.cgi?id=1650995 reports an issue with kernel message format for rich rules configured to out a prefix in syslog, another problem I discovered once firewalld was running again.

Comment 27 Zdenek Dohnal 2019-03-12 14:15:07 UTC
(In reply to Rick Dicaire from comment #26)
> Zdenek, yes. As noted above, I removed the offending entry from the XML file
> and was able to successfully start firewalld.
> https://bugzilla.redhat.com/show_bug.cgi?id=1650995 reports an issue with
> kernel message format for rich rules configured to out a prefix in syslog,
> another problem I discovered once firewalld was running again.

Ok, I understood it like Eric asked you to report the error which you had until you removed rich rule from xml file. IIUC there is no bugzilla report for it? And mentioned bug is for different issue.

Anyway, thank you!

Comment 28 Rick Dicaire 2019-10-22 02:52:52 UTC
No further issues from me.


Note You need to log in before you can comment on or make changes to this bug.