On Feb 10, 2012 10:08 PM, "Mick" <michaelkintz...@gmail.com> wrote: > > On Friday 10 Feb 2012 04:42:51 Pandu Poluan wrote: > > On Fri, Feb 10, 2012 at 10:48, Pandu Poluan <pa...@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 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,
