Date: Fri, 31 Jan 2003 09:23:53 -0800 (PST) From: jdroflet@canada.com To: wmoran@potentialtech.com Cc: freebsd-questions@FreeBSD.ORG Subject: Re: PPtP Client to MPD to boxes behind NATD are very slow ?? Message-ID: <20030131092353.11107.h020.c009.wm@mail.canada.com.criticalpath.net>
next in thread | raw e-mail | index | archive | help
On Fri, 31 Jan 2003 09:00:07 -0800 (PST), Bill Moran wrote: > > jdroflet@canada.com wrote: > > 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. I've got some tricks on how to speed it up, but it's slow no matter what. 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 have tried adjusting the iface mtu to as low as 1350 with the same results. > > I've never seen the MTU change improve it much. > > > Problems are on downloading files from the hosts to the client. > > I have: > > MPD version 3.10 > > 4.5-RELEASE as a Gateway/NATD/Firewall using IPFW. IPFW is set to OPEN. > > You don't state your hardware. Keep in mind that MPD is encryption and encryption > is processor intensive. Faster CPU should give faster performance. Hardware: CPU: Pentium 4 (1495.16-MHz 686-class CPU) real memory = 1073180672 (1048028K bytes) The box is dedicated to NAT and now trying MPD - it's a very bored box ;) The box at 5.6.7.8 is a new install and has the same specs. Network cards are public Intel Server fxp0 and onboard 3com xl0. 5 mbs fibre to our ISP. > > > 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 -> client 84 kBs > > 172.16.105.66 -> client 35 kBs > > This is about what I normally expect from it (unfortunately). I'm assuming that you didn't > SCP on the second test as well, since that would be encrypting the data twice, and at least > one obvious cause of your slowdown. 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. > > > The configs and a log. > > > > mpd.conf > > default: > > load pptp > > > > pptp: > > new -i ng0 pptp pptp > > set iface disable on-demand > > set iface enable proxy-arp > > set iface idle 1800 > > set iface mtu 1350 > > set bundle enable multilink > > set link yes acfcomp protocomp > > set link no pap chap > > set link enable chap > > set link keep-alive 10 60 > > # set link mtu 1460 > > set ipcp yes vjcomp > > set ipcp ranges 172.16.105.80/32 172.16.105.75/32 > > set ipcp dns 172.16.105.67 > > > > set bundle enable compression > > If you're using ADSL speed connections, you'll probably find that compression > slows down your performance some (as it spends more time compressing the data > than it would sending it uncompressed) I thought so too and have tried compression off as well. Actually I notice that the 'Network Connection" status on the W2K client says Compression=no. It also shows Transmit Errors=0 Receive Errors=xx <- increments at a slow rate when connected. > > > Any suggestions are greatly appreciated as I have a bunch people who want > > access from warm comfy home, and if I give them access this way > > they will all moan about it being to slow :) > > I know. I have the same problem. Hmmm most of them currently use PCAnywhere via modem to come in, this could be a step up :) but I'd like to figure it out. > I've been meaning to try out an ssh-based VPN (ssh should be able to do this, > right?) but we've had much better success with a VPN based on vtun in the ports. > Unfortunately, you'll need a a FreeBSD or Linux machine at each end of the > connection, but vtund, with compression & encryption enabled was actually > faster than the raw connection in our performance tests. Agreed, vtund works very well and I wish I could give each programmer and Web Wizard a box but can't, some are road warriors too. > -- > Bill Moran > Potential Technologies > <a href="http://mail.canada.com/jump/http://www.potentialtech.com">http://www.potentialtech.com</a>; __________________________________________________________ Get your FREE personalized e-mail at http://www.canada.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?20030131092353.11107.h020.c009.wm>