Bug 1674076

Summary:

firewall-cmd --reload breaks connectivity

Product:

[Fedora] Fedora

Reporter:

David Hill <dhill>

Component:

firewalld

Assignee:

Eric Garver <egarver>

Status:

CLOSED DUPLICATE

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

urgent

Docs Contact:

Priority:

unspecified

Version:

rawhide

CC:

egarver, jpopelka, twoerner

Target Milestone:

---

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

If docs needed, set a value

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2019-02-09 21:31:12 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:

Embargoed:

Attachments:

Description	Flags
firewalld logs	none
firewalld configuration files	none
script used to configure the local firewall.	none
firewalld in debug while reproducing the issue	none
dnf.rpm.log ... the issue started today after updating packages I guess.	none

Description David Hill 2019-02-09 00:09:20 UTC

Description of problem:
firewall-cmd --reload breaks connectivity and firewalld needs to be restarted in order to recover access.     It somehow uses nft when reloading even though the backend being used is iptables.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  Update to latest rawhide
2.  send firewall-cmd --reload
3.

Actual results:
INPUT policy becomes DROP
OUTPUT policy becomes DROP

Expected results:
Nothing should happen actually

Additional info:

Comment 1 David Hill 2019-02-09 00:09:47 UTC

Created attachment 1528251 [details]
firewalld logs

Comment 2 David Hill 2019-02-09 00:10:50 UTC

Created attachment 1528252 [details]
firewalld configuration files

Comment 3 David Hill 2019-02-09 00:12:00 UTC

Created attachment 1528253 [details]
script used to configure the local firewall.

Comment 4 David Hill 2019-02-09 00:53:15 UTC

When I reload, one of the first thing we notice is that the following:
[root@zappa log]# iptables -nL | grep policy
Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)

becomes:
[root@zappa log]# iptables -nL | grep policy
Chain INPUT (policy DROP)
Chain FORWARD (policy DROP)
Chain OUTPUT (policy DROP)

and running "systemctl restart firewalld" restores all the rules and policy.

Comment 5 David Hill 2019-02-09 01:00:16 UTC

Created attachment 1528254 [details]
firewalld in debug while reproducing the issue

Comment 6 David Hill 2019-02-09 01:03:55 UTC

This is when I restarted firewalld in debug:
2019-02-08 19:57:31 DEBUG1: start()

and this is probably when the issue starts:

2019-02-08 19:58:29 DEBUG1: reload()
2019-02-08 19:58:29 DEBUG1: Setting policy to 'DROP'

Comment 7 David Hill 2019-02-09 01:08:52 UTC

Created attachment 1528256 [details]
dnf.rpm.log ... the issue started today after updating packages I guess.

Comment 8 David Hill 2019-02-09 01:12:22 UTC

One last comment for today and is ... you can forget my initial comment about nft as I just noticed the firewalld logs were never rotated and this issue happend when we migrated to nft which I reverted by changing back the backend to iptables.

Comment 9 Eric Garver 2019-02-09 21:31:12 UTC

(In reply to David Hill from comment #5)
> Created attachment 1528254 [details]
> firewalld in debug while reproducing the issue

From the logs:

  firewall.errors.FirewallError: COMMAND_FAILED: '/usr/sbin/ebtables-restore --noflush' failed: Bad table name 'nat'.

So marking it a duplicate of bug 1672683.

*** This bug has been marked as a duplicate of bug 1672683 ***