| 1 |
On 12/27/12 06:28, Graham Murray wrote: |
| 2 |
> Michael Orlitzky <michael@××××××××.com> writes: |
| 3 |
> |
| 4 |
>> The 'conntrack' module is supposed to be a superset of 'state', so most |
| 5 |
>> things should be compatible. You really have two warnings there; the |
| 6 |
>> first is for the state -> conntrack switch, and the second is because |
| 7 |
>> you're missing the --state flag in your rules. |
| 8 |
>> |
| 9 |
>> In your example, you turn on the state matching, |
| 10 |
>> |
| 11 |
>> iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED |
| 12 |
>> |
| 13 |
>> but you don't specify *which* state(s) you want to match. It wants you |
| 14 |
>> to specify --state SOMETHING. I'd guess that it used to interpret "no |
| 15 |
>> state" as "any state." |
| 16 |
> |
| 17 |
> The problem is not really the OP's fault. The problem is that if you |
| 18 |
> have tables with the form "-m state --state XXX" at the point you |
| 19 |
> upgrade, iptables-save (quite possibly called automatically by |
| 20 |
> /etc/init.d/iptables stop) will save it as "-m state --state" - ie |
| 21 |
> 'forgetting' which state(s) the rule applies to. |
| 22 |
> |
| 23 |
|
| 24 |
Youch, thanks, I'll keep an eye out for this when iptables wants a bump. |
| 25 |
I already keep the rules in a script, but it sounds like this will |
| 26 |
clobber the running rules after e.g. a reboot. |
| 27 |
|
| 28 |
My first -m state rule is, |
| 29 |
|
| 30 |
iptables -A INPUT -p ALL -m state \ |
| 31 |
--state ESTABLISHED,RELATED -j ACCEPT |
| 32 |
|
| 33 |
And if what you say is true, I'd be in deep shit if it reset to, |
| 34 |
|
| 35 |
iptables -A INPUT -p ALL -m state -j ACCEPT |
| 36 |
|
| 37 |
without a warning. |
| 38 |
|
| 39 |
|
| 40 |
> |
| 41 |
> I think that this is a serious enough change in behaviour that an elog |
| 42 |
> warning should have been issued. |
| 43 |
|
| 44 |
It's not stable yet, right? File a bug (and CC me, please). |
Archives