[vpn] RE: MTU Problems

Christopher Gripp cgripp at axcelerant.com
Thu Oct 4 18:44:14 EDT 2001


RedCreek also has a setting for 'ignore don't frag bit'


-----Original Message-----
From: Goldsmith, Eric [mailto:EGoldsmith at SmartPipes.com]
Sent: Thursday, October 04, 2001 7:33 AM
To: 'David McNeese'; vpn at securityfocus.com
Subject: [vpn] RE: MTU Problems


David,

What you're seeing is an issue that has plagued VPNs since their
beginnings.


The way to "fix" it is to find and correct the cause of the blocked ICMP
messages (what you refer to as "NACK"). Easier said than done. 

It's worth noting that Yahoo is not alone. Many Web sites are affected
by
this issue.

I was in contact with a Yahoo network engineer about this issue some
weeks
ago. He assured me that Yahoo is not blocking such messages and that it
is
likely someone upstream of them (i.e. their provider). The blocking of
these
messages can be caused by many things including misconfigured routers
and
buggy router software.

I have found two work arounds that you might try. The first is to reduce
the
MTU setting on the client machine behind your VPN gateway. This causes
the
TCP sessions with the data source (Yahoo, in this case) to negotiate a
smaller MSS (related to MTU) causing the source to send smaller packets.

On Windows machines, this involves editing the registry, but can be
automated by a tool recommend by Cisco call DrTCP
(http://www.dslreports.com/front/DRTCP019.exe). An MTU value of 1400 is
recommended in this situation.

Obviously, the work around above is not desirable if you have many
client
machines, or your not able to 'touch' them. Another option is to modify
the
behavior of the DF bit on the gateway facing the Internet so that you
can
force it off for the IPSec packets. This has the effect of allowing
fragmentation between the tunnel endpoints. This will negatively impact
performance due to the large number of fragments that will be created,
and
because the fragments will be small packets. But it beats the
alternative of
no connectivity to the affected sites.

Although controlling the DF bit is required in the IPSec RFC (section
6.1.1
of RFC 2401), I only know of one vendor to have implemented it - Cisco
with
IOS 12.2(2)T
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newf
t/12
2t/122t2/ftdfipsc.htm).

Good luck.

-Eric

-----Original Message-----
From: David McNeese [mailto:dmcneese at lanl.gov] 
Sent: Wednesday, October 03, 2001 5:14 PM
To: vpn at securityfocus.com
Subject: MTU Problems


We have recently begun to have problems accessing some web sites via our
VPN
connections.  We are using an Intel NetStructure as well as an Intraport
2+
.  Here's what has started:

The VPN process must add some additional information to the headers of
each
frame,  as a result the MTU is somewhat less than 1500 bytes. There are
several web sites (Yahoo in particular) that is sending data to us in
1500
byte frames with the "Do Not Fragment Bit" set.  The result is, our
boxes
throw the frames away because they aren't allowed to fragment it.  A
message
(NACK) is send back to the website requesting smaller frames (part of
the
RSVP protocol) or asking that the "do not fragment bit" not be set.  We
still get the 1500 byte frames so the client can't get the page.

Has anybody else run into this?  Are you aware of a solution (it seems
to me
it is a config problem at Yahoo)?

Thanks!


*************************************************************
"Cheer up, things could be worse.  So
I cheered up and sure enough, things got worse."

David McNeese
CCN-5 Network Services Team
MS B255
505-667-5226 (voice)
dmcneese at lanl.gov


VPN is sponsored by SecurityFocus.com


VPN is sponsored by SecurityFocus.com





More information about the VPN mailing list