FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 02-10-2012, 02:48 AM
Pandu Poluan
 
Default Recommended VPN Tunnel client?

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)*

+ has automatic failover and failback ability


*solutions involving iptables and iproute2 are also acceptable


Can anyone point me to the right direction re: what package and the relevant howto?


Thanks in advance.


Rgds,
 
Old 02-10-2012, 03:42 AM
Pandu Poluan
 
Default Recommended VPN Tunnel client?

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 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)*
> + has automatic failover and failback ability
>
> *solutions involving iptables and iproute2 are also acceptable
>
> 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 IPort 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".

Rgds,
--
FdS Pandu E Poluan
~ IT Optimizer ~

*• LOPSA Member #15248
*• Blog : http://pepoluan.tumblr.com
*• Linked-In : http://id.linkedin.com/in/pepoluan
 
Old 02-10-2012, 02:04 PM
Mick
 
Default Recommended VPN Tunnel client?

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 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 IPort 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.

This keeps it at a lower level in the OSI model, which is less complicated and
therefore easier to manage.
--
Regards,
Mick
 
Old 02-10-2012, 02:12 PM
Michael Mol
 
Default Recommended VPN Tunnel client?

On Thu, Feb 9, 2012 at 10:48 PM, 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 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)*
> + has automatic failover and failback ability
>
> *solutions involving iptables and iproute2 are also acceptable
>
> Can anyone point me to the right direction re: what package and the relevant
> howto?
>
> Thanks in advance.
>
> Rgds,

Not exactly what you're looking for, but this might help:

http://www.ntop.org/products/n2n/

That would set up reliable visibility on layer 2. You probably want to
employ something like 802.1x on top of it.
--
:wq
 
Old 02-10-2012, 03:46 PM
Pandu Poluan
 
Default Recommended VPN Tunnel client?

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 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 IPort 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,
 
Old 02-10-2012, 04:13 PM
Michael Orlitzky
 
Default Recommended VPN Tunnel client?

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.
 
Old 02-10-2012, 04:29 PM
Pandu Poluan
 
Default Recommended VPN Tunnel client?

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.


Rgds,
 
Old 02-10-2012, 04:40 PM
Michael Mol
 
Default Recommended VPN Tunnel client?

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
 
Old 02-10-2012, 05:05 PM
Pandu Poluan
 
Default Recommended VPN Tunnel client?

On Feb 11, 2012 12:42 AM, "Michael Mol" <mikemol@gmail.com> wrote:

>

> 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.

>


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.


Rgds,
 
Old 02-10-2012, 05:20 PM
Michael Mol
 
Default Recommended VPN Tunnel client?

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

Thread Tools




All times are GMT. The time now is 05:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org