OpenVPN Support Forum

There are many uses in which a openvpn server needs to be able to limit outgoing bandwidth. The most common is a server on an asynchronous internet connection (DSL/cable) When the --server flag is set, the --shaper option cannot be set. It would be nice if the --shaper option could be set even when acting as a server.

Thanks,
Jonathan Bennett

There is a good reason why --shaper is not supported on the server end.
How should --shaper work on the server? Set this limit for each connection? Or for all connections as a whole?

If you want to throttle the download speed of the clients you're better off to use something like 'tc' on Linux. Other solutions exist for other platforms.

On FreeBSD, pf with ALTQ is a good way to shape traffic.

Thanks for the replies.

Just a note on my specific issue:
I'm forced to use a tcp connection for the VPN (Going through an http proxy). When transferring a large file via scp, I get these errors: "MULTI: packet dropped due to output saturation (multi_process_incoming_tun)" Shortly thereafter, the scp transfer dies, but the vpn normally stays up. My theory is that the tcp outout buffer fills up, and when that starts dropping packets, it kills scp.

I know that I can use tc, and have had it set up in the past. Since I'm sending tcp over a tcp tunnel, the openvpn tcp output buffer fills up without the application being notified to slow its rate of sending data. As I understand it, a tcp connection uses dropped packets to gauge available bandwidth. Using tc limits the tunnel from the outside: It's the same as having a slower upload speed on my connection. This would just cause the buffer to fill faster. I think the shaper option would remedy this problem.

I would think that the --shaper option would restrict traffic as a whole. Perhaps a per client config could be added, as well.

Cheers,
Jonathan Bennett

I have successfully implemented tc shaping on my OpenVPN server. I use a variation of a script found on the internet:

http://www.topwebhosts.org/tools/traffic-control.php

I'm not sure what, if anything, --shaping does

Update:

tc renders openvpn unusable. Bummer. This is with htb, haven't used the other shaping qdisc algorithms.

OpenVPN is pretty slow to begin with. Anything you do to the tunnel subtracts speed. There are papers on this available on the web.

Then if you add shaping, I think the interaction between the shaping algorithms and the context switching of OpenVPN kills the speed. Latency was reported as high as 3000ms!

I have to admit I don't really understand why this is. We have a server with four processors barely registering use, RAM that's not full, a 1Gbps NIC, and a 2.5Gbps system bus.

Project for the OpenVPN community: optimize the program for speed. It's great that you don't need to recompile the kernel to install OpenVPN--I "get" that, but there's a huge price to be paid in terms of speed.

This must be the reason why OpenVPN didn't take over the world, and why PPTP is still the built-in VPN protocol in Windows 7.

hostizzle wrote: This must be the reason why OpenVPN didn't take over the world, and why PPTP is still the built-in VPN protocol in Windows 7.

oh so microsoft cares about the quality that much? is that why they still ship with pptp, a known faulty protocol...?
i figured it was because they made pptp... and by the way they would NEVER ship with openvpn, it is GPL which would require them to ship the source code (same reason you wouldnt see apple shipping with it)

As always M$ builds their products with security in mind...

PPtP is one of them




michael.

This must be the reason why OpenVPN didn't take over the world, and why PPTP is still the built-in VPN protocol in Windows 7.

Now that.. is a funny one.

hostizzle wrote:Update:

tc renders openvpn unusable. Bummer. This is with htb, haven't used the other shaping qdisc algorithms.

OpenVPN is pretty slow to begin with. Anything you do to the tunnel subtracts speed. There are papers on this available on the web.

Then if you add shaping, I think the interaction between the shaping algorithms and the context switching of OpenVPN kills the speed. Latency was reported as high as 3000ms!

I have to admit I don't really understand why this is. We have a server with four processors barely registering use, RAM that's not full, a 1Gbps NIC, and a 2.5Gbps system bus.

Project for the OpenVPN community: optimize the program for speed. It's great that you don't need to recompile the kernel to install OpenVPN--I "get" that, but there's a huge price to be paid in terms of speed.

This must be the reason why OpenVPN didn't take over the world, and why PPTP is still the built-in VPN protocol in Windows 7.

So have you successfully limited your clients download speed? From your post it seems like it will actually make the connection unusable. I tried tc but can't get it to work. I also tried squid and iptables to limit the download speed but that makes the download speed also unusable.

guys. tell please

how shape outgoing traffic for each client openvpn

prefer easy method