1 |
On Tue, Jun 12, 2012 at 5:05 PM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
|
3 |
> On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol <mikemol@×××××.com> wrote: |
4 |
> > On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty.wtb@×××××.com> wrote: |
5 |
> >> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@×××××.com> wrote: |
6 |
> >>> On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@×××××.com> wrote: |
7 |
> > |
8 |
> > [snip] |
9 |
> > |
10 |
> >>> More detail later...but make sure your vpn link is not TCP. UDP, fine, |
11 |
> >>> IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly |
12 |
> >>> traffic problems. |
13 |
> > |
14 |
> >> Ah it is TCP at the moment. Not something I could change too easily |
15 |
> either. |
16 |
> >> Is it possible to work around or is it not worth fighting with? |
17 |
> > |
18 |
> > If all of these cases are true: |
19 |
> > |
20 |
> > * You only have TCP traffic going over that VPN |
21 |
> > * You don't have any latency-sensitive traffic going over that VPN (no |
22 |
> > VOIP, no interactive terminal sessions and you won't pull your hair |
23 |
> > out over 10s or more round-trips slowing down page loads) |
24 |
> > * You don't have large bulk data transfers going over that VPN (my |
25 |
> > best example of personal experience here was trying to locally sync my |
26 |
> > work-related IMAP mailbox) |
27 |
> > |
28 |
> > ...then it's not worth fighting with. |
29 |
> |
30 |
> I could stand to be more precise and concise: |
31 |
> If you're going to use a TCP transport for VPN: |
32 |
> * You need to not mix TCP and UDP traffic |
33 |
> * You need to not have latency-sensitive traffic. |
34 |
> |
35 |
> In practice, you'll almost always have some UDP traffic; that's how |
36 |
> DNS generally operates. And even where DNS uses TCP, it's still |
37 |
> latency-sensitive. |
38 |
> |
39 |
> So I can be even more concise: |
40 |
> If you're going to use a TCP transport for VPN, you must avoid having |
41 |
> TCP traffic over that VPN link. |
42 |
> |
43 |
> -- |
44 |
> :wq |
45 |
> |
46 |
|
47 |
Thank you for that very thorough explanation, I had no idea there was a |
48 |
problem with using TCP, I figured the error correction would help it be |
49 |
more stable than just throwing data at it and hoping it got there. Somehow |
50 |
I've avoided the majority of the issues you've mentioned up to now, but |
51 |
then again generally my connection is very slow so maybe I'm just not |
52 |
feeling the effects. My ping however is around 40ms higher over the VPN |
53 |
link so I'm guessing that may be a sign. |
54 |
|
55 |
I'll set up a second vpn tunnel using UDP to test it out, my resistance to |
56 |
changing the main one is purely down to the fact that I have around 30 |
57 |
clients, probably half of which would reach for antiseptic if I mentioned |
58 |
TCP and I don't fancy having to drive 200+ miles to each of them to change |
59 |
it for them. |
60 |
|
61 |
I'll give it a shot tomorrow and report back on how it gets on. Regarding |
62 |
the tc rules I mentioned, do they look alright? I'm not 100% on how it all |
63 |
goes together still and would appreciate a prod in the right direction. |
64 |
|
65 |
Thanks again |
66 |
|
67 |
Oliver |