Bug 1674076 - firewall-cmd --reload breaks connectivity
Summary: firewall-cmd --reload breaks connectivity
Keywords:
Status: CLOSED DUPLICATE of bug 1672683
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Eric Garver
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-09 00:09 UTC by David Hill
Modified: 2019-02-09 21:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-09 21:31:12 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
firewalld logs (2.11 MB, text/plain)
2019-02-09 00:09 UTC, David Hill 		no flags Details
firewalld configuration files (2.48 KB, application/gzip)
2019-02-09 00:10 UTC, David Hill 		no flags Details
script used to configure the local firewall. (4.51 KB, text/plain)
2019-02-09 00:12 UTC, David Hill 		no flags Details
firewalld in debug while reproducing the issue (2.27 MB, text/plain)
2019-02-09 01:00 UTC, David Hill 		no flags Details
dnf.rpm.log ... the issue started today after updating packages I guess. (132.89 KB, text/plain)
2019-02-09 01:08 UTC, David Hill 		no flags Details
View All

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 ***
Note You need to log in before you can comment on or make changes to this bug.