On Fri, Jan 28, 2011 at 7:19 AM, John R Pierce pierce@hogranch.com wrote:

On 01/28/11 3:28 AM, kellyremo wrote:

...

bix.hu and www.yahoo.com are "pingable" test sites. 127.0.0.1 could not be pinged [firewall drops all icmp]

what sort of firewall drops packets on localhost ?!?

yahoo.com is probably a poor choice of targets, as its a widely distributed group of servers, and you likely will be pinging different servers at different times, maybe even in different parts of the world. I would instead suggest using a target at your ISP or backbone provider.

But it's therefore *very* robust, and less likely to have a particular host drop out.

If you'd like to be paranoid, it's sometimes handy to do a DNS lookup first on your target, and ping the local gateway. those steps can be automated from your local network configuration, they can *read* your local configuration so they work on all hosts you manage, and if things start failing, you can then have it run a "traceroute" against the target.

It also carries some classic attack vectors, such as the "smurf" attack.

btw, dropping 'all icmp' is bad practice.  Internet Control Message Protocol is used for a number of things, including informing applications when a host or port is not accessible.  if you drop this, you instead hang for minutes waiting for a response instead of quickly getting back a 'target {host|port} not reachable' error.

anyways, if you drop all ICMP, you won't get any pings from anywheres.

Yup. That's why it's common to drop at external firewalls and blocked by NAT from reaching inside your network, to protect less thoroughly protected and critical hosts from distributed denial of service (DDOS) such as the now classic "ping flood" attack. There is generally no good reason to allow external ICMP packets into your local network, except maybe to allow an external monitoring system or VPN connection to verify the presence of a few exposed hosts.

On Fri, Jan 28, 2011 at 11:19 AM, cpolish@surewest.net wrote:

Nico Kadel-Garcia wrote:

...

Yup. That's why it's common to drop at external firewalls and blocked by NAT from reaching inside your network, to protect less thoroughly protected and critical hosts from distributed denial of service (DDOS)  such as the now classic "ping flood" attack. There is generally no good reason to allow external ICMP packets into your local network, except maybe to allow an external monitoring system or VPN connection to verify the presence of a few exposed hosts.

Many network security devices block all ICMP messages for    perceived security benefits, including the errors that are    necessary for the proper operation of PMTUD. This can result in    connections that complete the TCP three-way handshake correctly,    but then hang when data is transferred. This state is referred    to as a black hole connection.

I'm not sure how the lack of PMTUD is worked around: given the number of environments for which blocking ICMP entirely is standard practice, it can't be *too* much of an issue, can it? I'm deducing, without enough proof, that the upstream ISP's routers have to handle ICMP from the other routers they speak with. But other than that, why should it be supported again? Do household network devices really need to do the path optimization supported by this? They're not multi-homed: perhaps the single gateway that they use helps avoid the issue?