Firewall Wizards mailing list archives

Re: how to block ICMP tunneling?


From: "Geva Patz" <geva () planet co za>
Date: Tue, 20 Jul 1999 16:42:38 +0200


I was under the impression that ICMP should be blocked coming from the
outside.  I can't think of any reason you would want some one from the
outside PINGing, TRACRTing or otherwise Probing your internal network for
active hosts.  IMHO you should simply block the entire proctocol from the
outside.

I have experienced issues with this breaking path MTU discovery (which
relies on an ICMP code 3, type 4 packets returning). The behaviour I've seen
was in a configuration which looked like this (I'm leaving out a lot of
irrelevant intermediate steps in this picture):

+--------+   +----+     +--------+   +--------+
| Server |---| FW |-----| Router |---| Client |
+--------+   +----+     +--------+   +--------+

The server (which I believe was running Solaris) was 'inside' the firewall,
(which I believe was running Checkpoint FW/1); everything else was
'outside'. The firewall was configured for 'no incoming ICMP', but would
allow HTTP connections to the server. The router was configured with a small
MTU (600).

The client would successfully complete the three-way handshake with port 80
on the server, and would successfully send a small packet with the HTTP GET
request in it. The server responded with an 1100-byte long packet containing
the (small) home page in its entirety. This packed had the Don't Fragment
flag set. The packet made it as far as the router, which dropped it and sent
back and ICMP 3/4 response (packet too big). This got swallowed by the
firewall, and the server (which was clearly running a TCP stack without a
lot of initiative) kept sending 1100-byte packets which never made it to
their destination.

The result was that all users behind the router were unable to access the
web site on the remote server. Since the firewall and the server were at
another organisation beyond my control, and since the MTU on the router
could not be raised for various reasons, the only workaround I could find
was to site a HTTP proxy server on the 'front' side of the router and route
requests for the users behind the router through that.

-- Geva





Current thread: