From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RvtdK-0004tk-B5 for garchives@archives.gentoo.org; Fri, 10 Feb 2012 16:47:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 718F5E064B; Fri, 10 Feb 2012 16:47:21 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 226DBE05EB for ; Fri, 10 Feb 2012 16:46:08 +0000 (UTC) Received: from mail-we0-f181.google.com ([74.125.82.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1Rvtbu-002xzI-Hn for gentoo-user@lists.gentoo.org; Fri, 10 Feb 2012 23:46:10 +0700 Received: by werp13 with SMTP id p13so2461634wer.40 for ; Fri, 10 Feb 2012 08:46:03 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.216.135.169 with SMTP id u41mr2668858wei.13.1328892363804; Fri, 10 Feb 2012 08:46:03 -0800 (PST) Received: by 10.223.103.4 with HTTP; Fri, 10 Feb 2012 08:46:03 -0800 (PST) Received: by 10.223.103.4 with HTTP; Fri, 10 Feb 2012 08:46:03 -0800 (PST) In-Reply-To: <201202101505.06700.michaelkintzios@gmail.com> References: <201202101505.06700.michaelkintzios@gmail.com> Date: Fri, 10 Feb 2012 23:46:03 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Recommended VPN Tunnel client? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0016e6de00d64a11a804b89edd8d X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: a3b23a14-7cf0-410f-8f9a-56fb62c31766 X-Archives-Hash: 73b2bc490116a38598dc915220a4b1bd --0016e6de00d64a11a804b89edd8d Content-Type: text/plain; charset=UTF-8 On Feb 10, 2012 10:08 PM, "Mick" wrote: > > On Friday 10 Feb 2012 04:42:51 Pandu Poluan wrote: > > On Fri, Feb 10, 2012 at 10:48, Pandu Poluan wrote: > > > Scenario: I have a server in the cloud that needs to connect to an > > > internal server in the office. There are 2 incoming connections into my > > > office, ISP "A" and ISP "B". The primary connection is A, but if A goes > > > down, we can use B. The app running on the cloud server has no automatic > > > failover ability (i.e., if A goes down, someone must change the app's > > > conf to point to B). > > > > > > My thought: If I can make a tunnel from the server to the FortiGate > > > firewall currently guarding the HQ, the cloud app can simply be > > > configured to connect to the internal IP address of the internal server. > > > No need to manually change the app's conf. > > > > > > 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. > > > > > + has automatic failover and failback ability > > Right, I don't know if one exists with this functionality - because this is > not a typical VPN function but one offered by load balancers/fall back servers > or routers. > > > > > *solutions involving iptables and iproute2 are also acceptable > > I am convinced that you can do that by clever enough routing on a linux box, > but cannot recall where I last read about it. > > > > > Can anyone point me to the right direction re: what package and the > > > relevant howto? > > > > > > Thanks in advance. > > > > I have been doing some research, and... > > > > Do you think I can do that using HAProxy running in tcp mode? > > > > My thought goes like this: Have the cloud app connect the IP:port of > > HAProxy, and let HAProxy perform a TCP proxy (NAT?) to connect to the > > internal server via A or B according to the "server checks". > > I haven't used HAProxy, but would consider setting up a fallback route at the > HQ router end. This is also called a failover configuration. The router > pings one address, say ISP A and if that fails more than x times over y pings > then it switches over the connection to ISP B. > HAproxy seems to be able to do that. It can check for A's status, and failover to B if A is down, but still keep checking for A to come up; and if A indeed comes back up, perform a failback to A. (I haven't actually tested this, just some informed guess based on its documentation) > This keeps it at a lower level in the OSI model, which is less complicated and > therefore easier to manage. HAproxy seems to work using double NAT technique (i.e., apps connect to HAproxy, and HAproxy connects to the actual destination) It's decidedly more complex than a route change, but according to its developer, more reliable (plus it employs some TCP tricks to optimize the connection) I'll post more info when I actually have done experience with it. Rgds, --0016e6de00d64a11a804b89edd8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 10, 2012 10:08 PM, "Mick" <michaelkintzios@gmail.com> wrote:
>
> On Friday 10 Feb 2012 04:42:51 Pandu Poluan wrote:
> > On Fri, Feb 10, 2012 at 10:48, Pandu Poluan <pandu@poluan.info> wrote:
> > > Scenario: I have a server in the cloud that needs to connect= to an
> > > internal server in the office. There are 2 incoming connecti= ons into my
> > > office, ISP "A" and ISP "B". The primary= connection is A, but if A goes
> > > down, we can use B. The app running on the cloud server has = no automatic
> > > failover ability (i.e., if A goes down, someone must change = the app's
> > > conf to point to B).
> > >
> > > My thought: If I can make a tunnel from the server to the Fo= rtiGate
> > > firewall currently guarding the HQ, the cloud app can simply= be
> > > configured to connect to the internal IP address of the inte= rnal server.
> > > No need to manually change the app's conf.
> > >
> > > The need: a VPN client that:
> > > + can selectively send packets fulfilling a criteria (in thi= s case, dest=3D
> > > IP address of internal server)*
>
> As far as I know typical VPNs require the IP address (or FQDN) of the = VPN
> gateway. =C2=A0If yours changes because ISP A goes down then the tunne= l will fail
> and be torn down.
>
>
> > > + has automatic failover and failback ability
>
> Right, I don't know if one exists with this functionality - becaus= e this is
> not a typical VPN function but one offered by load balancers/fall back= servers
> or routers.
>
>
> > > *solutions involving iptables and iproute2 are also acceptab= le
>
> I am convinced that you can do that by clever enough routing on a linu= x box,
> but cannot recall where I last read about it.
>
>
> > > Can anyone point me to the right direction re: what package = and the
> > > relevant howto?
> > >
> > > Thanks in advance.
> >
> > I have been doing some research, and...
> >
> > Do you think I can do that using HAProxy running in tcp mode?
> >
> > My thought goes like this: Have the cloud app connect the IP:port= of
> > HAProxy, and let HAProxy perform a TCP proxy (NAT?) to connect to= the
> > internal server via A or B according to the "server checks&q= uot;.
>
> I haven't used HAProxy, but would consider setting up a fallback r= oute at the
> HQ router end. =C2=A0This is also called a failover configuration. =C2= =A0The router
> pings one address, say ISP A and if that fails more than x times over = y pings
> then it switches over the connection to ISP B.
>

HAproxy seems to be able to do that. It can check for A's status, an= d failover to B if A is down, but still keep checking for A to come up; and= if A indeed comes back up, perform a failback to A.

(I haven't actually tested this, just some informed guess based on i= ts documentation)

> This keeps it at a lower level in the OSI model, which is less comp= licated and
> therefore easier to manage.

HAproxy seems to work using double NAT technique (i.e., apps connect to = HAproxy, and HAproxy connects to the actual destination)

It's decidedly more complex than a route change, but according to it= s developer, more reliable (plus it employs some TCP tricks to optimize the= connection)

I'll post more info when I actually have done experience with it.

Rgds,

--0016e6de00d64a11a804b89edd8d--