From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pascal Hambourg Subject: Re: [ICMP] Related ICMP packets are marked INVALID Date: Thu, 31 Jan 2008 20:39:16 +0100 Message-ID: <47A223E4.1090900@plouf.fr.eu.org> References: <200801311413.31466.markus@lanai.no-ip.com> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <200801311413.31466.markus@lanai.no-ip.com> Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: netfilter@vger.kernel.org Hello, Markus Torstensson a =E9crit : >=20 > I wonder why all incomming ICMP packets keep being classified as INVA= LID when=20 > they really are RELATED (at least according to me!).=20 >=20 > Here's the interesting part of my setup (generated by fwbuilder) >=20 > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -i eth1 -p icmp -m icmp --icmp-type any -m state --state INV= ALID -j=20 > In_RULE_5 > -A INPUT -i eth1 -p icmp -m icmp --icmp-type any -m state --state REL= ATED -j=20 > In_RULE_6 The third rule will never be triggered because the first rule has=20 already accepted all packets in the RELATED state. No wonder why the=20 count is 0. > Jan 31 13:47:15 lanai kernel: ICMP invalidIN=3Deth1 OUT=3D=20 > MAC=3D00:e0:18:5b:e9:bd:00:0f:90:3a:13:80:08:00 SRC=3D24.138.53.128=20 > DST=3D90.228.193.140 LEN=3D88 TOS=3D0x00 PREC=3D0x20 TTL=3D50 ID=3D33= 531 PROTO=3DICMP=20 > TYPE=3D3 CODE=3D1 [SRC=3D90.228.193.140 DST=3D192.168.2.2 LEN=3D60 TO= S=3D0x00 PREC=3D0x00=20 > TTL=3D49 ID=3D17900 DF PROTO=3DTCP SPT=3D47612 DPT=3D51413 WINDOW=3D5= 840 RES=3D0x00 SYN=20 > URGP=3D0 ] You (90.228.193.140) tried to connect to 24.138.53.128 on port 51413,=20 which seems to be a router with a NAT redirection to private address=20 192.168.2.2. But host 192.168.2.2 seems to be down (no reply to ARP=20 request), so router 24.138.53.128 sends you back an ICMP "host=20 unreachable" error message containing the header of the packet which=20 triggered the error (with final destination 192.168.2.2) to help=20 tracking the error. However its NAT is broken and fails to translate th= e=20 final destination address 192.168.2.2 back to the original destination=20 address 24.138.53.128. Since your connection tracking has no track of=20 any connection to 192.168.2.2, it classifies the ICMP packet as INVALID= =2E=20 Your conntrack is right, the other side is broken. > I've been looking at this issue for a while, and everyone keeps telli= ng me=20 > that I should append a stateless rule to let icmp 3 and 11 through, b= ut why=20 > should I? They are wrong, you should not.