On Tue, Jun 12, 2012 at 4:43 PM, Datty <datty....@gmail.com> wrote: > > > On Tue, Jun 12, 2012 at 5:05 PM, Michael Mol <mike...@gmail.com> wrote: >> >> 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 > > > 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
