Bug 355471

Summary: A response to a broadcast "ICMP ping" is considered "invalid" by iptables
Product: Red Hat Enterprise Linux 4 Reporter: David Tonhofer <bughunt>
Component: kernelAssignee: Thomas Graf <tgraf>
Status: CLOSED NOTABUG QA Contact: Martin Jenner <mjenner>
Severity: low Docs Contact:
Priority: low    
Version: 4.0CC: rkhan, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-13 20:33:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.