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