iptables: state RELATED and ICMP

This post,
http://lists.debian.org/debian-firew.../msg00045.html
claims "You will never see an ICMP types 3 or 11 with state NEW. Either they
are related to an existing connection and marked with state RELATED, or they
are not and they are marked with state INVALID."

Is that true? If so, if I have two rules
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

can I assume that makes these following rules
$IPT -A INPUT -i $INTERNET -p icmp --icmp-type destination-unreachable -d
$IPADDR -j ACCEPT

$IPT -A OUTPUT -o $INTERNET -p icmp --icmp-type fragmentation-needed -s
$IPADDR -j ACCEPT
are redundant, and this rule
$IPT -A OUTPUT -o $INTERNET -p icmp --icmp-type destination-unreachable -s
$IPADDR -j DROP
will also never be acted on?




Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Hello,

jqpx37 a écrit :
> This post,
> http://lists.debian.org/debian-firew.../msg00045.html
> claims "You will never see an ICMP types 3 or 11 with state NEW. Either they
> are related to an existing connection and marked with state RELATED, or they
> are not and they are marked with state INVALID."
>
> Is that true?

I'm the one who wrote this, so I believe it is true.
There is an exception, though. Kernels in the 2.4 series before 2.4.29
fail to mark locally some locally generated related ICMP packets as
RELATED and wrongly marks them as INVALID instead. I can't tell about
2.6 kernels.

> If so, if I have two rules
>
> $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> can I assume that makes these following rules
>
> $IPT -A INPUT -i $INTERNET -p icmp --icmp-type destination-unreachable
> -d $IPADDR -j ACCEPT
>
> $IPT -A OUTPUT -o $INTERNET -p icmp --icmp-type fragmentation-needed
> -s $IPADDR -j ACCEPT
>
> are redundant, and this rule
>
> $IPT -A OUTPUT -o $INTERNET -p icmp --icmp-type destination-unreachable
> -s $IPADDR -j DROP
>
> will also never be acted on?

The last three rules may actually be triggered. The first two rules
match only ESTABLISHED and RELATED states. But I said that ICMP type 3
state could be either RELATED or INVALID. When its state is INVALID, a
packet won't obviously match the first two rules but may still match one
of the next rules. So such rules in the OUTPUT chain may still be
necessary with an old 2.4 kernel. About the DROP rule, please note that
destination-unreachable is one of the ICMP types that should not be blocked.

"Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote in message
news:ed3lve$uje$(E-Mail Removed)...
> Hello,
>
> jqpx37 a écrit :
>> This post,
>> http://lists.debian.org/debian-firew.../msg00045.html
>> claims "You will never see an ICMP types 3 or 11 with state NEW. Either
>> they
>> are related to an existing connection and marked with state RELATED, or
>> they
>> are not and they are marked with state INVALID."
>>
>> Is that true?
>
> I'm the one who wrote this, so I believe it is true.
> There is an exception, though. Kernels in the 2.4 series before 2.4.29
> fail to mark locally some locally generated related ICMP packets as
> RELATED and wrongly marks them as INVALID instead. I can't tell about 2.6
> kernels.
>
>> If so, if I have two rules
>>
>> $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>> $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> can I assume that makes these following rules
>>
>> $IPT -A INPUT -i $INTERNET -p icmp --icmp-type
>> destination-unreachable -d $IPADDR -j ACCEPT
>>
>> $IPT -A OUTPUT -o $INTERNET -p icmp --icmp-type fragmentation-needed -s
>> $IPADDR -j ACCEPT
>>
>> are redundant, and this rule
>>
>> $IPT -A OUTPUT -o $INTERNET -p icmp --icmp-type
>> destination-unreachable -s $IPADDR -j DROP
>>
>> will also never be acted on?
>
> The last three rules may actually be triggered. The first two rules match
> only ESTABLISHED and RELATED states. But I said that ICMP type 3 state
> could be either RELATED or INVALID. When its state is INVALID, a packet
> won't obviously match the first two rules but may still match one of the
> next rules. So such rules in the OUTPUT chain may still be necessary with
> an old 2.4 kernel. About the DROP rule, please note that
> destination-unreachable is one of the ICMP types that should not be
> blocked.

Thanks for replying.

Out of curiosity---did you determine the behavior by looking at source code,
or by actually watching packets?



Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

jqpx37 a écrit :
>
> Out of curiosity---did you determine the behavior by looking at source code,
> or by actually watching packets?

Mostly by watching packets logs. I'm rather poor at reading source code.