VPN and icmp

Neil Ratzlaff neil.ratzlaff at UCOP.EDU
Thu Aug 24 16:56:26 EDT 2000


It isn't exactly a Cisco bug - I think it is an NT bug, but M$ doesn't
agree.  Cisco can't encrypt the packet and complains using icmp as it
should.  The firewall was blocking traffic originating at the Cisco router
as we never expected traffic from that source, so the NT machines never saw
the icmp traffic.

This means we have to allow icmp traffic from ANY source into our network,
though we can restrict the type of icmp.  (Loki  attacks are always lurking
around the back of my mind.)   I thought a better solution would be to have
NT stop setting the DF, and then Cisco could fragment and encrypt the
packet.  Secondhand information from M$ says it is not possible to turn off
DF, and even if you could the performance degradation would be unacceptible
since NT would convert to using very small packets.

Does internet traffic usually have packets with DF set?  I would expect
that to be a nuisance as packets traverse so many MTU paths.

Neil

At 05:27 PM 8/21/00 -0500, Dana J. Dawson wrote:
>Neil Ratzlaff wrote:
>
> > We recently tried to set up a Cisco VPN with some NT servers at our end,
> > the other end had Windows something.  Parts of it worked and parts didn't,
> > and we eventually found the cause to be the close Cisco router sending icmp
> > type 3 code 4 packets back to the NT machines.  The packets from NT had the
> > 'Don't Fragment' bit set, and Cisco couldn't encrypt them and still fit
> > them under the packet size limit.  I suggested the NT owners stop setting
> > the Don't Fragment bit, and they said there was no way to do that.  They
> > also cited RFC 1853:
> >
> > 3.1.  Tunnel MTU Discovery
> >     When the Don't Fragment bit is set by the originator and copied into
> >     the outer IP header, the proper MTU of the tunnel will be learned
> >     from ICMP (Type 3 Code 4) "Datagram Too Big" errors reported to the
> >     encapsulator.  To support originating hosts which use this
> >     capability, all implementations MUST support Path MTU Discovery
> >     [RFC-1191, RFC-1435] within their tunnels.
> >
> > So....  questions:
> > 1.  Can NT stop setting the Don't Fragment bit, and if so, how?
> > 2.  What is the best way to deal with this situation?
> >
> > Thanks,
> > Neil
> >
> > VPN is sponsored by SecurityFocus.COM
>
>If the NT box is setting the DF bit (presumably with the intent of doing MTU
>Path Discovery), and the local Cisco box is replying with Datagram Too Big
>errors, then it's the NT box's responsibility to fall back to a smaller MTU
>until the packets get through. If this isn't happening, it's an NT
>problem, not
>a Cisco problem.  I don't understand where the Cisco bug is, unless there's a
>part of the picture I haven't picked up on.
>
>Dana
>
>--
>Dana J. Dawson                              dana at interprise.com
>Distinguished Principal Engineer            CCIE #1937
>Qwest Communications International, Inc.    (612) 664-3364
>600 Stinson Blvd., Suite 1S                 (612) 664-4779 (FAX)
>Minneapolis  MN  55413-2620
>
>"Hard is where the money is."
>
>VPN is sponsored by SecurityFocus.COM

VPN is sponsored by SecurityFocus.COM




More information about the VPN mailing list