Bug 1477638
| Summary: | Using iptables.service and ip6tables.service may lead to no firewall configuration after booting | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Robert Scheck <redhat-bugzilla> |
| Component: | iptables | Assignee: | Thomas Woerner <twoerner> |
| Status: | CLOSED DUPLICATE | QA Contact: | qe-baseos-daemons |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | ajohn, ajz, anderson.gomes, contact, fabiano.martins, ffutigam, gkadam, iptables-maint-list, perobins, redhat-bugzilla, richard.cunningham, robert.scheck, twoerner, vjadhav |
| Target Milestone: | rc | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-09 12:26:35 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: | |||
|
Description
Robert Scheck
2017-08-02 14:06:55 UTC
Cross-filed ticket 01903155 on the Red Hat customer portal. Akhil, I personally dislike the workaround of manually starting the failed unit at Red Hat Knowledge Base (Solution) 3138851, wouldn't it be better to suggest my workaround? It is IMHO at least reboot-safe. The underlying issue seems to be the backporting of "--wait" to iptables-restore in https://bugzilla.redhat.com/show_bug.cgi?id=1438597 (released in https://access.redhat.com/errata/RHEA-2017:2280) now have iptables-restore looking for an exclusive lock file and default behavior of immediately exiting if it can't obtain it. There were no accompanying updates to the scripts in "iptables-services" to use the new "--wait" flag. (iptables-services-1.4.21-17.el7.x86_64 and iptables-services-1.4.21-18.el7.x86_64 have identical file contents). This issue was discovered in our environment on a new set of system builds that were patched up to 7.4 and rebooted. I planned to deploy the same local drop-in to ip6tables.service as a workaround until this is addressed and ensure our systems retain their full firewall configurations upon reboot. Hi Robert Scheck, I have updated the Red Hat Knowledge Base solution 3138851. Thanks a lot. I just logged into Bugzilla in order to report this issue. In the production environment I manage, system firewall rules are pulled from a Spacewalk server and saved into /etc/sysconfig/iptables and /etc/sysconfig/ip6tables . Depending on processor scheduling and hardware conditions, either iptables or ip6tables may fail to start on boot time, leaving part of the network stack opened to internal attacks. The larger the firewall rules are, the bigger the probability of a startup problem is. For example, ip6tables always fail to start on boot after running this command line: # ( echo -e '*filter\n:INPUT ACCEPT [0:0]\n:FORWARD ACCEPT [0:0]\n:OUTPUT ACCEPT [0:0]' ; for a in `seq 1 3000000`; do echo '-A OUTPUT -j RETURN' ; done; echo COMMIT ) | tee /etc/sysconfig/iptables > /etc/sysconfig/ip6tables ------------------ Manually checking unit status is not feasible here, because of the huge number of RHEL / CentOS / Oracle Linux installations. Logging into each server in order to check service status would be time-consuming. I agree to the dependency ordering workaround: # systemctl cat iptables.service (...) # /etc/systemd/system/iptables.service.d/ip6tables-conflict-solving.conf [Unit] Before=ip6tables.service *** This bug has been marked as a duplicate of bug 1477413 *** Not sure why this is "needinfo" for me (without any question that I can see). I still can not see any question (I am not a Red Hat employee)... |