[ previous ] [ next ] [ threads ]
 
 From:  "Jeff Scott" <scott at advbiol dot com>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] PPTP Client behind m0n0 = Remote Desktop MTU/Fragmentation Problem
 Date:  Wed, 22 Mar 2006 10:38:23 -0500
OK,

I spent some time last night doing some diagnostics.    I found that the 
default MTU for a Windows VPN connection is 1400 as per Microsoft 
documentation.  I used the "ping -l -f" command to determine my actual MTU. 
Here are the results:

Pinging my Comcast default gateway from behind m0n0wall
========================================
ping 68.84.48.1 -l 1272 -f    (1272 is the largest size I could successfully 
ping with)

Pinging a device on my company lan while connected to VPN from behind 
m0n0wall
=========================================================
ping 192.168.1.254 -l 1235 -f  (1235 is the largest size I could 
successfully ping with)
(Sizes from 1236-1372 returned a "Request Timed Out")
(Sized greater than 1372 returned "Packet needs to be fragmented but DF 
set")

Pinging my Comcast default gateway from behind GNATBox
=========================================
ping 68.84.48.1 -l 1272 -f   (1272 is the largest size I could successfully 
ping with)

Pinging a device on my company lan while connected to VPN from behind 
GNATBox
==========================================================
ping 192.168.1.254 -l 1368 -f  (1368 is the largest size I could 
successfully ping with)
(Sizes from 1369-1372 returned a "Request Timed Out")
(Sizes greater than 1372 returned "Packet needs to be fragmented but DF 
set")

Here are my conclusions from these test results:

My MTU from Comcast (Cable Internet) is only 1300 (Seems pretty low to me. 
And this may be what changed that broke RDP).  I'm sure that since this 
number is lower than the defualt MTU for Windows VPN connections, that is 
contributing to my problems.

There is a very large range of packet sizes while connected to the vpn from 
behind the m0n0wall that disappear?  This also happens with the GNATBox, but 
only between 1369 & 1372.  This explains why I don' have trouble with RDP 
when using the GNATBox.

Behind both firewalls, packets greater than 1372 respond with fragmentation 
needed messages.  This makes sense, since the default MTU for Windows VPN 
connections is 1400.  (1372 + 20 byte IP header + 8 byte ICMP header = 1400)

Now for what I don't understand:

Why is there a range of packet sizes behind both firewalls that return 
"Request Timed Out"?
Why are these ranges different between the two firewalls?
Why is the vpn MTU larger behind the GNATBox than behind the m0n0wall?

Chris,  I took your suggestion...  I used the Dr. TCP Utility on my client 
pc and changed the MTU for just the "RAS" connections to 1200 (I left the 
MTU for the NIC at the default of 1500).  This corrected the problem when 
behind the m0n0wall and I could RDP without any problems.

Well there are my findings.  Can anyone help me understand the parts that I 
am unclear on?

Thanks all,

Jeff


----- Original Message ----- 
From: "Chris Buechler" <cbuechler at gmail dot com>
Cc: <m0n0wall at lists dot m0n0 dot ch>
Sent: Tuesday, March 21, 2006 5:56 PM
Subject: Re: [m0n0wall] PPTP Client behind m0n0 = Remote Desktop 
MTU/Fragmentation Problem


On 3/21/06, Jeff Scott <scott at advbiol dot com> wrote:
>
> I did try lowering the MTU on the WAN interface to 1000.  That did not do 
> anything.  But, I'm not sure if I needed to reboot everything for that to 
> really take effect.  Or do I need to try something like 500.  I also did 
> not try playing with the MTU on my computer either.
>

you shouldn't have to go any lower than 1000, for testing purposes.
Try lowering the MTU on your computer first to see if that makes any
difference, and secondly, try lowering the MTU on the server/machine
you're connecting to via RDP.

-Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch