On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@gmail.com> wrote:

More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems.

On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@gmail.com> wrote:

On Tue, Jun 12, 2012 at 9:58 AM, J. Roeleveld <joost@antarean.org> wrote:
On Mon, June 11, 2012 5:27 pm, Datty wrote:
> Hi all
>
> I'm looking for some help setting up traffic shaping on my internet
> connection. I have a bit of an odd setup in that I run a remote VPN server
> that all of my traffic is pushed through and out on to the internet. As I
> understand generally it isn't possible to shape incoming traffic but as I
> have control of the VPN server which pushes the traffic to me I wondered
> if
> it was possible to implement something on that side? No traffic other than
> the VPN tunnel goes out of my home connection.
>
> I'm trying to do this because I have a service running on one of my home
> machines that requires around 5kbps constantly with low latency (<200ms),
> but as my home connection is 750kbps it gets saturated very quickly
> causing
> huge spikes in latency. Does anyone have any ideas as to how I could
> achieve this? Generally any pointers at all would be greatly appreciated.

If VPN is the only traffic to/from your home, eg. using your internet
connection and you control the VPN-server on the other side, you could
limit the "upstream" of the remote server to your home.

> Thanks for your time
>
> Oliver
>


--
Joost


Thanks that makes total sense. I was looking at it backwards, not thinking that I could apply the same upstream limit to my VPN server.
A bit of background/my aims - The vpn interface is 100mbps, I want everybody but me on the VPN to be able to use up to that speed, but for traffic sent to 192.168.50.0/24 to be limited to 750kbps, with 700kbps of that for normal traffic and 50kbps for my tcp traffic from port 9999. 

Based on that do the following rules make sense? 

tc qdisc add dev tap0 root handle 1: htb default 12 -- Set the interface to be handle 1 and default traffic to be in class 1:12
tc class add dev tap0 parent 1: classid 1:1 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all classes overall
tc class add dev tap0 parent 1:1 classid 1:12 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all people on the vpn
tc class add dev tap0 parent 1:1 classid 1:15 htb rate 750kbps ceil 750kbps -- To be applied to all traffic from my home network
tc class add dev tap0 parent 1:15 classid 1:16 htb rate 700kbps ceil 700kbps -- To be applied to all traffic other than special on home network
tc class add dev tap0 parent 1:15 classid 1:17 htb rate 50kbps ceil 50kbps -- To be applied to special traffic on home network
tc qdisc add dev $modemif parent 1:15 handle 20: sfq perturb 10 -- I understand this to prevent high bandwidth traffic in a class from filling up the whole of the class bandwidth and allow fair sharing. Is this right/needed?
tc qdisc add dev $modemif parent 1:12 handle 20: sfq perturb 10 

iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.0/24 -p tcp --sport 9999 -j CLASSIFY --set-class 1:17
iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.4/24 -j CLASSIFY --set-class 1:16
iptables -t mangle -A POSTROUTING -o tap0 -j CLASSIFY --set-class 1:12


Thanks again for your help

Oliver

Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with?