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