ICMP Filtering on a firewall

We often run into networks that are behind a firewall that blocks all ICMP.

This is not only a bad idea, it increases cost of network ownership due to increased troubleshooting costs and degraded TCP (not UDP) performance in many cases.

Remember, ICMP is designed into the internet core protocols for a specific reason: out-of-band signalling between the end notes that are talking IP AND the intermediate networks that carry the traffic. Blocking some types of ICMP traffic is a very good idea and increases network security. Blocking ALL icmp actually destabilizes your network.

A. These icmp types below should be allowed, and statefully filtered. If your firewall cannot support stateful filtering of icmp get a new firewall. Cisco ASAs and OpenBSD PF are capable of blocking dangerous icmp packets, icmp control packets that are not related to a tcp or udp session. If you are using a packet filtering router or an older firewall without stateful inspection then upgrade your firewall.

Host implementation:Mandatory.  

Router implementation:Mandatory.

echo reply: type 0 (ping reply)
echo request: type 8 (ping request)

B. The ICMP types below MUST be allowed, for TCP to function properly. Blocking these types makes your network is not rfc-compliant and prone to mysterious problems that manifest themselves in strange, hard to troubleshoot ways like path mtu blackhole. If you have servers behind a firewall that blocks all icmp, and those servers set the DF bit on all outgoing tcp segments, then remote clients that are behind netwoks that have smaller MTUs, like pppoe or dsl, or some mpls WANs will not be able to transfer tcp data, or they will transfer it very slowly. To the end user this will appear as a website that is very very slow, or only some pages and images will load.

Problems with tcp window scaling and firewalls that filter these options on ip packets with tcp connection setup can also cause problems. Here is a case study:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080742d6e.shtml

From the doc:

dropped TCP connections [are] caused by some versions of PIX software not
supporting the TCP Window Scaling option. This causes it to have a much
smaller TCP window than the endpoints actually have. This causes the Cisco
PIX to drop packets that it believes are outside the TCP window, but which
really are not.

Inbound can't fragment, among other messages: icmp type 3

ttl exceeded: icmp type 11

general parameter problem: icmp type 12

Some older documentation may suggest allowing:

Inbound Sourch quench: icmp type 4

But i have found that this is not necessary really.

Basically, if you feel compelled for some strange reason to filter ICMP then at an ABSOLUTE minium you must allow path mtu discovery to work properly and that means NOT blocking icmp type 3 code 4.

Here is a simple pf rule which can do this:

macro:

icmp_types = "{ echoreq, unreach}"

rules:

pass inet proto icmp all icmp-type $icmp_types keep state

pass out on $ext_if proto { tcp, udp, icmp } all modulate state

The 2nd rule will enable stateful tracking of tcp and udp sessions, and allow icmp that is naturally part of those sessions to be passed correctly. In additon ping replies will be allow in response to inconing ping requests since that is part of the "state" that is created for you inside pf.

Here is a proper ruleset and config for a Cisco ASA firewall:

access-list inet_in extended permit icmp any any time-exceeded access-list inet_in extended permit icmp any any unreachable access-list inet_in extended permit icmp any any echo-reply access-list inet_in extended permit icmp any any echo  policy-map global_policy  class inspection_default   inspect icmp  access-group inet_in in interface outside