Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Mol]

On Fri, Feb 10, 2012 at 1:05 PM, Pandu Poluan <pandu@××××××.info> wrote:
>
> On Feb 11, 2012 12:42 AM, "Michael Mol" <mikemol@×××××.com> wrote:
>>
>> On Fri, Feb 10, 2012 at 12:29 PM, Pandu Poluan <pandu@××××××.info> wrote:
>> >
>> > On Feb 11, 2012 12:16 AM, "Michael Orlitzky" <michael@××××××××.com>
>> > wrote:
>> >>
>> >> On 02/10/12 11:46, Pandu Poluan wrote:
>> >> >
>> >> > On Feb 10, 2012 10:08 PM, "Mick" <michaelkintzios@×××××.com
>> >> > <mailto:michaelkintzios@×××××.com>> wrote:
>> >> >>
>> >> >> > >
>> >> >> > > The need: a VPN client that:
>> >> >> > > + can selectively send packets fulfilling a criteria (in this
>> >> > case, dest=
>> >> >> > > IP address of internal server)*
>> >> >>
>> >> >> As far as I know typical VPNs require the IP address (or FQDN) of
>> >> >> the
>> >> >> VPN
>> >> >> gateway.  If yours changes because ISP A goes down then the tunnel
>> >> > will fail
>> >> >> and be torn down.
>> >>
>> >> I must have missed the original message. OpenVPN can do this. Just
>> >> specify multiple "remote vpn.example.com" lines in your client configs,
>> >> one for each VPN server.
>> >>
>> >> It also handles updating the routing table for you. Rather than match
>> >> "IP address of internal server," it will match "IP address on internal
>> >> network" and route through the VPN automatically.
>> >>
>> >
>> > I'm still torn between OpenVPN and HAproxy. The former works with both
>> > TCP
>> > and UDP, while the latter is lighter and simpler but works with TCP
>> > only*.
>> >
>> > *The traffic will be pure TCP, but who knows I might need a UDP tunnel
>> > in
>> > the future.
>> >
>> > Any experience with either?
>> >
>> > Do note that I don't actually need a strong security (e.g. IPsec); I
>> > just
>> > need automatic failover *and* fallback.
>>
>> We're not using multiple internet connections to the same network
>> where I work, but we do use UDP-based OpenVPN to connect a few
>> networks.
>>
>> TCP OpenVPN connections are very, very bad, IMO. With a TCP VPN, you
>> easily break systems' TCP stacks' link bandwidth estimation. I once
>> had a 30s ping time, because the pipe was hogged and backlogged from a
>> mail client synchronizing.
>>
>
> No, no, no. What I meant was running TCP and UDP *on top of* OpenVPN (which
> uses UDP).
>
> HAproxy seems to be able to perform its magic with TCP connections.

That's what I was talking about. Where I work, we use OpenVPN,
operating in UDP mode. This is after several bad experiences using it
in TCP mode.

By "UDP mode" and "TCP mode", I mean OpenVPN's connections to other
OpenVPN nodes were in UDP or TCP, respectively. When OpenVPN's
connections operate over TCP (and thus it gets guarantee'd delivery),
you can create a situation where a tunneled TCP connection attempts to
push data faster than your Internet connection can allow because it
never gets any congestion feedback; OpenVPN was accepting packets
faster than it could shove them through, and was buffering the rest.

In the situation I encountered, I was syncing my email over the vpn,
but I couldn't quickly reach any internal services; their response
time got slower and slower until I bounced my openvpn daemon (breaking
any outstanding tunneled TCP connections), but then they rapidly
degraded again. Towards the end, I discovered I had a non-tunneled
ping time of <100 ms, but a tunneled ping time of 30m.

If HAProxy is smart about congestion management, you shouldn't see
this behavior. If not, you may.

-- 
:wq