RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1164243 - [rhel 7.1.4] Firewalld support
Summary: [rhel 7.1.4] Firewalld support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Lokesh Mandvekar
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1133060
TreeView+ depends on / blocked
 
Reported: 2014-11-14 12:35 UTC by Jiri Popelka
Modified: 2019-08-15 04:05 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Docker does not support managing IPtable rules via firewalld. Consequence: If firewalld and iptables attempt to adjust rules at the same time, it is possible for filtering rules to be applied incorrectly (or not at all) Fix: Implement code to check if firewalld is running on the system. If it is, pass filtering rules through firewalld. If firewalld is reloaded, then re-apply filtering rules and configuration. Result: Firewalld is now supported in docker -- and if it is running on the system, then rules will be added via firewalld passthrough. If firewalld is reloaded, configuration will be re-applied.
Clone Of:
Environment:
Last Closed: 2015-08-06 00:31:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1536 0 normal SHIPPED_LIVE docker bug fix and enhancement update 2015-08-06 04:31:26 UTC

Description Jiri Popelka 2014-11-14 12:35:57 UTC 
Support for firewalld in docker would solve two problems:

1) firewalld restart/reload flushes all docker's iptables rules
Solution would be in reacting to org.fedoraproject.FirewallD1.Reloaded() signal and recreating all the previously added iptables rules.
Problem is that I don't think docker tracks anywhere what rules have been added, so the change would probably not be as simple.

2) When docker and firewalld call iptables tool at the same moment the second one fails because the first one is holding xtables lock.
There are 2 possible solutions:
a) both docker and firewalld would use --wait/-w option when calling iptables
Docker has been doing this since
https://github.com/docker/docker/commit/b315c380f4acd65cc0428009702f99a266f96c59
which was released first with docker-v0.12.0, so it's included in docker-v1.2.0 we have in extras-rhel-7.1.
Firewalld upstream commit is https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=b3b451d6f8946986b8f50c8bcddeef50ed7a5f8f and RHEL7 BZ is bug #1161745
b) In case there's firewalld running, docker would use its D-Bus interface instead of calling iptables directly.
I've been working on this recently, I'm half-way there,
I just need to find out how to do things not so awkward way & test it.


You can assign this BZ to me if you want.
Comment 1 Jiri Popelka 2014-11-26 18:25:43 UTC 
There's been firewalld branch in my docker fork.
https://github.com/jpopelka/docker/tree/firewalld

These two commits should add the firewalld support and therefore solve the above described problems:
https://github.com/jpopelka/docker/commit/46d4f66aadbad25899fba2f13674df12923b7e39
https://github.com/jpopelka/docker/commit/3b295156e48db1486f5fa347c5e2814637385d74

If you know somebody who can take a look at them before I create a pull request, I'll be glad if you can point him/her to it so we can increase our chances for merging them upstream. Thanks!
Comment 2 Daniel Walsh 2014-11-26 21:00:02 UTC 
Make sure you run these through gofmt.


+ if err != nil {
+ fmt.Println("Failed to connect to D-Bus system bus:", err)
+ }
+

Should the be a log.Errorf()
Comment 3 Jiri Popelka 2014-11-28 12:41:52 UTC 
Thanks Dan, you're right.

Here's upstream issue & pull request:
https://github.com/docker/docker/issues/9395
Comment 5 Jiri Popelka 2014-12-03 17:47:18 UTC 
(In reply to Jiri Popelka from comment #3)
> Here's upstream issue & pull request:
> https://github.com/docker/docker/issues/9395

In case it's not obvious from the issue, the pull request is:
https://github.com/docker/docker/pull/9397
Comment 6 Daniel Walsh 2014-12-04 09:29:48 UTC 
Looks like that pull request is being hung up for better unit tests.
Comment 8 Jiri Popelka 2015-04-24 08:21:37 UTC 
Merged upstream:
https://github.com/docker/docker/commit/259effc6dfd901130ca6d2926090bddfe35f7cdc
Comment 9 Daniel Walsh 2015-04-24 14:31:08 UTC 
Fixed in docker-1.7 When it ships.
Comment 10 Thomas Woerner 2015-06-11 12:52:54 UTC 
Assigning to the default owner of the docker component.
Comment 11 Lokesh Mandvekar 2015-06-11 13:38:07 UTC 
Dan, so this is probably a candidate for 7.1.4, right?
Comment 12 Daniel Walsh 2015-06-17 22:02:13 UTC 
Yes
Comment 13 Luwen Su 2015-07-24 09:25:58 UTC 
Hi Jiri,

Do i need the latest firewalld to make the support success?
The latest firewalld i can get is firewalld-0.3.9-12.el7.noarch in RHEL7, docker is docker-1.7.1-105.el7.x86_64 which includes those patches btw.

And after reload, the firewalld still flushes all dockers rule so that the container will lose connection.

Steps like:(start all daemon in foreground for easy checking debug log )
#firewalld --no-fork --debug 1
#docker -d -D --selinux-enabled
Now the iptable-save can get the dockers iptable rule

#firewall-cmd --reload
All docker iptable rule were erased and docker daemon show nothing

journel error message:
journal: operation failed: filter 'allow-arp' already exists with uuid f2a01626-247c-4d52-8b4d-0a231496c2d1
journal: operation failed: filter 'allow-dhcp-server' already exists with uuid e50f60ab-7518-4ed5-8205-acd47c33d72b
journal: operation failed: filter 'allow-dhcp' already exists with uuid 3ac27d9f-94fd-41c0-8b91-1eb8b500f914
ournal: operation failed: filter 'allow-incoming-ipv4' already exists with uuid f87d158f-70f2-448f-b6a1-11eaaaa26243
journal: operation failed: filter 'allow-ipv4' already exists with uuid 9a32ff01-9e93-458a-b3bf-ca700e317bc5
journal: operation failed: filter 'clean-traffic' already exists with uuid 65b666a8-51d7-46b6-879a-251363843c7e
journal: operation failed: filter 'no-arp-ip-spoofing' already exists with uuid 76153d69-c55c-466f-9456-e6db1b29b100
journal: operation failed: filter 'no-arp-mac-spoofing' already exists with uuid b172576d-2d69-4bde-9325-91fb7909d52c
journal: operation failed: filter 'no-arp-spoofing' already exists with uuid 73f4fe72-b6b9-4a95-b263-3814949e344d
journal: operation failed: filter 'no-ip-multicast' already exists with uuid 3b859870-965b-43f1-a432-818d629d869a
journal: operation failed: filter 'no-ip-spoofing' already exists with uuid 4857b80d-6388-4292-aea4-cb51d78c48c5
journal: operation failed: filter 'no-mac-broadcast' already exists with uuid e90f5089-72fa-4602-ae0a-fcf69b6e83c7
journal: operation failed: filter 'no-mac-spoofing' already exists with uuid 8a04362c-8530-46ba-9439-b5b9792084b3
journal: operation failed: filter 'no-other-l2-traffic' already exists with uuid 5e14eb96-4cdf-47fd-bdf5-30424af55f6d
journal: operation failed: filter 'no-other-rarp-traffic' already exists with uuid 80796b32-adbc-4f04-a4fd-57a7f1784f8f
journal: operation failed: filter 'qemu-announce-self-rarp' already exists with uuid 3da7e953-a5a9-4bf7-a84a-f10596e6b88d
journal: operation failed: filter 'qemu-announce-self' already exists with uuid 5e48c76b-d953-40e6-9a27-d185c11a6ea8
Comment 14 Alec Benson 2015-07-24 14:05:28 UTC 
@Luwen I was not able to reproduce this in Fedora 21, but I will grab a RHEL VM and test it out there. I will report back with results when that is done.
Comment 15 Alec Benson 2015-07-24 18:16:28 UTC 
I tried to emulate your situation as closely as I could. I am still unable to reproduce the errors that you are seeing. 

I tested on a Centos 7 x64 environment running firewalld-0.3.9-11.el7.noarch.
I am using the RPM from:
 http://koji.fedoraproject.org/koji/buildinfo?buildID=671790

Are you positive the version you are running has the fixes?
Comment 17 Luwen Su 2015-07-27 05:33:30 UTC 
(In reply to Alec Benson from comment #15)
> I tried to emulate your situation as closely as I could. I am still unable
> to reproduce the errors that you are seeing. 
> 
> I tested on a Centos 7 x64 environment running firewalld-0.3.9-11.el7.noarch.
> I am using the RPM from:
>  http://koji.fedoraproject.org/koji/buildinfo?buildID=671790
> 
> Are you positive the version you are running has the fixes?

Thanks your update Alec, seems like the it's either the previous docker version or my machines issue,

With the new one docker-1.7.1-107.el7.x86_64, firewalld is firewalld-0.3.9-12.el7.noarch , same as before, the #firewall-cmd --reload doesn't flush the docker rules anymore.

Move to verified
Comment 19 errata-xmlrpc 2015-08-06 00:31:46 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://rhn.redhat.com/errata/RHBA-2015-1536.html
Note You need to log in before you can comment on or make changes to this bug.