Date: Fri, 31 Jan 2003 17:34:39 -0500 From: Bill Moran <wmoran@potentialtech.com> To: jdroflet@canada.com Cc: freebsd-questions@FreeBSD.ORG Subject: Re: PPtP Client to MPD to boxes behind NATD are very slow?? (solved?) Message-ID: <3E3AF9FF.3000306@potentialtech.com> References: <20030131110838.7849.h012.c009.wm@mail.canada.com.criticalpath.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to many problems I've had with MPD as a PPTP server for
Windows, as well as other's questions, I set up a test network and
did a bit of experimenting.
In my experiments, I found a number of interesting facts about PPTP:
1) PPTP doesn't do a lot of friendly negiotiation. If the server and
client aren't configured identically, problems result. These are
not always "can't connect" problems, sometimes they are "everything
works except FTP" problems.
2) disabling non-used network protocols (IPX/SPX & NetBEUI) on Win98
caused a 50% improvement in speed.
3) The connection is about the same speed whether encryption was turned
on or off.
4) Disabling multilink allows the PPTP connection to go almost as fast
as the raw network speed (on Windows XP!)
5) No matter what we did, Windows 98 was always 10x _slower_ than the
raw network speed.
6) Multilink turned on makes Windows XP as slow as Windows 98
7) I juggled MTUs around until I couldn't stand it any more. No MTU
changes that I made cause any noticable change to the connection
(either speed or reliability)
So my conclusion is this:
1) Use encryption, it doesn't slow anything down.
2) Disable multilink, whatever it does, it's not good
3) Don't use Windows 98, it's a piece of junk
4) Make absolutely sure the client is configured exactly
like the server.
This is pretty useful information for me, I hope it's helpful for you
as well as the archives. If this question comes up in the future, point
the questioner to this message in the archives.
jdroflet@canada.com wrote:
> On Fri, 31 Jan 2003 10:23:37 -0800 (PST), Bill Moran wrote:
>
>>[could you wrap lines around 72 chars or so, please]
>
> Sorry about that.
>
>>>>>After connecting via VPN I can get decent throughput from the MPD
>>>>
>>host but
>>
>>>>>very poor speed from anything past it.
>>>>
>>>>What do you mean by this? We use MPD off and on, and (honestly) it
>>>
> is just slow.
>
>>>From other posts I knew MPD would be slow but what concerns me is
>>
> that it is how much slower it is beyond the mpd host itself, see test
> results below.
>
>>I'm not sure I understand your test results.
>>Are you saying
>>PPTP client <--> MPD machine <---> "other host"
>>?
>>If so, is "other host" on the Internet, or on your
>>local network?
>
> Other host is on the local network behind the MPD box and transfers
> files at a slower rate over the PPtP connection than a transfer from the
> MPD box. I also have the 'other host' aliased to a public IP address so
> thats how I got the baseline from it.
>
>>We've seen that trying to route through the MPD
>>machine to the internet is terribly slow, but
>>haven't noticed any problems with routing to the
>>local network.
>>Did you check the box on the MS side to say
>>"use gateway on remote network"?
>
> Nope.
>
>>>>>A separte public IP is redirected to a 4.7 RELEASE box on the
>>>>
> inside.
>
>>>>>Client(s) tested with have been Windows 2000 SP2 and SP3 from 2
>>>>
>>different ADSL Lines.
>>
>>>>>client-----1.2.3.4 MPD/NATD 172.16.105.80------172.16.105.66 /
>>>>
>>5.6.7.8 Redirected from 1.2.3.4
>>
>>>>>Tests using Penguinet SCP and a 1.9 MB ZIP file.
>>>>>Baseline Download the file from the public IP's
>>>>>1.2.3.4 -> client 180 kBs
>>>>>5.6.7.8 -> client 180 kBs
>>>>>
>>>>>Now test via the PPtP.
>>>>
> 172.16.105.80 aka. 1.2.3.4 -> client 84 kBs ****
> 172.16.105.66 aka. 5.6.7.8 -> client 35 kBs **** These are the results
> that don't make sense.
>
>>I see now.
>>We haven't tested this extensively. We've only seen it when routing
>>into the VPN, just to
>>go back out on the Internet (which seemed a silly thing to do).
>
> NO I'm not trying to go back out onto the Internet but could if you
> wanted to make sure your remote workers were safe behind your firewall -
> but thats a policy/procedure discussion and not for this one :)
>
>>>Actually I used SCP on the second test so as not to skew things, in
>>
>>normal operations we won't
>> > be. My concern is test to 172.16.105.66. What
>>
>>>would make it perform worse than to 172.16.105.80 ? In my mind they
>>
>>should be same, like the public IP tests.
>>
>>Apparently, something in MPD isn't working as efficiently as it should.
>>
>>
>>>It also shows Transmit Errors=0 Receive Errors=xx <- increments at a
>>
>>slow rate when connected.
>>
>>Ok, now this is something. We need to find out the nature of the
>
> errors and fix it.
>
>>I'm very interested in getting this working better for the same reason
>>that you are. I'm going to set up a test network here and see what I
>>can figure out. I'll keep in touch with you on my findings if you
>
> agree to do the same.
> Certainly, I wonder if Archie Cobbs is out there today :)
> Here's a recap,
> File downloads to the remote client are much slower from a box(es) on
> the same network as the MPD server/Gateway than from the MPD server
> itself.
> MPD server is also running Natd and IPFW in OPEN mode for this testing.
> Have adjusted the MTU down to as low as 1350 with no difference in
> performance. ng0 does display an MTU of 1350 when the tunnel is up.
> Have tried with compression on/off - no change.
> On the W2K Network status I see a steady increase on 'Receive Errors'
> when the PPtP is up. Transmit errors=0
> Could it be something to do with NATd ? Since I'm already behind on this
> by 4 days I think I'll do up a test network without NAT and see.
> If someone can read a tcpdump I can do one of those too. Let me know
> from which box and what options.
>
> Thanks, John.
>
> __________________________________________________________
> Get your FREE personalized e-mail at http://www.canada.com
>
>
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3AF9FF.3000306>