The TCP/IP stack in my 2.4.18 debian linux system has Reverse Path Filtering (rp_filter) turned on by default. This makes it drop all incoming IP packets from sources which are not in its routing tables. The dropped packets include ICMP error packets destined to the local node such as the ICMP Datagram Too Large error message used for path MTU discovery.

I have a host route to a remote system through a gateway. The Ethernet interfaces on the local system and remote system have MTU set to 1500. A router along the way to the remote system has one interface at an MTU of 1442 and sends back an ICMP Datagram Too Large error packet as per RFC1191. Since I don't have a route set for that router, the ICMP error packet is dropped and my system fails to do path MTU discovery.

Is the dropping of ICMP error packets from "unknown" sources (sources without a matching routing table entry) a bug in the Reverse Path Filtering implementation or is it an intended consequence? Should ICMP error packets destined to the local node be accepted regardless of the rp_filter setting?

I am thinking of turning off rp_filter to make the path MTU discovery work correctly.

Thanks,

- Krish -

I would like to know if turning off rp_filter on a system inside the corporate LAN presents a grave security risk. I am assuming that the corporate firewall will protect the interior server.

Does anyone know of any risk specifically introduced by the turning off of rp_filter on a server that cannot be protected by a firewall outside the server?

Thanks.

I normally recommend leaving rp_filter on unless absolutely necessary. Turning it off inside the LAN is less of a risk than doing so on a border firewall, but it still is a risk. While the border firewall may block the vast majority of spoofing attempts, rp_filter can still catch hosts inside the LAN that are compromised and spitting out malicious packets in the LAN. Usually your best option is to just fix your routing table and avoid rp_filter problems all together.