On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol <mike...@gmail.com> wrote: > On Tue, Jun 12, 2012 at 9:37 AM, Datty <datty....@gmail.com> wrote: >> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol <mike...@gmail.com> wrote: >>> On Jun 12, 2012 8:59 AM, "Datty" <datty....@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
