This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 865898 - iptables: No chain/target/match by that name
iptables: No chain/target/match by that name
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-12 14:38 EDT by Lance Lassetter
Modified: 2013-02-07 02:24 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-07 02:24:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backtrace (1.25 KB, text/plain)
2012-10-17 07:11 EDT, Jiri Popelka
no flags Details
snippet from /var/log/messages (12.64 KB, text/plain)
2012-10-25 05:25 EDT, Jiri Popelka
no flags Details

  None (edit)
Description Lance Lassetter 2012-10-12 14:38:27 EDT
Description of problem:  firewall-cmd cannot delete rules (nat?)


Version-Release number of selected component (if applicable):

firewalld-0.2.7-1.fc18.noarch

How reproducible:

constant

Steps to Reproduce:

1.# firewall-cmd --add-forward-port=port=80:proto=tcp:toport=8080

2.# firewall-cmd --list-forward-ports
port=80:proto=tcp:toport=8080:toaddr=

3.# firewall-cmd --zone=public --remove-forward-port=port=80:proto=tcp:toport=8080
Error: COMMAND_FAILED: '/sbin/iptables -D PRE_ZONE_public_allow -t mangle -p tcp --dport 80 -j MARK --set-mark 0x64' failed: iptables: No chain/target/match by that name.

4.# firewall-cmd --list-ports
8080/tcp
  
Actual results:  Port open in public zone leaving hole in firewall.


Expected results:  Delete added open port.


Additional info:   Unable to delete the port forward rule in the GUI as well.
Comment 1 Jiri Popelka 2012-10-15 07:21:50 EDT
I'm not able to reproduce it here.
What's the output of 'rpm -q iptables' and 'uname -a' ?
Comment 2 Jiri Popelka 2012-10-17 07:11:08 EDT
Created attachment 628689 [details]
backtrace

I actually see something similar with kernel-3.6.1-1.fc17
kernel-3.5.6-1.fc17 is ok.
Comment 3 Jiri Popelka 2012-10-25 05:25:58 EDT
Created attachment 633236 [details]
snippet from /var/log/messages

Still occurs from time to time even with kernel 3.6.2-4.fc17.x86_64
This time I'm seeing it it after firewalld service restart.

Now
'iptables -t filter -I INPUT 1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT'
returns 'iptables: No chain/target/match by that name.'
and I can see the attached lines in /var/log/messages
Comment 4 Jiri Popelka 2012-10-25 05:27:34 EDT
# iptables-save
*filter
:INPUT ACCEPT [4781:1563336]
:FORWARD ACCEPT [114:6840]
:OUTPUT ACCEPT [3916:988198]
:INPUT_ZONES - [0:0]
:INPUT_direct - [0:0]
COMMIT
Comment 5 Thomas Woerner 2012-10-25 05:59:30 EDT
Reassigning to kernel. See attachment in comment 3.
Comment 6 Josh Boyer 2012-11-13 09:56:34 EST
Neil, any ideas here?
Comment 7 Jiri Popelka 2013-02-07 02:24:09 EST
I no longer see this on kernel-3.7.5-201.fc18.x86_64

Note You need to log in before you can comment on or make changes to this bug.