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 1129622 - Docker daemon parameter --iptable=true leave mess in iptables after daemon finish
Summary: Docker daemon parameter --iptable=true leave mess in iptables after daemon fi...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1113141
TreeView+ depends on / blocked
 
Reported: 2014-08-13 11:21 UTC by Jiri Zupka
Modified: 2019-03-06 01:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-24 19:11:09 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jiri Zupka 2014-08-13 11:21:54 UTC 
Description of problem:
rhel with disabled firewalld.service.
Docker daemon with started with paramter --iptable=true --icc=false. Leaves in iptables some rules.

0        0 DROP       all  --  docker0 docker0  0.0.0.0/0   0.0.0.0/0           
0        0 ACCEPT     all  --  *      docker0  0.0.0.0/0   0.0.0.0/0  ctstate RELATED,ESTABLISHED
0        0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0  0.0.0.0/0

When docker is started again with with --iptables=false then it could
makes hidden problems with containers which are not able communicate. 



+ really minor think and minor problem in implementation in networkdriver/bridge/driver.go L:178 in got master branch with last commit  
       4398108433121ce2ac9942e607da20fa1680871a
Docker daemon iptables rules are different order after
  iptables -F
  docker -d --iptables=true --icc=true
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0 
  docker -d --iptables=true --icc=false
    DROP       all  --  0.0.0.0/0  0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0
  docker -d --iptables=true --icc=true
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0           
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0  0.0.0.0/0

Version-Release number of selected component (if applicable):
docker-1.1.2-9.el7

How reproducible:
always


Steps to Reproduce:
1. systemctl stop firewalld.service
2. iptables -F (for sure)
3. systemctl stop docker.socket
4. systemctl stop docker.service
5. docker -d --iptables=true --icc=false
6. iptable -L  show some docker rules
7. terminate correctly docker daemon (ctrl-c)
8. iptables -L  show iptables rules which left there after docker daemon finish


Actual results:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Expected results:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 


Additional info:
Comment 2 Daniel Walsh 2014-08-13 20:30:15 UTC 
Not sure if cleaning up here is a good idea either.  Does docker know if it added the rules, so that it can remove them?  I would hate to have docker make firewall rules less strict when it exits
Comment 3 Jiri Zupka 2014-09-24 19:11:09 UTC 
When docker will make containers standalone then it shouldn't be problem any more, moreover it will be needed behavior.

Standalone docker container -> when system kill docker daemon all docker 
                               containers stay alive
Note You need to log in before you can comment on or make changes to this bug.