Description of problem: When nat network is destroyed, one of the iptables rules still exists. Version-Release number of selected component (if applicable): # rpm -q libvirt iptables firewalld kernel libvirt-5.0.0-3.module+el8+2807+8bbe0a41.x86_64 iptables-1.8.2-9.el8.x86_64 firewalld-0.6.3-7.el8.noarch kernel-4.18.0-67.el8.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start the default network. 2. Destroy the default network. 3. Check the iptables rules, it should be all cleared, but there is one still exists: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable Actual results: In step 3, the last rule '-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable' should be cleared, but it didn't Expected results: the last rule should be cleared as well. Additional info:
The logs shows as below, and after a 'firewall-cmd --reload', the legacy rule is cleared successfully. # tail /var/log/messages .... Feb 20 06:58:44 dell-per730-36 nm-dispatcher[11510]: req:4 'down' [virbr0]: new request (3 scripts) Feb 20 06:58:44 dell-per730-36 nm-dispatcher[11510]: req:4 'down' [virbr0]: start running ordered scripts... Feb 20 06:58:44 dell-per730-36 firewalld[1441]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter delete FORWARD --in-interface virbr0 --jump REJECT' failed: Bad argument `delete'#012Try `iptables -h' or 'iptables --help' for more information.
This problem is due to a typo in upstream commit 2deb74f1 that accidentally replaced "--delete" with "delete" when refactoring libvirt's iptables library. This typo was later incidentally fixed by upstream commit 7431b3eb, which was part of the series that moved the iptables rules for each network into their own iptables chain. Commit 2deb74f1 first appeared in libvirt 5.0.0, but 7431b3eb will only be in libvirt 5.1.0, which is why the current rhel8-av exhibits the bad behavior. The patch that fixes the bug is the final patch of a series of 4 patches that makes a sizeable change to libvirt's behavior, see this commit log for a comprehensive list of the advantages to making the change: https://libvirt.org/git/?p=libvirt.git;a=commit;h=5f1e6a7d48c02e02ee50fc9d9818ac1db076f051
Test on libvirt-5.0.0-4.module+el8+2835+faae67de.x86_64, the bug is fixed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:1293