Red Hat Bugzilla – Bug 355471
A response to a broadcast "ICMP ping" is considered "invalid" by iptables
Last modified: 2014-06-18 04:29:45 EDT
Description of problem: A response to a broadcast "ICMP ping message" is considered "invalid" by iptables, i.e. the criterium "--state INVALID" matches the response ICMP ping response message. This does not occur with unicast ICMP ping messages. What happens: I have a private network 192.168.1.0/24, and two machines on it, asuka = 192.168.1.65 misato = 192.168.1.64 I run "ping -b 192.168.1.255 -c 1" from asuka. The iptables have been modified to do logging. In the kernel log of misato, we find: The incoming ICMP, being accepted (TYPE=8, echo request) Oct 27 22:16:41 misato kernel: IPIN icmp: IN=eth1 OUT= MAC=.... SRC=192.168.1.65 DST=192.168.1.255 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=50205 SEQ=0 The ICMP ping response packet is generated but is considered INVALID by iptables (maybe because the source does not match the destination of the incoming packet? rank speculation of course). (TYPE=0, echo response) Oct 27 22:16:41 misato kernel: IPOUT invalid: IN= OUT=eth1 SRC=192.168.1.64 DST=192.168.1.65 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=3158 PROTO=ICMP TYPE=0 CODE=0 ID=50205 SEQ=0 The iptables REJECT this packet, thus an ICMP error message is generated. This is due to the fact that if INVALID is matched, my setup REJECTs (as opposed to DROPing), like so: $IPTABLES -P OUTPUT DROP $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state INVALID -j LOG --log-prefix "IPOUT invalid:" $IPTABLES -A OUTPUT -m state --state INVALID -j REJECT ...special rules follow... The ICMP error message due to the REJECT is itself considered INVALID, and forcibly dropped (one must not answer to an ICMP error message): (TYPE=3, Destination Unreachable) Oct 27 22:16:41 misato kernel: IPOUT invalid: IN= OUT=lo SRC=192.168.1.64 DST=192.168.1.64 LEN=112 TOS=0x00 PREC=0xC0 TTL=255 ID=57692 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.1.64 DST=192.168.1.65 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=3158 PROTO=ICMP TYPE=0 CODE=0 ID=50205 SEQ=0 ] Version-Release number of selected component (if applicable): iptables-1.2.11-3.1.RHEL4 How reproducible: Always
This is not a userland iptables problem. iptables is only the configuration utility to setup netfilter in the kernel. Assigning to kernel.
Red Hat support says this is working as designed. Service Request 1779266: "I discussed this issue with Engineering and they are of the opinion that this is by design and is not a bug. Below is the comments from Engineering." -------------- After thinking about this, i'm going to have to think that this is by design. The stateful matching of iptables classifies this as an invalid packet because there is no stream, related or otherwise coming back from those hosts. While the function may be valid on a network, the "packet" is not valid in regards to connection tracking. -------------- The Workaround is as follows: "if you are dropping INVALID packets and want broadcast ping to work, you should add an iptables rule before the rule to drop INVALID packets. Only then you would be able to accept ICMP replies for broadcast pings." OR agrees.