[gentoo-user] Traffic shaping - downstream data

[gentoo-user] Traffic shaping - downstream data

[Datty]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

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.

Thanks for your time

Oliver

[-- Attachment #2: Type: text/html, Size: 1018 bytes --]

Re: [gentoo-user] Traffic shaping - downstream data

[J. Roeleveld]

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

Re: [gentoo-user] Traffic shaping - downstream data

[Datty]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4096 bytes --]

Re: [gentoo-user] Traffic shaping - downstream data

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 3529 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4620 bytes --]

Re: [gentoo-user] Traffic shaping - downstream data

[Datty]

[-- Attachment #1: Type: text/plain, Size: 3841 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 5178 bytes --]

Re: [gentoo-user] Traffic shaping - downstream data

[Michael Mol]

On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty.wtb@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@gmail.com> wrote:

[snip]

>> 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.

> 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?

If all of these cases are true:

* You only have TCP traffic going over that VPN
* You don't have any latency-sensitive traffic going over that VPN (no
VOIP, no interactive terminal sessions and you won't pull your hair
out over 10s or more round-trips slowing down page loads)
* You don't have large bulk data transfers going over that VPN (my
best example of personal experience here was trying to locally sync my
work-related IMAP mailbox)

...then it's not worth fighting with.

It's very unlikely you fall in that camp.

The problem of TCP VPN transport is a confluence of three issues:

1) You're likely to have packet loss underneath that transport due to
things like congestion...the TCP transport will hide this from
tunneled traffic and retransmit itself.
2) In TCP, Nagle's Algorithm handles flow throttling, but it depends
on detecting packet loss to limit how many packets it pushes.
3) Your VPN endpoint will very probably buffer a very large amount of
data for sending if its TCP transport link is acting slow.

Here's what happens:

1) Your TCP app on your computer opens a connection with a remote
host. This connection is encapsulated inside your TCP OpenVPN tunnel.
2) Your app's TCP connection starts exchanging data. For as long as
it's not losing any packets, it figures it can send more and more data
without waiting for a response; this is Nagle's Algorithm managing
your TCP sliding window, and it's why TCP can scale from dial-up
speeds up to 10g ethernet.
3) Your VPN link's TCP connection experiences packet loss. Maybe it's
because of a congested router between you and the remote side of the
VPN, or maybe it's because someone's ADSL connection is pushing more
than its measly 768Kb/s upstream speed allows for. Or maybe it's noise
on the copper causing packet loss on the ADSL link. Or maybe it's a
frame collision on the PPoE link.

...time passes...

4) Your VPN link's TCP stack notes the packet loss and retransmits the
lost packet until the packet gets through.
5) The connection traffic from step (2) is completely unaware that the
VPN's TCP connection is fielding packet loss issues for it, and
Nagle's Algorithm figures, 'hey, this is a high-bandwith link! Let's
shove more data!'
6) OpenVPN link is now receving data it can't stuff into the pipe
right this second, so it buffers it for a moment, and then sends it
when its turn has come. Still, no data is lost.

...time passes...

7) Steps 4-6 repeat themselves, causing your original connection to
become more and more confident about the bandwidth of the pipe.

...time passes...

8) The connection from step 2 is now so confident of the connection
speed of the pipe, it's pushing data to OpenVPN faster than OpenVPN
could conceivably push out, even if there were no packet loss issues.
You've now got a cycle of just steps 5 and 6.

Presumably, you'd eventually hit OpenVPN's buffer limit. I don't know
what that is, and I don't think it's tuneable. The one time I
personally saw, measured and helped diagnose this, I was getting up to
a *fifteen minute* round-trip ping time over the VPN, even though the
round-trip time for ping outside the VPN between the VPN endpoints was
only about 100ms. Watching that round-trip time climb was surreal
until I figured out what was happening.

Switching the VPN transport to UDP allowed the tunneled connections'
TCP stacks to properly gauge and react to available throughput. Even
SIP started working over that VPN link.

-- 
:wq

Re: [gentoo-user] Traffic shaping - downstream data

[Michael Mol]

On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty.wtb@gmail.com> wrote:
>> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@gmail.com> wrote:
>
> [snip]
>
>>> 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.
>
>> 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?
>
> If all of these cases are true:
>
> * You only have TCP traffic going over that VPN
> * You don't have any latency-sensitive traffic going over that VPN (no
> VOIP, no interactive terminal sessions and you won't pull your hair
> out over 10s or more round-trips slowing down page loads)
> * You don't have large bulk data transfers going over that VPN (my
> best example of personal experience here was trying to locally sync my
> work-related IMAP mailbox)
>
> ...then it's not worth fighting with.

I could stand to be more precise and concise:
If you're going to use a TCP transport for VPN:
* You need to not mix TCP and UDP traffic
* You need to not have latency-sensitive traffic.

In practice, you'll almost always have some UDP traffic; that's how
DNS generally operates. And even where DNS uses TCP, it's still
latency-sensitive.

So I can be even more concise:
If you're going to use a TCP transport for VPN, you must avoid having
TCP traffic over that VPN link.

-- 
:wq

Re: [gentoo-user] Traffic shaping - downstream data

[Datty]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

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

> On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol <mikemol@gmail.com> wrote:
> > On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty.wtb@gmail.com> wrote:
> >> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@gmail.com> wrote:
> >>> On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@gmail.com> wrote:
> >
> > [snip]
> >
> >>> 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.
> >
> >> 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?
> >
> > If all of these cases are true:
> >
> > * You only have TCP traffic going over that VPN
> > * You don't have any latency-sensitive traffic going over that VPN (no
> > VOIP, no interactive terminal sessions and you won't pull your hair
> > out over 10s or more round-trips slowing down page loads)
> > * You don't have large bulk data transfers going over that VPN (my
> > best example of personal experience here was trying to locally sync my
> > work-related IMAP mailbox)
> >
> > ...then it's not worth fighting with.
>
> I could stand to be more precise and concise:
> If you're going to use a TCP transport for VPN:
> * You need to not mix TCP and UDP traffic
> * You need to not have latency-sensitive traffic.
>
> In practice, you'll almost always have some UDP traffic; that's how
> DNS generally operates. And even where DNS uses TCP, it's still
> latency-sensitive.
>
> So I can be even more concise:
> If you're going to use a TCP transport for VPN, you must avoid having
> TCP traffic over that VPN link.
>
> --
> :wq
>

Thank you for that very thorough explanation, I had no idea there was a
problem with using TCP, I figured the error correction would help it be
more stable than just throwing data at it and hoping it got there. Somehow
I've avoided the majority of the issues you've mentioned up to now, but
then again generally my connection is very slow so maybe I'm just not
feeling the effects. My ping however is around 40ms higher over the VPN
link so I'm guessing that may be a sign.

I'll set up a second vpn tunnel using UDP to test it out, my resistance to
changing the main one is purely down to the fact that I have around 30
clients, probably half of which would reach for antiseptic if I mentioned
TCP and I don't fancy having to drive 200+ miles to each of them to change
it for them.

I'll give it a shot tomorrow and report back on how it gets on. Regarding
the tc rules I mentioned, do they look alright? I'm not 100% on how it all
goes together still and would appreciate a prod in the right direction.

Thanks again

Oliver

[-- Attachment #2: Type: text/html, Size: 3730 bytes --]

Re: [gentoo-user] Traffic shaping - downstream data

[Michael Mol]

On Tue, Jun 12, 2012 at 4:43 PM, Datty <datty.wtb@gmail.com> wrote:
>
>
> On Tue, Jun 12, 2012 at 5:05 PM, Michael Mol <mikemol@gmail.com> wrote:
>>
>> On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol <mikemol@gmail.com> wrote:
>> > On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty.wtb@gmail.com> wrote:
>> >> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@gmail.com> wrote:
>> >>> On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@gmail.com> wrote:
>> >
>> > [snip]
>> >
>> >>> 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.
>> >
>> >> 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?
>> >
>> > If all of these cases are true:
>> >
>> > * You only have TCP traffic going over that VPN
>> > * You don't have any latency-sensitive traffic going over that VPN (no
>> > VOIP, no interactive terminal sessions and you won't pull your hair
>> > out over 10s or more round-trips slowing down page loads)
>> > * You don't have large bulk data transfers going over that VPN (my
>> > best example of personal experience here was trying to locally sync my
>> > work-related IMAP mailbox)
>> >
>> > ...then it's not worth fighting with.
>>
>> I could stand to be more precise and concise:
>> If you're going to use a TCP transport for VPN:
>> * You need to not mix TCP and UDP traffic
>> * You need to not have latency-sensitive traffic.
>>
>> In practice, you'll almost always have some UDP traffic; that's how
>> DNS generally operates. And even where DNS uses TCP, it's still
>> latency-sensitive.
>>
>> So I can be even more concise:
>> If you're going to use a TCP transport for VPN, you must avoid having
>> TCP traffic over that VPN link.
>>
>> --
>> :wq
>
>
> Thank you for that very thorough explanation, I had no idea there was a
> problem with using TCP, I figured the error correction would help it be more
> stable than just throwing data at it and hoping it got there. Somehow I've
> avoided the majority of the issues you've mentioned up to now, but then
> again generally my connection is very slow so maybe I'm just not feeling the
> effects. My ping however is around 40ms higher over the VPN link so I'm
> guessing that may be a sign.
>
> I'll set up a second vpn tunnel using UDP to test it out, my resistance to
> changing the main one is purely down to the fact that I have around 30
> clients, probably half of which would reach for antiseptic if I mentioned
> TCP and I don't fancy having to drive 200+ miles to each of them to change
> it for them.
>
> I'll give it a shot tomorrow and report back on how it gets on. Regarding
> the tc rules I mentioned, do they look alright? I'm not 100% on how it all
> goes together still and would appreciate a prod in the right direction.
>
> Thanks again

I'd suggest setting up that second VPN link for parallel use, get all
the clients up on that one (can you remote admin?), and then take down
the old one once the TCP link is no longer actively used. You should
be able to do it pretty seamlessly.

Regarding the tc rules...no idea off the top of my head. I think when
I first saw them I had more questions about topology, but I don't have
time to grok it again today.


-- 
:wq