Bug 355471 - A response to a broadcast "ICMP ping" is considered "invalid" by iptables
A response to a broadcast "ICMP ping" is considered "invalid" by iptables
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Thomas Graf
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2007-10-27 16:46 EDT by David Tonhofer
Modified: 2014-06-18 04:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-13 16:33:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Tonhofer 2007-10-27 16:46:12 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, and two machines on it, 

asuka  =
misato =

I run "ping -b -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= 
  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 
  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 -A OUTPUT -m state --state INVALID -j LOG --log-prefix "IPOUT invalid:"
...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 
  LEN=112 TOS=0x00 PREC=0xC0 TTL=255 ID=57692 PROTO=ICMP
  TYPE=3 CODE=3 
  [SRC= DST=
   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):


How reproducible:

Comment 1 Thomas Woerner 2007-11-29 12:06:35 EST
This is not a userland iptables problem. iptables is only the configuration
utility to setup netfilter in the kernel.

Assigning to kernel.
Comment 2 David Tonhofer 2007-12-05 15:50:01 EST
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.

Note You need to log in before you can comment on or make changes to this bug.