[gentoo-user] Recommended VPN Tunnel client?

[gentoo-user] Recommended VPN Tunnel client?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

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,

[-- Attachment #2: Type: text/html, Size: 1080 bytes --]

[gentoo-user] Re: Recommended VPN Tunnel client?

[Pandu Poluan]

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

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

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2442 bytes --]

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

This keeps it at a lower level in the OSI model, which is less complicated and 
therefore easier to manage.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 3167 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4013 bytes --]

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Orlitzky]

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.

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

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,

[-- Attachment #2: Type: text/html, Size: 1966 bytes --]

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Mol]

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

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

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,

[-- Attachment #2: Type: text/html, Size: 3300 bytes --]

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Mol]

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

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Todd Goodman]

* Michael Mol <mikemol@gmail.com> [120210 12:51]:
[..]
> 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.

So obviously OpenVPN wasn't handling congestion appropriately and should
have been using some queueing discipline to discard instead of letting
transmit queues grow unbounded.

But switching to UDP from TCP just pushes the problem off your OpenVPN
gateway and onto the "outside" network.

If you're really receiving more traffic than can be sent over the
"outside" network, now you're relying on intermediate routers to "do the
right thing" with your excess UDP traffic and most likely impacting TCP
traffic through the same router.

Todd

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Mol]

On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman <tsg@bonedaddy.net> wrote:
> * Michael Mol <mikemol@gmail.com> [120210 12:51]:
> [..]
>> 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.
>
> So obviously OpenVPN wasn't handling congestion appropriately and should
> have been using some queueing discipline to discard instead of letting
> transmit queues grow unbounded.

Sure, that contributed to the problem, and may qualify as a bug. On
the flip side, by operating OpenVPN in TCP mode, you're saying you
want guaranteed delivery across the link.

>
> But switching to UDP from TCP just pushes the problem off your OpenVPN
> gateway and onto the "outside" network.
>
> If you're really receiving more traffic than can be sent over the
> "outside" network, now you're relying on intermediate routers to "do the
> right thing" with your excess UDP traffic and most likely impacting TCP
> traffic through the same router.

OpenVPN was running on the router on both ends. The sending side was
on the lean side of an ADSL modem, plugged directly into the same, so
the entire issue was handled locally.

Even if OpenVPN wasn't running on the router itself, there'd wouldn't
*be* excess UDP traffic when running OpenVPN in UDP mode, as
congestion management would be behaving properly. so other traffic
would not be unduly impacted.

-- 
:wq

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Todd Goodman]

* Michael Mol <mikemol@gmail.com> [120210 13:36]:
> On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman <tsg@bonedaddy.net> wrote:
> > * Michael Mol <mikemol@gmail.com> [120210 12:51]:
> > [..]
> >> 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.
> >
> > So obviously OpenVPN wasn't handling congestion appropriately and should
> > have been using some queueing discipline to discard instead of letting
> > transmit queues grow unbounded.
> 
> Sure, that contributed to the problem, and may qualify as a bug. On
> the flip side, by operating OpenVPN in TCP mode, you're saying you
> want guaranteed delivery across the link.

Yes, certainly.  And certainly TCP has far more resource requirements on the
sending side.  However, it also has congestion avoidance built in to it,
which UDP does not.

> 
> >
> > But switching to UDP from TCP just pushes the problem off your OpenVPN
> > gateway and onto the "outside" network.
> >
> > If you're really receiving more traffic than can be sent over the
> > "outside" network, now you're relying on intermediate routers to "do the
> > right thing" with your excess UDP traffic and most likely impacting TCP
> > traffic through the same router.
> 
> OpenVPN was running on the router on both ends. The sending side was
> on the lean side of an ADSL modem, plugged directly into the same, so
> the entire issue was handled locally.

There was no infrastructure between the two routers?  They had a direct
connection between them?  It would be slightly strange to go through the
hassle of running OpenVPN in that case...

> 
> Even if OpenVPN wasn't running on the router itself, there'd wouldn't
> *be* excess UDP traffic when running OpenVPN in UDP mode, as
> congestion management would be behaving properly. so other traffic
> would not be unduly impacted.

Why do you think congestion management would be behaving properly?  What
congestion management are you referring to for UDP traffic?

The only thing intermediate routers can do in the case of congestion due
to UDP traffic is to drop.  And depending on the queueing implementation
they may end up dropping TCP traffic as well.

Almost certainly they'll signal congestion to TCP endpoints with traffic
through them, hence impacting TCP traffic as well.

Todd

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Mol]

On Fri, Feb 10, 2012 at 2:21 PM, Todd Goodman <tsg@bonedaddy.net> wrote:
> * Michael Mol <mikemol@gmail.com> [120210 13:36]:
>> On Fri, Feb 10, 2012 at 1:22 PM, Todd Goodman <tsg@bonedaddy.net> wrote:
>> > * Michael Mol <mikemol@gmail.com> [120210 12:51]:
>> > [..]
>> >> 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.
>> >
>> > So obviously OpenVPN wasn't handling congestion appropriately and should
>> > have been using some queueing discipline to discard instead of letting
>> > transmit queues grow unbounded.
>>
>> Sure, that contributed to the problem, and may qualify as a bug. On
>> the flip side, by operating OpenVPN in TCP mode, you're saying you
>> want guaranteed delivery across the link.
>
> Yes, certainly.  And certainly TCP has far more resource requirements on the
> sending side.  However, it also has congestion avoidance built in to it,
> which UDP does not.

And that's perfectly fine, when you're going to be tunneling an entire
IP stack inside OpenVPN. If a tunneled application needs low latency,
low guarantee of delivery, it can use UDP. If a tunneled application
needs guarantee of delivery, it can use TCP. But if the OpenVPN tunnel
is itself using TCP, you lose low latency opportunities, and you deny
your tunneled applications' ability to respond to congestion.

>
>>
>> >
>> > But switching to UDP from TCP just pushes the problem off your OpenVPN
>> > gateway and onto the "outside" network.
>> >
>> > If you're really receiving more traffic than can be sent over the
>> > "outside" network, now you're relying on intermediate routers to "do the
>> > right thing" with your excess UDP traffic and most likely impacting TCP
>> > traffic through the same router.
>>
>> OpenVPN was running on the router on both ends. The sending side was
>> on the lean side of an ADSL modem, plugged directly into the same, so
>> the entire issue was handled locally.
>
> There was no infrastructure between the two routers?  They had a direct
> connection between them?  It would be slightly strange to go through the
> hassle of running OpenVPN in that case...

workstation - ovpn - ADSL 6Mbs/512Kbs - AT&T - ADSL(6Mbs/512Kbs) - ovpn - server

Both sides would be pushing up the weak end of ADSL, and both sides'
local routers would be discarding layer 3 packets that won't fit. AT&T
wouldn't even have seen the excess traffic.

>
>>
>> Even if OpenVPN wasn't running on the router itself, there'd wouldn't
>> *be* excess UDP traffic when running OpenVPN in UDP mode, as
>> congestion management would be behaving properly. so other traffic
>> would not be unduly impacted.
>
> Why do you think congestion management would be behaving properly?  What
> congestion management are you referring to for UDP traffic?

The fact that the tunneled TCP packets and fragments would be dropped,
causing the tunneled connections' relevant TCP stacks to scale back.

>
> The only thing intermediate routers can do in the case of congestion due
> to UDP traffic is to drop.  And depending on the queueing implementation
> they may end up dropping TCP traffic as well.

Which is *fine*, as long as the TCP packets are encapsulated inside
the tunnel, and the tunnel itself is UDP; the connection owners for
the encapsulated tunnels would scale back their throughput
automatically. If the TCP packet dropped is what's carrying the tunnel
itself, then one of the openvpn instances will resend, and the
encapsulated connection's packet will still ultimately reach its
destination.

>
> Almost certainly they'll signal congestion to TCP endpoints with traffic
> through them, hence impacting TCP traffic as well.

Not sure what you mean here.

Michael Orlitsky had a decent, relevant link:
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Though instead of stacking TCP/IP/PPP on top of SSH/TCP/IP, I was
packing IMAP/TCP/IP on top of OpenVPN/TCP/IP.

-- 
:wq

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Orlitzky]

On 02/10/12 13:05, Pandu Poluan wrote:
> 
> 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.
> 

I was about to say that we use it over UDP, but... we don't. We have a
small number of clients, maybe ten(?) that use the VPN for remote
administration.

UDP is recommended, references[1] are easy to google. Why we're running
it over TCP I don't know. I must have had a good reason =)

It performs fine anyway, but now I'm considering flipping it to UDP to
see what happens. At least I'll be in the office when it breaks.



[1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[Michael Orlitzky]

On 02/10/12 13:36, Michael Orlitzky wrote:
> 
> UDP is recommended, references[1] are easy to google. Why we're running
> it over TCP I don't know. I must have had a good reason =)

Ohhhhh my school blocks outgoing UDP. Running on TCP/443 allows me to
connect from their network.

Re: [gentoo-user] Re: Recommended VPN Tunnel client?

[wdk@moriah]

Congestion isn't the only reason to use TCP and a VPN.

3G smartphone network (Optus in Oz) has a large number of duplicate and dropped packets - openvpn performance over TCP is much better.  Similar case with a cheap French network while on holiday there.  This was an extreme case though with non VPN traffic very poor as well.

Otherwise use openvpn with fqdn's and not IP numbers then use ospf across them with suitable route metrics to either share or prefer a route.  Works well with dynamic IP's from my ISP so should be ok in your scenario.  You could also use openvpns route push if you dont need complex dynamic routing - this works better than ospf on bad links anyway.

BillK

On 11/02/2012, at 2:36, Michael Orlitzky <michael@orlitzky.com> wrote:

> On 02/10/12 13:05, Pandu Poluan wrote:
>> 
>> 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.
>> 
> 
> I was about to say that we use it over UDP, but... we don't. We have a
> small number of clients, maybe ten(?) that use the VPN for remote
> administration.
> 
> UDP is recommended, references[1] are easy to google. Why we're running
> it over TCP I don't know. I must have had a good reason =)
> 
> It performs fine anyway, but now I'm considering flipping it to UDP to
> see what happens. At least I'll be in the office when it breaks.
> 
> 
> 
> [1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
> 

Re: [gentoo-user] Recommended VPN Tunnel client?

[Michael Mol]

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