On Fri, Feb 10, 2012 at 1:05 PM, Pandu Poluan <pa...@poluan.info> wrote: > > On Feb 11, 2012 12:42 AM, "Michael Mol" <mike...@gmail.com> wrote: >> >> 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. >> > > 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
