What should we do with packets marked as INVALID?

What should we do with packets marked as INVALID?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2714 bytes --]

Hello,

One of the most important feature provided by the netfilter subsystem is 
stateful connection tracking - the ability to decide that a packet is 
valid (or not) using not only data from a packet itself but also from a 
history of a flaw.

So, the question is: what should we do with packets marked as INVALID?

For a very long time I have thought that something like this should work 
best:

-A INVALID -m limit --limit 10/s -j LOG --log-prefix "INVALID: " --log-level 7 --log-tcp-sequence --log-tcp-options --log-ip-options
-A INVALID -p tcp -m limit --limit 4/s -j REJECT --reject-with tcp-reset
-A INVALID -p udp -m limit --limit 4/s -j REJECT
-A INVALID -j DROP

-A FORWARD -m conntrack --ctstate INVALID -j INVALID

This whole REJECT idea is to kill out of sync sessions - IMO it is better 
to send RST/port-unreachable ASAP, so hosts know they should reconnect 
immediatley (if that's appropriately) without needing to wait (sometines 
very long) for a session to timeout. Think on stalled NFS mounts, etc.

Then I realized that the same INVALID state handles packets from a valid 
flow (proto/src/dst/sport/dport match conntrack table) but with something 
the netfilter decides that is wrong (ex. out of window segments, 
short/truncated/malformed packets, bad checksum, etc). Rejecting such 
packets kills valid connections, and it is quite common to get a lot of, 
for example, "ip_ct_tcp: ACK is under the lower bound (possible overly 
delayed ACK)" on bigger firewalls:

root@fw2:~# grep -c "ip_ct_tcp: ACK is under the lower bound (possible overly delayed ACK)" /var/log/syslog
905

So OK, REJECT is wrong (possibly kills valid connections), DROP (makes 
invalid connections hang "forever") is also wrong, so maybe we should 
forward such packets and allow dst hosts to handle it (ignore/reset/etc). 
Bzzzz... no, wait, it is also wrong as we lose one of the most important 
netfilter feature.

So, I have two propositions:
  - Add another state (ex. UNCLEAN) for packet that matches 
proto/src/dst/sport/dport, but netfilter consider that it is wrong. There 
will be two states: INVALID (for packet with no known conntrack entry) and 
UNCLEAN and that gives us possibility to distinguish between these two 
states:

-A FORWARD -m conntrack --ctstate UNCLEAN -j DROP
-A FORWARD -m conntrack --ctstate INVALID -j INVALID

  - Drop such packets implicitly (something like s/-NF_ACCEPT/-NF_DROP/ in 
ip_conntrack_proto_*.c) and safely REJECT packets with INVALID state, like 
in my first example. This time INVALID will means that there is no 
appropriate conntrack entry, nothing else.

Comments?

Best regardas,


 			Krzysztof Olędzki

Re: What should we do with packets marked as INVALID?

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2551 bytes --]



>Date: Mon, 25 Dec 2006 02:33:59 +0100 (CET)
>From: Krzysztof Oledzki <ole@ans.pl>
>To: Netfilter Developer Mailing List <netfilter-devel@lists.netfilter.org>
>Subject: What should we do with packets marked as INVALID?
>
> Hello,
>
> One of the most important feature provided by the netfilter
> subsystem is stateful connection tracking - the ability to decide
> that a packet is valid (or not) using not only data from a packet
> itself but also from a history of a flaw.
>
> So, the question is: what should we do with packets marked as
> INVALID?


http://jengelh.hopto.org/p/chaostables/fw.html
section 3. YMMV.

>
> For a very long time I have thought that something like this should
> work best:
>
> -A INVALID -m limit --limit 10/s -j LOG --log-prefix "INVALID: " --log-level 7
> --log-tcp-sequence --log-tcp-options --log-ip-options
> -A INVALID -p tcp -m limit --limit 4/s -j REJECT --reject-with tcp-reset
> -A INVALID -p udp -m limit --limit 4/s -j REJECT
> -A INVALID -j DROP
>
> -A FORWARD -m conntrack --ctstate INVALID -j INVALID
>
> This whole REJECT idea is to kill out of sync sessions - IMO it is
> better to send RST/port-unreachable ASAP, so hosts know they should
> reconnect immediatley (if that's appropriately) without needing to
> wait (sometines very long) for a session to timeout. Think on
> stalled NFS mounts, etc.
>
> Then I realized that the same INVALID state handles packets from a
> valid flow (proto/src/dst/sport/dport match conntrack table) but
> with something the netfilter decides that is wrong (ex. out of
> window segments, short/truncated/malformed packets, bad checksum,

When do these happen anyways? Bad checksum should probably be caught
by the TCP layer.


> So, I have two propositions:
> - Add another state (ex. UNCLEAN) for packet that matches
> proto/src/dst/sport/dport, but netfilter consider that it is wrong. There will
> be two states: INVALID (for packet with no known conntrack entry) and UNCLEAN
> and that gives us possibility to distinguish between these two states:
>
> -A FORWARD -m conntrack --ctstate UNCLEAN -j DROP

There was a 'unclean' match in POMng sometime ago, coincidence?

> -A FORWARD -m conntrack --ctstate INVALID -j INVALID
>
> - Drop such packets implicitly (something like s/-NF_ACCEPT/-NF_DROP/ in
> ip_conntrack_proto_*.c) and safely REJECT packets with INVALID state, like in
> my first example. This time INVALID will means that there is no appropriate
> conntrack entry, nothing else.
>
> Comments?
>
> Best regardas,
>
>
> 			Krzysztof Olędzki
>

	-`J'
-- 

Re: What should we do with packets marked as INVALID?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4694 bytes --]



On Mon, 25 Dec 2006, Jan Engelhardt wrote:

>
>
>> Date: Mon, 25 Dec 2006 02:33:59 +0100 (CET)
>> From: Krzysztof Oledzki <ole@ans.pl>
>> To: Netfilter Developer Mailing List <netfilter-devel@lists.netfilter.org>
>> Subject: What should we do with packets marked as INVALID?
>>
>> Hello,
>>
>> One of the most important feature provided by the netfilter
>> subsystem is stateful connection tracking - the ability to decide
>> that a packet is valid (or not) using not only data from a packet
>> itself but also from a history of a flaw.
>>
>> So, the question is: what should we do with packets marked as
>> INVALID?
>
>
> http://jengelh.hopto.org/p/chaostables/fw.html
> section 3. YMMV.

OK, but my fw does not try to pickup unknown connections as I disabled 
ip_conntrack_tcp_loose (net.ipv4.netfilter.ip_conntrack_tcp_loose=0) - 
there is no chance to pickup connections using sack/wscale, I don't flush 
conntrack and I don't reboot it very often. So I assume that my firewall 
should know _all_ active connections and drop/kill others.

>>
>> For a very long time I have thought that something like this should
>> work best:
>>
>> -A INVALID -m limit --limit 10/s -j LOG --log-prefix "INVALID: " --log-level 7
>> --log-tcp-sequence --log-tcp-options --log-ip-options
>> -A INVALID -p tcp -m limit --limit 4/s -j REJECT --reject-with tcp-reset
>> -A INVALID -p udp -m limit --limit 4/s -j REJECT
>> -A INVALID -j DROP
>>
>> -A FORWARD -m conntrack --ctstate INVALID -j INVALID
>>
>> This whole REJECT idea is to kill out of sync sessions - IMO it is
>> better to send RST/port-unreachable ASAP, so hosts know they should
>> reconnect immediatley (if that's appropriately) without needing to
>> wait (sometines very long) for a session to timeout. Think on
>> stalled NFS mounts, etc.
>>
>> Then I realized that the same INVALID state handles packets from a
>> valid flow (proto/src/dst/sport/dport match conntrack table) but
>> with something the netfilter decides that is wrong (ex. out of
>> window segments, short/truncated/malformed packets, bad checksum,
>
> When do these happen anyways? Bad checksum should probably be caught
> by the TCP layer.

It is checked in ip_conntrack_proto_tcp.c:

         /* Checksum invalid? Ignore.
          * We skip checking packets on the outgoing path
          * because it is assumed to be correct.
          */
         /* FIXME: Source route IP option packets --RR */
         if (ip_conntrack_checksum && hooknum == NF_IP_PRE_ROUTING &&
             nf_ip_checksum(skb, hooknum, iph->ihl * 4, IPPROTO_TCP)) {
                 if (LOG_INVALID(IPPROTO_TCP))
                         nf_log_packet(PF_INET, 0, skb, NULL, NULL, NULL,
                                   "ip_ct_tcp: bad TCP checksum ");
                 return -NF_ACCEPT;

         }

So, bad checksum => INVALID.

Anyway, other error messages are also quite common:

root@fw2:~# grep ip_ct_tcp /var/log/syslog |cut -d " " -f 6-|cut -d = -f 1|sed s/IN//|sort|uniq -c|sort
      10 ip_ct_tcp: invalid state
      11 ip_ct_tcp: truncated/malformed packet
      30 ip_ct_tcp: killing out of sync session
     173 ip_ct_tcp: SEQ is under the lower bound (already ACKed data retransmitted)
     241 ip_ct_tcp: SEQ is over the upper bound (over the window of the receiver)
     500 ip_ct_tcp: ACK is over the upper bound (ACKed data not seen yet)
     863 ip_ct_tcp: ACK is under the lower bound (possible overly delayed ACK)
    1134 ip_ct_tcp: invalid TCP flag combination
    3050 ip_ct_tcp: bad TCP checksum
   10552 ip_ct_tcp: invalid packet ignored

>> So, I have two propositions:
>> - Add another state (ex. UNCLEAN) for packet that matches
>> proto/src/dst/sport/dport, but netfilter consider that it is wrong. There will
>> be two states: INVALID (for packet with no known conntrack entry) and UNCLEAN
>> and that gives us possibility to distinguish between these two states:
>>
>> -A FORWARD -m conntrack --ctstate UNCLEAN -j DROP
>
> There was a 'unclean' match in POMng sometime ago, coincidence?

Partialy, yes. The "-m unclean" is able to check if something in a packet 
seems to be wrong, so I think it may be good name for additional state 
in '-m conntrack'. ;)

>> -A FORWARD -m conntrack --ctstate INVALID -j INVALID
>>
>> - Drop such packets implicitly (something like s/-NF_ACCEPT/-NF_DROP/ in
>> ip_conntrack_proto_*.c) and safely REJECT packets with INVALID state, like in
>> my first example. This time INVALID will means that there is no appropriate
>> conntrack entry, nothing else.
>>
>> Comments?
>>


Best regards,

 				Krzysztof Olędzki

Re: What should we do with packets marked as INVALID?

[Pablo Neira Ayuso]

Krzysztof Oledzki wrote:
> One of the most important feature provided by the netfilter subsystem is
> stateful connection tracking - the ability to decide that a packet is
> valid (or not) using not only data from a packet itself but also from a
> history of a flaw.
> 
> So, the question is: what should we do with packets marked as INVALID?
> 
> [...]
> 
> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
> invalid connections hang "forever") is also wrong, so maybe we should
> forward such packets and allow dst hosts to handle it
> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
> of the most important netfilter feature.

IMO, the default action should be drop. Having a look at the errors in
the tcp window tracking code, I can't think about a sane connection that
can generate invalid out of window packets even under packet lost.

> So, I have two propositions:
>  - Add another state (ex. UNCLEAN) for packet that matches
> proto/src/dst/sport/dport, but netfilter consider that it is wrong.

If you let the invalid packet go through just because there is a tuple
in the conntrack table that matches it then, why do you want the whole
TCP window tracking? Just disabled it via ip_conntrack_tcp_be_liberal if
you want to do so, out of window packets will not be marked as invalid,
and you can still drop unclean packets since they are marked as invalid.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: What should we do with packets marked as INVALID?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2258 bytes --]



On Thu, 28 Dec 2006, Pablo Neira Ayuso wrote:

> Krzysztof Oledzki wrote:
>> One of the most important feature provided by the netfilter subsystem is
>> stateful connection tracking - the ability to decide that a packet is
>> valid (or not) using not only data from a packet itself but also from a
>> history of a flaw.
>>
>> So, the question is: what should we do with packets marked as INVALID?
>>
>> [...]
>>
>> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
>> invalid connections hang "forever") is also wrong, so maybe we should
>> forward such packets and allow dst hosts to handle it
>> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
>> of the most important netfilter feature.
>
> IMO, the default action should be drop. Having a look at the errors in
> the tcp window tracking code, I can't think about a sane connection that
> can generate invalid out of window packets even under packet lost.

I agree to DROP it, especially that ~11Mbit/s communication betwen two of 
my hosts (FreeBSD 6) is able to ganarate the "ip_ct_tcp: ACK is under the 
lower bound" condition in about 1-2 minutes. One has 100Mbit NIC, the 
second 1Gbit NIC and there is a linux FW between them. But I also want to 
REJECT packets from unknown connections (no touple).

>> So, I have two propositions:
>>  - Add another state (ex. UNCLEAN) for packet that matches
>> proto/src/dst/sport/dport, but netfilter consider that it is wrong.
>
> If you let the invalid packet go through just because there is a tuple
> in the conntrack table that matches it then, why do you want the whole
> TCP window tracking?

I want to:
  - REJECT packets without a touple, to kill unknown connections.
  - DROP packets with a touple when window tracking decides that a packet 
is invalid

I think it is quite sane...

> Just disabled it via ip_conntrack_tcp_be_liberal if
> you want to do so, out of window packets will not be marked as invalid,
> and you can still drop unclean packets since they are marked as invalid.

It does not solve anything, AFAIK setting ip_conntrack_tcp_be_liberal 
ignores such packets but I want them to be dropped. :|

Best regards,

 				Krzysztof Olędzki

Re: What should we do with packets marked as INVALID?

[Pablo Neira Ayuso]

Krzysztof Oledzki wrote:
> On Thu, 28 Dec 2006, Pablo Neira Ayuso wrote:
>> Krzysztof Oledzki wrote:
>>> So, the question is: what should we do with packets marked as INVALID?
>>>
>>> [...]
>>>
>>> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
>>> invalid connections hang "forever") is also wrong, so maybe we should
>>> forward such packets and allow dst hosts to handle it
>>> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
>>> of the most important netfilter feature.
>>
>> IMO, the default action should be drop. Having a look at the errors in
>> the tcp window tracking code, I can't think about a sane connection that
>> can generate invalid out of window packets even under packet lost.
> 
> I agree to DROP it, especially that ~11Mbit/s communication betwen two
> of my hosts (FreeBSD 6) is able to ganarate the "ip_ct_tcp: ACK is under
> the lower bound" condition in about 1-2 minutes. One has 100Mbit NIC,
> the second 1Gbit NIC and there is a linux FW between them. But I also
> want to REJECT packets from unknown connections (no touple).

All packets have a conntrack, and therefore a tuple. Even those that
don't belong to a unexistent connection. The point is if the
conntrack is confirmed or not, ie. at least one packet of a certain
connection traversed the stack successfully. The TCP window tracking
does not mark as invalid unconfirmed conntracks, just checks if the
packets follows an appropiate protocol sequence, ie. a packet with the
flag push set for an "unknown" connection is invalid.

> I want to:
>  - REJECT packets without a touple, to kill unknown connections.
>  - DROP packets with a touple when window tracking decides that a packet
> is invalid
> 
> I think it is quite sane...

iptables -P FORWARD -j DROP
[... your ruleset ...]
iptables -A FORWARD -m state INVALID -j LOG --log-prefix "invalid: "
iptables -A FORWARD -m state INVALID -j DROP
iptables -A FORWARD -p tcp --syn -j REJECT --reject-with tcp-reset

Couldn't this be enough? In this case, an invalid packet is always
dropped, and a valid packet, a TCP syn packet for a filtered port, is
replied with a TCP reset. Of course, as I told you before, a packet with
a wrong flag combination for an unknown connection is marked as invalid
by the TCP tracking code, but this is the expected behaviour.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: What should we do with packets marked as INVALID?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2838 bytes --]



On Thu, 28 Dec 2006, Pablo Neira Ayuso wrote:

> Krzysztof Oledzki wrote:
>> On Thu, 28 Dec 2006, Pablo Neira Ayuso wrote:
>>> Krzysztof Oledzki wrote:
>>>> So, the question is: what should we do with packets marked as INVALID?
>>>>
>>>> [...]
>>>>
>>>> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
>>>> invalid connections hang "forever") is also wrong, so maybe we should
>>>> forward such packets and allow dst hosts to handle it
>>>> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
>>>> of the most important netfilter feature.
>>>
>>> IMO, the default action should be drop. Having a look at the errors in
>>> the tcp window tracking code, I can't think about a sane connection that
>>> can generate invalid out of window packets even under packet lost.
>>
>> I agree to DROP it, especially that ~11Mbit/s communication betwen two
>> of my hosts (FreeBSD 6) is able to ganarate the "ip_ct_tcp: ACK is under
>> the lower bound" condition in about 1-2 minutes. One has 100Mbit NIC,
>> the second 1Gbit NIC and there is a linux FW between them. But I also
>> want to REJECT packets from unknown connections (no touple).
>
> All packets have a conntrack, and therefore a tuple. Even those that
> don't belong to a unexistent connection. The point is if the
> conntrack is confirmed or not, ie. at least one packet of a certain
> connection traversed the stack successfully. The TCP window tracking
> does not mark as invalid unconfirmed conntracks, just checks if the
> packets follows an appropiate protocol sequence, ie. a packet with the
> flag push set for an "unknown" connection is invalid.

OK, thank you for this clarification. :)

>> I want to:
>>  - REJECT packets without a touple, to kill unknown connections.
>>  - DROP packets with a touple when window tracking decides that a packet
>> is invalid
>>
>> I think it is quite sane...
>
> iptables -P FORWARD -j DROP
> [... your ruleset ...]
> iptables -A FORWARD -m state INVALID -j LOG --log-prefix "invalid: "
> iptables -A FORWARD -m state INVALID -j DROP
> iptables -A FORWARD -p tcp --syn -j REJECT --reject-with tcp-reset
>
> Couldn't this be enough? In this case, an invalid packet is always
> dropped, and a valid packet, a TCP syn packet for a filtered port, is
> replied with a TCP reset. Of course, as I told you before, a packet with
> a wrong flag combination for an unknown connection is marked as invalid
> by the TCP tracking code, but this is the expected behaviour.

Unfortunately, this is not enough. You mentioned about a packet with the 
flag 'push' for an "unknown" connection. This is one of examples, when I 
would like to send (properly ratelimited) tcp-reset, exactly like normal 
TCP stack does.

Best regards,

 				Krzysztof Olędzki

Re: What should we do with packets marked as INVALID?

[Patrick McHardy]

Krzysztof Oledzki wrote:
> Hello,
> 
> One of the most important feature provided by the netfilter subsystem is
> stateful connection tracking - the ability to decide that a packet is
> valid (or not) using not only data from a packet itself but also from a
> history of a flaw.
> 
> So, the question is: what should we do with packets marked as INVALID?
> 
> For a very long time I have thought that something like this should work
> best:
> 
> -A INVALID -m limit --limit 10/s -j LOG --log-prefix "INVALID: "
> --log-level 7 --log-tcp-sequence --log-tcp-options --log-ip-options
> -A INVALID -p tcp -m limit --limit 4/s -j REJECT --reject-with tcp-reset
> -A INVALID -p udp -m limit --limit 4/s -j REJECT
> -A INVALID -j DROP
> 
> -A FORWARD -m conntrack --ctstate INVALID -j INVALID
> 
> This whole REJECT idea is to kill out of sync sessions - IMO it is
> better to send RST/port-unreachable ASAP, so hosts know they should
> reconnect immediatley (if that's appropriately) without needing to wait
> (sometines very long) for a session to timeout. Think on stalled NFS
> mounts, etc.
> 
> Then I realized that the same INVALID state handles packets from a valid
> flow (proto/src/dst/sport/dport match conntrack table) but with
> something the netfilter decides that is wrong (ex. out of window
> segments, short/truncated/malformed packets, bad checksum, etc).
> Rejecting such packets kills valid connections, and it is quite common
> to get a lot of, for example, "ip_ct_tcp: ACK is under the lower bound
> (possible overly delayed ACK)" on bigger firewalls:
> 
> root@fw2:~# grep -c "ip_ct_tcp: ACK is under the lower bound (possible
> overly delayed ACK)" /var/log/syslog
> 905
> 
> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
> invalid connections hang "forever") is also wrong, so maybe we should
> forward such packets and allow dst hosts to handle it
> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
> of the most important netfilter feature.


DROP shouldn't make sessions hang (otherwise they would break with NAT
as well) and is in my opinion the correct thing to do with INVALID
packets.

Re: What should we do with packets marked as INVALID?

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2776 bytes --]



On Wed, 10 Jan 2007, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> Hello,
>>
>> One of the most important feature provided by the netfilter subsystem is
>> stateful connection tracking - the ability to decide that a packet is
>> valid (or not) using not only data from a packet itself but also from a
>> history of a flaw.
>>
>> So, the question is: what should we do with packets marked as INVALID?
>>
>> For a very long time I have thought that something like this should work
>> best:
>>
>> -A INVALID -m limit --limit 10/s -j LOG --log-prefix "INVALID: "
>> --log-level 7 --log-tcp-sequence --log-tcp-options --log-ip-options
>> -A INVALID -p tcp -m limit --limit 4/s -j REJECT --reject-with tcp-reset
>> -A INVALID -p udp -m limit --limit 4/s -j REJECT
>> -A INVALID -j DROP
>>
>> -A FORWARD -m conntrack --ctstate INVALID -j INVALID
>>
>> This whole REJECT idea is to kill out of sync sessions - IMO it is
>> better to send RST/port-unreachable ASAP, so hosts know they should
>> reconnect immediatley (if that's appropriately) without needing to wait
>> (sometines very long) for a session to timeout. Think on stalled NFS
>> mounts, etc.
>>
>> Then I realized that the same INVALID state handles packets from a valid
>> flow (proto/src/dst/sport/dport match conntrack table) but with
>> something the netfilter decides that is wrong (ex. out of window
>> segments, short/truncated/malformed packets, bad checksum, etc).
>> Rejecting such packets kills valid connections, and it is quite common
>> to get a lot of, for example, "ip_ct_tcp: ACK is under the lower bound
>> (possible overly delayed ACK)" on bigger firewalls:
>>
>> root@fw2:~# grep -c "ip_ct_tcp: ACK is under the lower bound (possible
>> overly delayed ACK)" /var/log/syslog
>> 905
>>
>> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
>> invalid connections hang "forever") is also wrong, so maybe we should
>> forward such packets and allow dst hosts to handle it
>> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
>> of the most important netfilter feature.
>
>
> DROP shouldn't make sessions hang (otherwise they would break with NAT
> as well)

It blocks until timeout which sometimes simply takes to long.

> and is in my opinion the correct thing to do with INVALID packets.

OK, hopefully I found a smart solution. With 
net.ipv4.netfilter.ip_conntrack_tcp_loose enabled it is possible to 
distinguish between new tcp-ack packet without preceding syn and improper 
tcp-ack packet with a matching tuple:

iptA FORWARD -m conntrack --ctstate INVALID -j INVALID
iptA FORWARD -p tcp -m conntrack --ctstate NEW ! --syn -j INVALID_NewTCP


Best regards,

 				Krzysztof Olędzki

Re: What should we do with packets marked as INVALID?

[Patrick McHardy]

Krzysztof Oledzki wrote:
> 
> On Wed, 10 Jan 2007, Patrick McHardy wrote:
> 
>> Krzysztof Oledzki wrote:
>>
>>> So OK, REJECT is wrong (possibly kills valid connections), DROP (makes
>>> invalid connections hang "forever") is also wrong, so maybe we should
>>> forward such packets and allow dst hosts to handle it
>>> (ignore/reset/etc). Bzzzz... no, wait, it is also wrong as we lose one
>>> of the most important netfilter feature.
>>
>>
>>
>> DROP shouldn't make sessions hang (otherwise they would break with NAT
>> as well)
> 
> 
> It blocks until timeout which sometimes simply takes to long.


Not sure if I understand you correctly, but if dropping INVALID packets
makes the session hang, this would mean that valid packets are
incorrectly marked as INVALID, which would surprise me, since that
would also break with NAT (INVALID packets are not NATed) and I haven't
seen any reports of something like that.