Bug 355471 - A response to a broadcast "ICMP ping" is considered "invalid" by iptables
Summary: A response to a broadcast "ICMP ping" is considered "invalid" by iptables
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Thomas Graf
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-27 20:46 UTC by David Tonhofer
Modified: 2014-06-18 08:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-13 20:33:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description David Tonhofer 2007-10-27 20:46:12 UTC
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

Comment 1 Thomas Woerner 2007-11-29 17:06:35 UTC
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 20:50:01 UTC
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.