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.
-
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
