OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: path MTU discovery issue
From: Greg A. Woods (woodsweird.com)
Date: Wed Sep 06 2000 - 12:27:48 CDT


[ On Wednesday, September 6, 2000 at 11:50:39 (-0400), Tim Harrison wrote: ]
> Subject: Re: path MTU discovery issue
>
> After doing repeated pings backwards, starting at the remote mail
> server, I found that for both networks that I'm trying to reach, there's
> a hop along the way that doesn't respond if you use: ping -D -s 1472
> x.x.x.x. So, I assume that there's a router along the way that's
> causing the problems. But, considering I've turned on and off path MTU
> discovery, it should have worked sometime.

Ah ha! This is good information. I was not able to determine this in
the cases where I was having problems (and indeed my problems were with
apparently random sites all around the world).

Presumably when you say that it doesn't respond I'm guessing that you're
not even seeing any ICMP "needs frag" replies from the router just prior
to the one that doesn't respond either.

So, this means we need to establish for certain that your own firewall
isn't blocking these replies. There are many ways to do this of course
but the best way might be to run tcpdump or some other sniffer on the
outside of the firewall and look for such replies. For example if you
ping with large "DF" packets from an internal host that is not
generating or receiving any other packets from the outside world then
you'll best be able to see any such replies quite easily.

If you are getting such replies all the way to the outside of your
firewall then it's still at fault for not letting them in (they're
fundamental to the correct functioning of Path-MTU-discovery of course).
If you fix the firewall to let these replies in then you should be able
to get your e-mail through again. However given that you've tried
turning off P-MTU-d this is probably the least likely scenario.

If you're not getting such replies then someone else's router or
firewall is at fault.

If the failing hop is not at the border of the network you're trying to
reach then that someone isn't being a very friendly transit provider,
but in more common cases the failing hop will be the border of the
network you're trying to reach and it'll be their firewall at fault.

On occasion the problem's not a firewall per se but rather a load
balancer or redundancy device. For example at one point the BigIP
device made by F5 Labs had such a problem (and I first encountered this
problem when trying to reach the whois server at the InterNIC a couple
of years ago.

If it's not their firewall then I'd bet the most likely other candidate
culprit is your own ISP. I've helped several local ISPs "fix" their
filters so that they are not the cause of this problem but no doubt
there are still more at fault. Note that many ISPs have some form of
ICMP filtering tools either in place or ready to deploy in order to
allow them to control smurf-style attacks and such. In at least some
cases they are using nifty rate-limiting tools to prevent ICMP from
taking over various network links. Unfortunately they often deploy such
filters without regard to the types of ICMP that are fundamentally
critical to the correct functioning of TCP/IP.

-- 
							Greg A. Woods

+1 416 218-0098 VE3TCP <gwoodsacm.org> <robohack!woods> Planix, Inc. <woodsplanix.com>; Secrets of the Weird <woodsweird.com>