state match incompatibilty across versions

state match incompatibilty across versions

[Laurence J. Lane]

Debian Bug#718810 reports a problem with the state match across
iptables versions. The following rules were created with the same
states using 1.4.14. The state information on the state match do now
show with 1.4.19.1's iptables-save or " iptables -L". The conntrack
match's ctstate works as expected with the upgrade.

  # Generated by iptables-save v1.4.19.1 on Tue Aug  6 18:15:36 2013
  *filter
  :INPUT ACCEPT [270:16468]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [197:23360]
  -A INPUT -m state
  -A INPUT -m conntrack --ctstate INVALID,NEW,RELATED,ESTABLISHED
  COMMIT
  # Completed on Tue Aug  6 18:15:36 2013

  # Generated by iptables-save v1.4.14 on Tue Aug  6 18:16:43 2013
  *filter
  :INPUT ACCEPT [535:33200]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [384:42988]
  -A INPUT -m state --state INVALID,NEW,RELATED,ESTABLISHED
  -A INPUT -m conntrack --ctstate INVALID,NEW,RELATED,ESTABLISHED
  COMMIT
  # Completed on Tue Aug  6 18:16:43 2013

It seems to work fine the other way around, with 1.4.19.1 creating the rules.

Re: state match incompatibilty across versions

[Laurence J. Lane]

It appears to be in the change of state to an alias in 1.4.16.

Re: state match incompatibilty across versions

[Phil Oester]

On Tue, Aug 06, 2013 at 02:23:44PM -0400, Laurence J. Lane wrote:
> Debian Bug#718810 reports a problem with the state match across
> iptables versions. The following rules were created with the same
> states using 1.4.14. The state information on the state match do now
> show with 1.4.19.1's iptables-save or " iptables -L". The conntrack
> match's ctstate works as expected with the upgrade.

Can't seem to reproduce the problem here:

# /usr/local/ipt1414/sbin/iptables -V
iptables v1.4.14
# /usr/local/ipt1414/sbin/iptables -A foo -m state --state RELATED,ESTABLISHED -j ACCEPT
# /usr/local/ipt1414/sbin/iptables -nvL foo
Chain foo (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED


# /usr/local/iptables/sbin/iptables -V
iptables v1.4.19.1
# /usr/local/iptables/sbin/iptables -nvL foo
Chain foo (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED


Perhaps kernel revision sensitive?

Phil

Re: state match incompatibilty across versions

[Laurence J. Lane]

I think I failed to explain the problem clearly. I'll try again.

If I use iptables 1.1.14 or 1.4.15 to create a match state rule,
iptables 1.4.16+ binaries do not display the state information that is
in the kernel.

https://gist.github.com/anonymous/6180482

The gist shows a way reproduce the problem. I can post that directly
on list if it's appropriate and necessary. The iptables-save output
(from iptables 1.4.16) on line 52 is missing "--state
INVALID,NEW,RELATED,ESTABLISHED,UNTRACKED". If I roll back to 1.4.15,
the info is still there.

There I used a fresh archlinux VM and compiled iptables 1.4.15 and
1.4.16 in the VM. I have the same results with Debian on VMs and HW,
with stock kernel.org and Debian kernels, and using both i686 and
amd64 and using iptables versions from 1.4.14 to 1.4.20. I'm fairly
certain it's the change between iptables 1.4.15 and 1.4.16, not any
kernel or distro influence, that is causing the problem.

Re: state match incompatibilty across versions

[Phil Oester]

On Wed, Aug 07, 2013 at 09:28:49PM -0400, Laurence J. Lane wrote:
> I think I failed to explain the problem clearly. I'll try again.
> 
> If I use iptables 1.1.14 or 1.4.15 to create a match state rule,
> iptables 1.4.16+ binaries do not display the state information that is
> in the kernel.

Issue understood.  I posted a patch in the past few hours.  Can you verify
this fixes the issue for you?

Phil

Re: state match incompatibilty across versions

[Laurence J. Lane]

On Thu, Aug 8, 2013 at 12:32 AM, Phil Oester <kernel@linuxace.com> wrote:

> Issue understood.  I posted a patch in the past few hours.  Can you verify
> this fixes the issue for you?

It does. Thank you!