Bug 1136801
Summary: | a rule added into IN_<zone>_allow chain with 'permanent direct' interface doesn't exist after reload | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Mario Gamboa <mgamboap> |
Component: | firewalld | Assignee: | Thomas Woerner <twoerner> |
Status: | CLOSED ERRATA | QA Contact: | Tomas Dolezal <todoleza> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | joallen, jpopelka, mgamboap, pvrabec, todoleza |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | firewalld-0.4.2-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-11-03 21:00:06 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: |
Comment 3
Jiri Popelka
2014-09-03 12:19:39 UTC
Hi jiri This is the problem actually when the customer try this on the "drop zone" is not working as expected the same happen if he try to open the service of ssh # firewall-cmd --permanent --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # firewall-cmd --reload only work in runtime for the drop zone and we can't make permanent the rule for this zone, if the customer run like this the command works fine but is not permanent for the drop zone # firewall-cmd --direct --passthrough ipv4 -A IN_drop_allow -p icmp --icmp-type=8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # firewall-cmd --reload In the public zone works ok Just to be clear this is happen when the customer change to the zone drop in the zone public is works as expected. Ok, I see it now. But I can see the same even with 'public' zone. The reason is that when you reload firewalld, firewalld adds the direct rules *before* the chains for zones are created. The chains for zones are first created in a moment when a interface is associated with a zone. So it fails because IN_drop_allow (or even IN_public_allow in my case) does not yet exist in that moment. Besides fixing the issue with being able to add rules to chains of zones, there is also another idea to use icmp-block more like an icmp-filter, that is rejecting for zones using the default or ACCEPT target and that is accepting icmp types for zones using the reject or drop targets. Is there interest in a change like this? Fixed upstream in https://github.com/t-woerner/firewalld/commit/a3f82d2cd4530e409a2a7dc778afa0f9b1becc5c and https://github.com/t-woerner/firewalld/commit/1d9158dc81c6c78f34f2f368b6db9096504f366d This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Thomas, Mario's account has been closed. Personally I like function behind the idea but this implementation might be very confusing. I mean that function of this field would invisibly depend on default-target which is not shown even in --zone-info=<zone>. Instead, I suggest 'icmp-filter' (backward compatibile with icmp-block) and added notation like '!' before the list. What do you think? idea from comments 11 and 15 now has a separate bug 1325335 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/RHSA-2016-2597.html |