[ICMP] Related ICMP packets are marked INVALID

[ICMP] Related ICMP packets are marked INVALID

[Markus Torstensson]

Hi folks.

I wonder why all incomming ICMP packets keep being classified as INVALID when 
they really are RELATED (at least according to me!). 

Here's the interesting part of my setup (generated by fwbuilder)

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p icmp -m icmp --icmp-type any -m state --state INVALID -j 
In_RULE_5
-A INPUT -i eth1 -p icmp -m icmp --icmp-type any -m state --state RELATED -j 
In_RULE_6
-A INPUT -j RULE_8

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth1 -m state --state NEW -j ACCEPT
-A OUTPUT -j RULE_8

-A In_RULE_5 -j LOG --log-prefix "ICMP invalid" --log-level 6
-A In_RULE_6 -j LOG --log-prefix "ICMP related" --log-level 6
-A RULE_8 -j LOG --log-prefix "RULE 8 -- DENY " --log-level 6
-A RULE_8 -j DROP


Here are some of the logs:

[root@lanai log]# grep -c invalid messages
967
[root@lanai log]# grep -c related messages
0 
[root@lanai log]# grep invalid messages |tail -n 3
Jan 31 13:47:15 lanai kernel: ICMP invalidIN=eth1 OUT= 
MAC=00:e0:18:5b:e9:bd:00:0f:90:3a:13:80:08:00 SRC=24.138.53.128 
DST=90.228.193.140 LEN=88 TOS=0x00 PREC=0x20 TTL=50 ID=33531 PROTO=ICMP 
TYPE=3 CODE=1 [SRC=90.228.193.140 DST=192.168.2.2 LEN=60 TOS=0x00 PREC=0x00 
TTL=49 ID=17900 DF PROTO=TCP SPT=47612 DPT=51413 WINDOW=5840 RES=0x00 SYN 
URGP=0 ]
Jan 31 13:49:27 lanai kernel: ICMP invalidIN=eth1 OUT= 
MAC=00:e0:18:5b:e9:bd:00:0f:90:3a:13:80:08:00 SRC=24.138.53.128 
DST=90.228.193.140 LEN=88 TOS=0x00 PREC=0x20 TTL=50 ID=33532 PROTO=ICMP 
TYPE=3 CODE=1 [SRC=90.228.193.140 DST=192.168.2.2 LEN=60 TOS=0x00 PREC=0x00 
TTL=49 ID=27024 DF PROTO=TCP SPT=47704 DPT=51413 WINDOW=5840 RES=0x00 SYN 
URGP=0 ]
Jan 31 13:49:27 lanai kernel: ICMP invalidIN=eth1 OUT= 
MAC=00:e0:18:5b:e9:bd:00:0f:90:3a:13:80:08:00 SRC=24.138.53.128 
DST=90.228.193.140 LEN=88 TOS=0x00 PREC=0x20 TTL=50 ID=33533 PROTO=ICMP 
TYPE=3 CODE=1 [SRC=90.228.193.140 DST=192.168.2.2 LEN=60 TOS=0x00 PREC=0x00 
TTL=49 ID=27025 DF PROTO=TCP SPT=47704 DPT=51413 WINDOW=5840 RES=0x00 SYN 
URGP=0 ]

These (typical) entries are probably generated by my bittorrent client while 
trying to connect to client on local networks.

I've been looking at this issue for a while, and everyone keeps telling me 
that I should append a stateless rule to let icmp 3 and 11 through, but why 
should I? These connections should be related according to the manual:

"....and RELATED meaning that the packet is starting a new connection,  but  
is  associated  with  an existing  connection,  such  as  an  FTP  data 
transfer, or an ICMP error."

Or is this a missinterperation? I understand these ICMP packets do not 
actually relate to any established connection, but they do relate to 
connections in the NEW state. 

Thankful for any input.

/Markus

Re: [ICMP] Related ICMP packets are marked INVALID

[Pascal Hambourg]

Hello,

Markus Torstensson a écrit :
> 
> I wonder why all incomming ICMP packets keep being classified as INVALID when 
> they really are RELATED (at least according to me!). 
> 
> Here's the interesting part of my setup (generated by fwbuilder)
> 
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -i eth1 -p icmp -m icmp --icmp-type any -m state --state INVALID -j 
> In_RULE_5
> -A INPUT -i eth1 -p icmp -m icmp --icmp-type any -m state --state RELATED -j 
> In_RULE_6

The third rule will never be triggered because the first rule has 
already accepted all packets in the RELATED state. No wonder why the 
count is 0.

> Jan 31 13:47:15 lanai kernel: ICMP invalidIN=eth1 OUT= 
> MAC=00:e0:18:5b:e9:bd:00:0f:90:3a:13:80:08:00 SRC=24.138.53.128 
> DST=90.228.193.140 LEN=88 TOS=0x00 PREC=0x20 TTL=50 ID=33531 PROTO=ICMP 
> TYPE=3 CODE=1 [SRC=90.228.193.140 DST=192.168.2.2 LEN=60 TOS=0x00 PREC=0x00 
> TTL=49 ID=17900 DF PROTO=TCP SPT=47612 DPT=51413 WINDOW=5840 RES=0x00 SYN 
> URGP=0 ]

You (90.228.193.140) tried to connect to 24.138.53.128 on port 51413, 
which seems to be a router with a NAT redirection to private address 
192.168.2.2. But host 192.168.2.2 seems to be down (no reply to ARP 
request), so router 24.138.53.128 sends you back an ICMP "host 
unreachable" error message containing the header of the packet which 
triggered the error (with final destination 192.168.2.2) to help 
tracking the error. However its NAT is broken and fails to translate the 
final destination address 192.168.2.2 back to the original destination 
address 24.138.53.128. Since your connection tracking has no track of 
any connection to 192.168.2.2, it classifies the ICMP packet as INVALID. 
Your conntrack is right, the other side is broken.

> I've been looking at this issue for a while, and everyone keeps telling me 
> that I should append a stateless rule to let icmp 3 and 11 through, but why 
> should I?

They are wrong, you should not.