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
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.
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
I agree with Christopher. I'll update firewalld to v0.6.3 when I get a chance.
firewalld-0.6.3-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-77c401b989
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
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.
Forgot to mention, I had done un upgrade from 28 -> 29.
Adding FirewallBackend=iptables on bother versions 0.6.2 and 0.6.3 didnt work either.
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.
Same errors as above.
Besides the above errors, is there any additional information I can provide?
(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.
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.
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.
Created attachment 1502244 [details] 0.6.3 debug log
I have attached my debug log.
Any update?
Hi, do you need any more information from me?
(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?
What file contains that information?
(In reply to Rick Dicaire from comment #20) > What file contains that information? I think it would be in /etc/firewalld/zones/public.xml
Created attachment 1503833 [details] /etc/firewalld/zones/public.xml Here's my public.xml.
I removed the last rule in public.xml, and firewalld reloaded successfully.
(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.
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?
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.
(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!
No further issues from me.