[EMAIL PROTECTED] 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.
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.
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.
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-----22.214.171.124 MPD/NATD 172.16.105.80------172.16.105.66 / 126.96.36.199 Redirected from 188.8.131.52
Tests using Penguinet SCP and a 1.9 MB ZIP file.
Baseline Download the file from the public IP's
184.108.40.206 -> client 180 kBs
220.127.116.11 -> 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.
The configs and a log.
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)
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.
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message