# systemctl disable iptables.service # systemctl mask iptables.service
There are many system components including OpenShift Origin, containers, and software that manage local firewall policies that rely on the kernel iptables configuration for proper network operation. In addition, the iptables configuration of all nodes in the cluster must be correct for networking to work.
All components independently work with iptables without knowledge of how other components are using them. This makes it very easy for one component to break another component’s configuration. Further, OpenShift Origin and the Docker service assume that iptables remains set up exactly as they have set it up. They may not detect changes introduced by other components and if they do there may be some lag in implementing the fix. In particular, OpenShift Origin does monitor and fix problems. However, the Docker service does not.
|
Ensure that any changes you make to the iptables configuration on a node do not impact the operation of OpenShift Origin and the Docker service. Also, changes will often need to be made on all nodes in the cluster. Use caution, as iptables is not designed to have multiple concurrent users, and is very easy to break OpenShift Origin and Docker networking. OpenShift Origin provides several chains, one of which is specifically intended
for administrators to use for their own purposes:
See the discussion of using iptables rules to limit access to external resources for more information. |
The chains, order of the chains, and rules in the kernel iptables must be properly set up on each node in the cluster for OpenShift Origin and Docker networking to work properly. There are several tools and services that are commonly used in the system that interact with the kernel iptables and can accidentally impact OpenShift Origin and the Docker service.
The iptables tool can be used to set up, maintain, and inspect the tables of IPv4 packet filter rules in the Linux kernel.
Independent of other use, such as a firewall, OpenShift Origin and the the Docker service manage chains in some of the tables. The chains are inserted in specific order and the rules are specific to their needs.
|
|
The iptables service supports a local network firewall. It assumes total control of the iptables configuration. When it starts, it flushes and restores the complete iptables configuration. The restored rules are from its configuration file, /etc/sysconfig/iptables. The configuration file is not kept up to date during operation, so the dynamically added rules are lost during every restart.
|
Stopping and starting iptables.service will destroy configuration that is required by OpenShift Origin and Docker. OpenShift Origin and Docker are not notified of the change. |
# systemctl disable iptables.service # systemctl mask iptables.service
If you need to run iptables.service, keep a limited configuration in the configuration file and rely on OpenShift Origin and Docker to install their needed rules.
The iptables.service configuration is loaded from:
/etc/sysconfig/iptables
To make permanent rules changes, edit the changes into this file. Do not include Docker or OpenShift Origin rules.
After iptables.service is started or restarted on a node, the Docker service and atomic-openshift-node.service must be restarted to reconstruct the needed iptables configuration.
|
Restarting the Docker service will cause all containers running on the node to be stopped and restarted. |
# systemctl restart iptables.service # systemctl restart docker # systemctl restart atomic-openshift-node.service