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

[Michael Mol <mikemol@gmail.com>]

On Fri, Feb 10, 2012 at 12:29 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Feb 11, 2012 12:16 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>>
>> On 02/10/12 11:46, Pandu Poluan wrote:
>> >
>> > On Feb 10, 2012 10:08 PM, "Mick" <michaelkintzios@gmail.com
>> > <mailto:michaelkintzios@gmail.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.

-- 
:wq