# iptables error: The state match is obsolete. Use conntrack i

## Skippy204

After upgrading to iptables 1.4.16.2 I started getting this error.

```

 root # rc-config start iptables

Starting init script

 * Loading iptables state and starting firewall ...

WARNING: The state match is obsolete. Use conntrack instead.

iptables-restore v1.4.16.2: state: option "--state" must be specified

Error occurred at line: 24

Try `iptables-restore -h' or 'iptables-restore --help' for more informati [ !! ]

 * ERROR: iptables failed to start

```

I've done some googleing and all I've come up with is this - which seems to indicate this is a bug.  But I hardly know enough about iptables to know if it's bug or my mistake.

https://bugs.launchpad.net/ufw/+bug/1065297

Can anyone help me out?  Thanks.

Skippy

----------

## PaulBredbury

Instead of e.g.:

```
-m state --state RELATED
```

Use:

```
-m conntrack --ctstate RELATED
```

----------

## Skippy204

Thanks - I'm still having trouble applying this.  Please tell me what I'm doing wrong, 'cause I'm flying mostly blind here.   :Smile: 

In /var/lib/iptables/rules.working I'm changing

```

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

```

to 

```
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
```

and then

```

 root # rc-config start iptables

Starting init script

 * Caching service dependencies ...                                                                                        [ ok ]

 * Loading iptables state and starting firewall ...

WARNING: The state match is obsolete. Use conntrack instead.

iptables-restore v1.4.16.3: state: option "--state" must be specified

Error occurred at line: 24

Try `iptables-restore -h' or 'iptables-restore --help' for more information.                                               [ !! ]

 * ERROR: iptables failed to start

```

I'm still wrong about something . . .

----------

## Hu

Unless you have changed your /etc/conf.d/iptables file, that is the wrong filename to edit.  The default here is /var/lib/iptables/rules-save.

Did you change all uses of state?  Does your kernel have conntrack built?  Please post the entire modified rules file.

----------

## Skippy204

Hi, thanks for responding.

```

 root # cat /var/lib/iptables/rules-save 

# Generated by iptables-save v1.4.16.2 on Thu Oct 11 17:39:04 2012

*nat

:PREROUTING ACCEPT [115774:17577973]

:INPUT ACCEPT [1:28]

:OUTPUT ACCEPT [1429994:98812650]

:POSTROUTING ACCEPT [1429994:98812650]

COMMIT

# Completed on Thu Oct 11 17:39:04 2012

# Generated by iptables-save v1.4.16.2 on Thu Oct 11 17:39:04 2012

*mangle

:PREROUTING ACCEPT [228134025:307554773508]

:INPUT ACCEPT [228133750:307554742848]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [135710476:20656815767]

:POSTROUTING ACCEPT [135931198:20687428864]

COMMIT

# Completed on Thu Oct 11 17:39:04 2012

# Generated by iptables-save v1.4.16.2 on Thu Oct 11 17:39:04 2012

*filter

:INPUT DROP [347589:48808777]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [135631043:20649408445]

[193304:10478848] -A INPUT -i lo -j ACCEPT

[227495532:307389083399] -A INPUT -m state -j ACCEPT

COMMIT

# Completed on Thu Oct 11 17:39:04 2012

```

```

 root # cat /var/lib/iptables/rules.working

# Generated by iptables-save v1.4.12.1 on Fri Oct 28 14:03:14 2011

*nat

:PREROUTING ACCEPT [2:604]

:INPUT ACCEPT [1:28]

:OUTPUT ACCEPT [4507:294969]

:POSTROUTING ACCEPT [4507:294969]

COMMIT

# Completed on Fri Oct 28 14:03:14 2011

# Generated by iptables-save v1.4.12.1 on Fri Oct 28 14:03:14 2011

*mangle

:PREROUTING ACCEPT [102988:113880041]

:INPUT ACCEPT [102987:113879465]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [80124:7497553]

:POSTROUTING ACCEPT [80524:7553153]

COMMIT

# Completed on Fri Oct 28 14:03:14 2011

# Generated by iptables-save v1.4.12.1 on Fri Oct 28 14:03:14 2011

*filter

:INPUT DROP [3:747]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [691:90231]

[0:0] -A INPUT -i lo -j ACCEPT

[5659:7506894] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

COMMIT

# Completed on Fri Oct 28 14:03:14 2011

```

I have not modified /etc/conf.d/iptables.  

Regarding the kernel, if NETFILTER_XT_MATCH_CONNTRACK is the correct module to build, then yes.

----------

## Hu

According to your output, you modified a file that is not used at all.  You must modify the file which will be read by the init script.  This file defaults to rules-save, which you have not modified.

----------

## toralf

 *PaulBredbury wrote:*   

> Instead of e.g.:
> 
> ```
> -m state --state RELATED
> ```
> ...

 Hhm, do I have to adapt that change to all of these lines 

```
tfoerste@n22 ~ $ sudo grep state /etc/kmyfirewall/kmyfirewall.sh

        $MOD ipt_state 

        $IPT -t filter -A INPUT -p tcp --destination-port 22 --match state --state NEW         --match recent --name FAILED_SSH_LOGIN --set

        $IPT -t filter -A INPUT -p tcp --destination-port 22 --match state --state ESTABLISHED --match recent --name FAILED_SSH_LOGIN --update --seconds 60 --hitcount 2 -j REJECT --reject-with tcp-reset

        $IPT -t filter -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

        $IPT -t filter -A INPUT --match state --state NEW --match recent --name MAX_CONN_PER_IP --set

        $IPT -t filter -A INPUT --match state --state NEW --match recent --name MAX_CONN_PER_IP --update --seconds 60 --hitcount 11 -j DROP

        $IPT -t filter -A OUTPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

```

if >=iptables-1.4.16.x becomes stable ?

----------

## Skippy204

Well that works.  However it works by totally cutting off all my internet connection.

Definitely secure.   :Smile:   No so useful.

```
 root # cat rules-save

# Generated by iptables-save v1.4.16.3 on Sat Oct 27 15:05:40 2012

*nat

:PREROUTING ACCEPT [115774:17577973]

:INPUT ACCEPT [1:28]

:OUTPUT ACCEPT [1430136:98822605]

:POSTROUTING ACCEPT [1430136:98822605]

COMMIT

# Completed on Sat Oct 27 15:05:40 2012

# Generated by iptables-save v1.4.16.3 on Sat Oct 27 15:05:40 2012

*mangle

:PREROUTING ACCEPT [228134830:307554866638]

:INPUT ACCEPT [228134555:307554835978]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [135710876:20656863052]

:POSTROUTING ACCEPT [135931612:20687478095]

COMMIT

# Completed on Sat Oct 27 15:05:40 2012

# Generated by iptables-save v1.4.16.3 on Sat Oct 27 15:05:40 2012

*filter

:INPUT DROP [348394:48901907]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [135631443:20649455730]

[193304:10478848] -A INPUT -i lo -j ACCEPT

[227495532:307389083399] -A INPUT -m conntrack --ctstate RELATED -j ACCEPT

COMMIT

```

----------

## Ant P.

Well since you changed it to not allow traffic from established connections, I'm not sure what else you expected to happen...

----------

## PaulBredbury

 *Skippy204 wrote:*   

> -A INPUT -m conntrack --ctstate RELATED -j ACCEPT

 

Your previous rule was:

```
-A INPUT -m state -j ACCEPT
```

Since it's not actually checking a state, that "-m state" was useless. And the change you've made is totally wrong.

Change it to:

```
-A INPUT -j ACCEPT
```

----------

## Hu

 *toralf wrote:*   

> 
> 
> ```
> tfoerste@n22 ~ $ sudo grep state /etc/kmyfirewall/kmyfirewall.sh
> 
> ...

 Yes, but if that script is generated by some other tool, updating the tool should handle that for you.

OP: PaulBredbury is correct.  He also brings up an interesting problem.  You have been using a completely open (non-filtering) configuration for some time, since your rules-save specified an open configuration.  The rules.working file, which was not used and therefore not working, specified a filtering configuration.  The change he suggests is correct to maintain your current behavior of accepting all traffic.

----------

## toralf

 *Hu wrote:*   

> Yes, but if that script is generated by some other tool, updating the tool should handle that for you.

 Sure - but I used KMyFirewall eons before just for the initial generation and after that I'm using vim to update it  :Smile: 

----------

## Skippy204

Howdy, the post from PaulBredbury solved it.  Iptablels now starts up.

Regarding the fact that I have no actual filtering rules - thank you for pointing that out.  My iptalbes knowledge seriously lacks.  Can anyone suggest a good GUI that will help me configure this or a manual that is written for idiots?

Thanks very much for the help.

----------

## PaulBredbury

The Arch wiki seems like a good intro.

----------

## Element Dave

 *Skippy204 wrote:*   

> Howdy, the post from PaulBredbury solved it.  Iptablels now starts up.
> 
> Regarding the fact that I have no actual filtering rules - thank you for pointing that out.  My iptalbes knowledge seriously lacks.  Can anyone suggest a good GUI that will help me configure this or a manual that is written for idiots?
> 
> Thanks very much for the help.

 

The Arch Linux wiki has a page that you might find helpful.  From what it looks like you're trying to accomplish, you can probably skip everything after section 2.4 ("The INPUT Chain").

https://wiki.archlinux.org/index.php/Simple_Stateful_Firewall

----------

## khayyam

 *Skippy204 wrote:*   

> Can anyone suggest a good GUI that will help me configure this or a manual that is written for idiots?

 

Skippy204 ... there is a direct corrolation between tools that shield the user from understanding the internals of a given system, and users not understanding the internals of a given system. Skill and familiarity are aquired by "use", and there is no shortcut that doesn't infact circumvent "use", and so the development of skill.

By far the best tutorial on iptables is Oskar Andreasson's. It doesn't make the assumption of prior knowledege (and so is accessable) but is detailed and broad in scope. That said, the subject is not one that can be grasped in a new-york minute, but as the saying goes, its better to be at the bottom of a ladder you want to climb than half way up one you don't.

best ... khay

----------

## Skippy204

Thank you all for your suggestions.

I will check them out.

----------

## toralf

Hhm, the proposed change doesn't work here :

```
n22 /etc/kmyfirewall # diff kmyfirewall.sh kmyfirewall.sh_old

42,43c42,43                                                                                                                                                           

<       $IPT -t filter -A INPUT -p tcp --destination-port 22 --match conntrack --ctstate NEW         --match recent --name FAILED_SSH_LOGIN --set                     

<       $IPT -t filter -A INPUT -p tcp --destination-port 22 --match conntrack --ctstate ESTABLISHED --match recent --name FAILED_SSH_LOGIN --update --seconds 60 --hitcount 2 -j REJECT --reject-with tcp-reset                                                                                                                            

---                                                                                                                                                                   

>       $IPT -t filter -A INPUT -p tcp --destination-port 22 --match state --state NEW         --match recent --name FAILED_SSH_LOGIN --set                           

>       $IPT -t filter -A INPUT -p tcp --destination-port 22 --match state --state ESTABLISHED --match recent --name FAILED_SSH_LOGIN --update --seconds 60 --hitcount 2 -j REJECT --reject-with tcp-reset                                                                                                                                  

47c47                                                                                                                                                                 

<       $IPT -t filter -A INPUT --match conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT                                                                             

---                                                                                                                                                                   

>       $IPT -t filter -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT                                                                                   

51,52c51,52                                                                                                                                                           

<       $IPT -t filter -A INPUT --match conntrack --ctstate NEW --match recent --name MAX_CONN_PER_IP --set                                                           

<       $IPT -t filter -A INPUT --match conntrack --ctstate NEW --match recent --name MAX_CONN_PER_IP --update --seconds 60 --hitcount 11 -j DROP                     

---                                                                                                                                                                   

>       $IPT -t filter -A INPUT --match state --state NEW --match recent --name MAX_CONN_PER_IP --set                                                                 

>       $IPT -t filter -A INPUT --match state --state NEW --match recent --name MAX_CONN_PER_IP --update --seconds 60 --hitcount 11 -j DROP                           

138c138

<       $IPT -t filter -A OUTPUT --match conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

---

>       $IPT -t filter -A OUTPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

```

The old works :

```

n22 /etc/kmyfirewall # ./kmyfirewall.sh_old restart

```

but the new not

```

n22 /etc/kmyfirewall # ./kmyfirewall.sh restart

iptables: No chain/target/match by that name.

iptables: No chain/target/match by that name.

iptables: No chain/target/match by that name.

iptables: No chain/target/match by that name.

iptables: No chain/target/match by that name.

iptables: No chain/target/match by that name.

```

----------

## Hu

Do you have the appropriate Netfilter features configured in your kernel?  It is possible to build a kernel with state and without conntrack.

----------

## toralf

 *Hu wrote:*   

> Do you have the appropriate Netfilter features configured in your kernel?  It is possible to build a kernel with state and without conntrack.

 ah maybe, here I do have a /proc/config.gz : http://bpaste.net/show/59865/ /me now wonders which have to be added too .

----------

## aCOSwt

@toralf : What about this one :  *toralf's config wrote:*   

> # CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set

 

I'd definitely set it.

----------

## toralf

 *aCOSwt wrote:*   

> @toralf : What about this one :  *toralf's config wrote:*   # CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set 
> 
> I'd definitely set it.

 ofc - thx

So CONFIG_NETFILTER_XT_MATCH_STATE is gone in favor of CONFIG_NETFILTER_XT_MATCH_CONNTRACK.

----------

## Yminus

I have never touched any iptables configuration assuming it comes with reasonable defaults. And iptables has been installed as dependency of those:

```
 * These packages depend on iptables:

app-emulation/libvirt-0.10.2-r3 (virt-network ? >=net-firewall/iptables-1.4.10)

net-misc/connman-1.0-r1 (>=net-firewall/iptables-1.4.8)

sys-apps/iproute2-3.3.0 (iptables ? >=net-firewall/iptables-1.4.5)
```

But now I learn that an upgrade broke this configuration. Shouldn't the upgrade ensure that the configuration is sane if I never touched it myself?

----------

## aCOSwt

 *Yminus wrote:*   

> I have never touched any iptables configuration assuming it comes with reasonable defaults... And iptables has been installed as dependency

 

So this means that you did not write any rules / did not add the program to rc... correct ?

So iptables are neither configured nor running on your system.

For running as a firewall for example I mean.

So the upgrade did not actually break anything in your system.

BTW, just fearing something. I might completely misunderstand what you mean but... do you mean you believed your system protected because supposed to be running some automagic-default-safe firewall ?   :Shocked: 

----------

## Yminus

 *aCOSwt wrote:*   

> So this means that you did not write any rules / did not add the program to rc... correct ?

 

I did not write any rules. I think that libvirt is shipped with some rules needed for virtual networking. iptables is in runlevel default, but I can't remember adding it (I use this system for  more than 4 years now)

 *aCOSwt wrote:*   

> So iptables are neither configured nor running on your system.
> 
> Well, 
> 
> For running as a firewall for example I mean.

 

I never set it up to be running as a firewall. I think libvirt needs it for bridging.

 *aCOSwt wrote:*   

> So the upgrade did not actually break anything in your system.

 

iptbales fails to start. Maybe I just remove it from all runlevels and see if this breaks something.

 *aCOSwt wrote:*   

> BTW, just fearing something. I might completely misunderstand what you mean but... do you mean you believed your system protected because supposed to be running some automagic-default-safe firewall ?  

 

I always thought a Linux system does not need a firewall if there are no services listening for external connections? My apache only accepts connections from localhost (I need it for personal dokuwiki), my sshd is only accepting certain ssh-keys and no passwords,... . Do I need a firewall on a Linux laptop?

----------

## Hu

If you connect to an untrusted network, I recommend running a packet filter.  You may not need one, but security is about defense in depth.  If the attacker cannot contact your system, then there is no possibility that a bug or mistaken configuration in some server could allow the attacker to advance, because he will never talk to it.

----------

## libertytrek

 *Hu wrote:*   

> Unless you have changed your /etc/conf.d/iptables file, that is the wrong filename to edit.  The default here is /var/lib/iptables/rules-save.

 

Ok, I encountered this, and am having a weird problem...

/etc/conf.d/iptables definitely is configured to save rules-save to /var/lib/iptables, and the date/time of the file changed when I ran iptables-save after making changes to the running config, but it still contained references to --state (content didn't appear to update).

So, I mv'd the old file and reran iptables-save - no file was created. Touched rules-save, reran iptables-save, file was not updated.

The problem I'm having right now is when I try to restart iptables, it gives me:

Well, now I'm really confused... apparently after mving  the old file, it now restarts without an error *and* contains the correct modifications...

So, how can I find out where iptables is *really* storing rules-save?

Oh - this is on a Linode hosted VM slice...

----------

## Hu

Do you mean the command iptables, the command iptables-save, or the Gentoo initscript iptables?  The first produces output unsuitable for use here.  The second writes to stdout, so is not saved unless its caller redirects stdout.  The third writes to the location specified in /etc/conf.d/iptables.

----------

## libertytrek

 *Hu wrote:*   

> Do you mean the command iptables, the command iptables-save, or the Gentoo initscript iptables?  The first produces output unsuitable for use here.  The second writes to stdout, so is not saved unless its caller redirects stdout.  The third writes to the location specified in /etc/conf.d/iptables.

 

Ok, I was talking about the command iptables-save. I thought that would save the rules to the rules-current file specified in /etc/conf.d/iptables.

I'm confused as to what good sending output of iptables-save to stdout accomplishes? If it is just doing that then it isn't 'saving' it at all, it is just outputting it to the screen (unless of course it is redirected).

Anyway, you're right, restarting iptables again using the gentoo init script updated the file as it should.

Thanks!

----------

## Hu

It saves an atomic snapshot of the rules to stdout, which you can then post-process in any way you want, whether that is adding/deleting/modifying rules, compressing the rule list, writing it to a file, or streaming it over a network connection.

----------

