Skip Menu |

This queue is for tickets about the IPTables-Rule CPAN distribution.

Report information
The Basics
Id: 115973
Status: resolved
Priority: 0/
Queue: IPTables-Rule
People
Owner: fukawi2 [...] gmail.com
Requestors: rest [...] xicon.de
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Jul 08 06:27:12 2016 rest [...] xicon.de - Ticket created
Subject: Order of generated iptables rule is not valid if using "-C" (check) option - chain must be set before table
Date: Fri, 8 Jul 2016 12:26:57 +0200
To: bug-IPTables-Rule [...] rt.cpan.org
From: XiconRest <rest [...] xicon.de>
Dear Phillip, I don't know if this is a bad behaviour of iptables or just a bug in it, but I couldn't find any documentation that states this rule: If you are using the -C option on a chain, for checking, if the rule is applied into iptables, and you set the table "-t" like nat or filter (e.x.), than the chain definition (e.x. -C POSTROUTING) has to be in front of the table definition (e.x. -t nat). throws error: /sbin/iptables -t nat -C POSTROUTING -o eth0 -j MASQUERADE works fine: /sbin/iptables -C POSTROUTING -t nat -o eth0 -j MASQUERADE Expected output is either none, if the rule is applied, or "Bad rule (does a matching rule exist in that chain?)". But if you select the NAT table with "-t nat", the output seems also to be not completely right "No chain/target/match by that name.", even when the chain is there - but this not the problem of this request/ticket. So summing up: "-[ADIRLSFZNXPE]" has to be in front of "-t [filter|nat|mangle|raw|security]". Patch/diff attached. Best regards xiconfjs

Message body is not shown because sender requested not to inline it.

  Sun Jul 10 23:27:30 2016 fukawi2 [...] gmail.com - Correspondence added
I suspect this is a bug in your iptables. What is your environment? I am unable to reproduce on Arch Linux with kernel 4.5.1-1 and iptables 1.6.0: [root ~]# iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 23 packets, 3338 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 1 packets, 78 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination [root ~]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE [root ~]# iptables -t nat -C POSTROUTING -o eth0 -j MASQUERADE [root ~]# echo $? 0 [root ~]# iptables -C POSTROUTING -t nat -o eth0 -j MASQUERADE [root ~]# echo $? 0 [root ~]#
  Sun Jul 10 23:27:31 2016 The RT System itself - Status changed from 'new' to 'open'
  Sun Jul 10 23:27:41 2016 fukawi2 [...] gmail.com - Taken
  Mon Apr 17 23:53:26 2017 fukawi2 [...] gmail.com - Status changed from 'open' to 'resolved'