Bug 1738785

Summary: Firewalld shows ip6tables error when IPv6 is disabled.
Product: Red Hat Enterprise Linux 7 Reporter: Akhil John <ajohn>
Component: firewalldAssignee: Eric Garver <egarver>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: urgent Docs Contact: Marc Muehlfeld <mmuehlfe>
Priority: urgent    
Version: 7.7CC: acurley, andreas.mohr, dkinkead, egarver, jeharris, jmaxwell, joshua.megerman, marcin.rucinski, mjahoda, mmilgram, pasik, pdwyer, ptalbert, rameshn2, todoleza, toneata, winstan
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: firewalld-0.6.3-3.el7 Doc Type: Bug Fix
Doc Text:
.`firewalld` no longer attempts to create IPv6 rules if the IPv6 protocol is disabled Previously, if the IPv6 protocol was disabled, the `firewalld` service incorrectly attempted to create rules using the `ip6tables` utility, even though `ip6tables` should not be usable. As a consequence, when `firewalld` initialized the firewall, the service logged error messages. This update fixes the problem, and `firewalld` now only initializes IPv4 rules if IPv6 is disabled.
Story Points: ---
Clone Of:
: 1744441 (view as bug list) Environment:
Last Closed: 2020-03-31 20:00:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1744441    

Description Akhil John 2019-08-08 07:35:37 UTC
Description of problem:
Firewalld shows "UNKNOWN_ERROR: 'ip6tables' backend does not exist" when IPv6 is disabled.

Version-Release number of selected component (if applicable):
firewalld-0.6.3-2.el7.noarch


How reproducible:
Always

Steps to Reproduce:
1.Disable IPv6 and reboot

2. Check firewalld status.


Actual results:
 WARNING: ip6tables not usable, disabling IPv6 firewall.
 ERROR: UNKNOWN_ERROR: 'ip6tables' backend does not exist
 ERROR: COMMAND_FAILED: UNKNOWN_ERROR: 'ip6tables' backend does not exist
 ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore: line 10 failed

 ERROR: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore: line 10 failed

 ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: goto 'FWDI_public' is not a chain

Error occurred at line: 2
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

 ERROR: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: goto 'FWDI_public' is not a chain

Error occurred at line: 2
Try `iptables-restore -h' or 'iptables-restore --help' for more information.


Expected results:
SHould have NO errors

Additional info:
This issue is only with firewalld-0.6.3-2.el7.noarch when IPv6 is disabled.

Comment 2 Andreas Mohr 2019-08-08 07:44:07 UTC
hi,
we can confirm this issue.

current firewalld-0.6.3-2.el7.noarch will work with kernel boot parameter ipv6.disable=0
current firewalld-0.6.3-2.el7.noarch will NOT work with kernel boot parameter ipv6.disable=1

previous firewalld-0.5.3-5.el7.noarch will work with kernel boot parameter ipv6.disable=0
previous firewalld-0.5.3-5.el7.noarch will work with kernel boot parameter ipv6.disable=1

Comment 3 Eric Garver 2019-08-08 12:45:16 UTC
This has already been fixed upstream:

  bcb33e448abb ("fix: tests: guard occurrences of IPv6")
  3ac719c1908d ("fix: tests/functions: ignore warnings about missing ip6tables")
  d569d7239f23 ("test: add macro IF_IPV6_SUPPORTED")
  4d5c3f190dc3 ("test: add macro HOST_SUPPORTS_IP6TABLES")
  8533c488a30d ("test: pass IPTABLES make variables down to autotest")
  3fdffa76be42 ("fix: avoid calling backends that aren't available")

Comment 6 Eric Garver 2019-08-09 12:29:51 UTC
*** Bug 1739415 has been marked as a duplicate of this bug. ***

Comment 21 errata-xmlrpc 2020-03-31 20:00:54 UTC
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-2020:1109