1 |
On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty.wtb@×××××.com> wrote: |
3 |
>> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mikemol@×××××.com> wrote: |
4 |
>>> On Jun 12, 2012 8:59 AM, "Datty" <datty.wtb@×××××.com> wrote: |
5 |
> |
6 |
> [snip] |
7 |
> |
8 |
>>> More detail later...but make sure your vpn link is not TCP. UDP, fine, |
9 |
>>> IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly |
10 |
>>> traffic problems. |
11 |
> |
12 |
>> Ah it is TCP at the moment. Not something I could change too easily either. |
13 |
>> Is it possible to work around or is it not worth fighting with? |
14 |
> |
15 |
> If all of these cases are true: |
16 |
> |
17 |
> * You only have TCP traffic going over that VPN |
18 |
> * You don't have any latency-sensitive traffic going over that VPN (no |
19 |
> VOIP, no interactive terminal sessions and you won't pull your hair |
20 |
> out over 10s or more round-trips slowing down page loads) |
21 |
> * You don't have large bulk data transfers going over that VPN (my |
22 |
> best example of personal experience here was trying to locally sync my |
23 |
> work-related IMAP mailbox) |
24 |
> |
25 |
> ...then it's not worth fighting with. |
26 |
|
27 |
I could stand to be more precise and concise: |
28 |
If you're going to use a TCP transport for VPN: |
29 |
* You need to not mix TCP and UDP traffic |
30 |
* You need to not have latency-sensitive traffic. |
31 |
|
32 |
In practice, you'll almost always have some UDP traffic; that's how |
33 |
DNS generally operates. And even where DNS uses TCP, it's still |
34 |
latency-sensitive. |
35 |
|
36 |
So I can be even more concise: |
37 |
If you're going to use a TCP transport for VPN, you must avoid having |
38 |
TCP traffic over that VPN link. |
39 |
|
40 |
-- |
41 |
:wq |