Is dropping all ICMP traffic valid?

Is dropping all ICMP traffic valid?

[alex]

I'm still trying to figure out why I'm losing connection on my
portforwarded webserver. One thing I have noticed is the gateway is
dropping ICMP packets back to the webserver:

Nov 12 23:01:16 gateway kernel: [Dropped to-lan]IN= OUT=eth0
SRC=192.168.1.250 DST=192.168.1.110 LEN=576 TOS=0x00 PREC=0xC0 TTL=64
ID=13411 PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.1.110 DST=213.155.151.41
LEN=1500 TOS=0x00 PREC=0x00 TTL=63 ID=8806 DF PROTO=TCP SPT=80 DPT=4776
WINDOW=7504 RES=0x00 ACK URGP=0 ] MTU=1478 

which seem to be related to the web connection. I thought ICMP packets
were not needed for general operation, and even if they where they would
be covered by the nat and FORWARD tables not being dropped on the local
process OUTPUT chain.

Any ideas?

-- 
Alex
http://www.bennee.com/~alex/

Re: Is dropping all ICMP traffic valid?

[Dax Kelson]

On Tue, 2002-11-12 at 16:25, alex wrote:
> I'm still trying to figure out why I'm losing connection on my
> portforwarded webserver. One thing I have noticed is the gateway is
> dropping ICMP packets back to the webserver:
> 
> Nov 12 23:01:16 gateway kernel: [Dropped to-lan]IN= OUT=eth0
> SRC=192.168.1.250 DST=192.168.1.110 LEN=576 TOS=0x00 PREC=0xC0 TTL=64
> ID=13411 PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.1.110 DST=213.155.151.41
> LEN=1500 TOS=0x00 PREC=0x00 TTL=63 ID=8806 DF PROTO=TCP SPT=80 DPT=4776
> WINDOW=7504 RES=0x00 ACK URGP=0 ] MTU=1478 
> 
> which seem to be related to the web connection. I thought ICMP packets
> were not needed for general operation, and even if they where they would
> be covered by the nat and FORWARD tables not being dropped on the local
> process OUTPUT chain.
> 
> Any ideas?

Yes. This is a classic beginner/expert mistake.

ICMP *is* needed for general operation, specifically ICMP Type 3, Code
4.

This is needed for proper MTU path discovery (PMTU). Go google and learn
about this.

If you are doing stateful filtering, then "RELATED" will automatically
match those ICMP packets. For example as the first rule in your INPUT,
or OUTPUT, and/or FORWARD chain (depending on how you have stuff
configured) have:

iptables -A INPUT/FORWARD/OUTPUT -m state --state ESTABLISHED,RELATED -j
ACCEPT

Re: Is dropping all ICMP traffic valid?

[Antony Stone]

On Tuesday 12 November 2002 11:25 pm, alex wrote:

> I'm still trying to figure out why I'm losing connection on my
> portforwarded webserver. One thing I have noticed is the gateway is
> dropping ICMP packets back to the webserver:
>
> Nov 12 23:01:16 gateway kernel: [Dropped to-lan]IN= OUT=eth0
> SRC=192.168.1.250 DST=192.168.1.110 LEN=576 TOS=0x00 PREC=0xC0 TTL=64
> ID=13411 PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.1.110 DST=213.155.151.41
> LEN=1500 TOS=0x00 PREC=0x00 TTL=63 ID=8806 DF PROTO=TCP SPT=80 DPT=4776
> WINDOW=7504 RES=0x00 ACK URGP=0 ] MTU=1478
>
> which seem to be related to the web connection. I thought ICMP packets
> were not needed for general operation, and even if they where they would
> be covered by the nat and FORWARD tables not being dropped on the local
> process OUTPUT chain.

ICMP type 3 code 4 is Source Quench - not very common these days, but 
important to let through if you run systems which use it.

Source Quench basically means "Hold it !   I can't keep up !   Slow Down!!!", 
and is used by a machine on a slow link to tell a machine on a fast link to 
stop sending data so quickly.

I recommend you let it through.

I also notice the MTU (maximum transmission unit) on this log entry is 1478 - 
you might want to check whether you've got problems with the MSS (maximum 
segment size) being larger than this, causing some packets to get fragmented, 
or even worse, discarded.

Look up "clamp mss to mtu" for more details on this.

Antony.

-- 

If you want to be happy for an hour, get drunk.
If you want to be happy for a year, get married.
If you want to be happy for a lifetime, get a garden.

Re: Is dropping all ICMP traffic valid?

[Peter E. Fry]

On 13 Nov 2002 at 1:01, Antony Stone wrote:

> ICMP type 3 code 4 is Source Quench - not very common these days, but
> important to let through if you run systems which use it.

  The only stack I've seen use source quench is the old Mac stack, 
and it sent 'em gratuitously.  Funny -- I can't bloody well remember 
how I found that out.  I must've shared a LAN with a Mac at some 
point.
  I just wanted to point that out, to those who see lots of 
"quenches" on the Internet.  I'd never advocate dropping all ICMP.

[...]

Peter E. Fry

Re: Is dropping all ICMP traffic valid?

[alex]

On Wed, 2002-11-13 at 00:36, Dax Kelson wrote:
> On Tue, 2002-11-12 at 16:25, alex wrote:
> > I'm still trying to figure out why I'm losing connection on my
> > portforwarded webserver. One thing I have noticed is the gateway is
> > dropping ICMP packets back to the webserver:
> > 
> > Nov 12 23:01:16 gateway kernel: [Dropped to-lan]IN= OUT=eth0
> > SRC=192.168.1.250 DST=192.168.1.110 LEN=576 TOS=0x00 PREC=0xC0 TTL=64
> > ID=13411 PROTO=ICMP TYPE=3 CODE=4 [SRC=192.168.1.110 DST=213.155.151.41
> > LEN=1500 TOS=0x00 PREC=0x00 TTL=63 ID=8806 DF PROTO=TCP SPT=80 DPT=4776
> > WINDOW=7504 RES=0x00 ACK URGP=0 ] MTU=1478 
> > 
> > which seem to be related to the web connection. I thought ICMP packets
> > were not needed for general operation, and even if they where they would
> > be covered by the nat and FORWARD tables not being dropped on the local
> > process OUTPUT chain.
> > 
> > Any ideas?
> 
> Yes. This is a classic beginner/expert mistake.

Probably worth adding to NAT HOTWO or FAQ (Hello Rusty?). Of course I
never had problems with my earlier script, it was just as I got paranoid
I obviously tightend the rules too much.

> ICMP *is* needed for general operation, specifically ICMP Type 3, Code
> 4.
> 
> This is needed for proper MTU path discovery (PMTU). Go google and learn
> about this.
> 
> If you are doing stateful filtering, then "RELATED" will automatically
> match those ICMP packets. For example as the first rule in your INPUT,
> or OUTPUT, and/or FORWARD chain (depending on how you have stuff
> configured) have:
> 
> iptables -A INPUT/FORWARD/OUTPUT -m state --state ESTABLISHED,RELATED -j
> ACCEPT

Ahh, this is where I got tripped up. My rules did have --state
ESTABLISHED, RELATED on the FORWARD chain. However this ICMP message was
being sent by the local machine and got blocked by my OUTPUT rules
(which where tighter) even though they related to a FORWARD'ed
connection. I also mis-understood what RELATED really means thinking it
was a useful workaround for weird protocols like FTP (although
re-reading 7.2 of the Packet filter HOWTO it is mentioned it could
probably do with highlighting) 

I was also thrown by the problem only showing itself intermitently. Of
course no its working it all makes perfect sense, like most problems :-)

-- 
Alex
http://www.bennee.com/~alex/