Re: [Openvpn-users] Seamless openvpn tunnel failover

[Chandrika S. <sch...@no...>]

Ahaan :(
I assume you meant round robin for load balancing.How is that even close to what I was asking for?
 
Thanks Jan Just Keijser,
Chandrika

>>> Jan Just Keijser <ja...@ni...> 12/22/2009 5:08 PM >>>
Chandrika Sarath wrote:
> Ok.
> So is there a mechanism to transfer application connection states 
> across openvpn cluster nodes?
>  
What you're asking is not trivial :-)
There is no way to transfer connection states in openvpn itself; I'd set 
up a failover openvpn server and use something like round-robin/failover 
routing to make it appear "as one" : that way there is no need to 
transfer application connection states from one node to another.

cheers,

JJK

>
> >>> Jan Just Keijser <ja...@ni...> 12/22/2009 4:53 PM >>>
> Hi Chandrika,
>
> Chandrika Sarath wrote:
> > Thanks all.I completely agree with you.And I do not want to share the
> > session keys or server/client certificates across the cluster
> > nodes.Instead I would like to transfer only the application session
> > states.
> > 
> > In the following example:
> > 
> > 
> > FTP client
> >                        |               |                            |
> > Openvpn client  |<-------->|Openvpn server     |
> > ----------------   |               |----------------------|
> > IP layer            |               |
> > IP                        |---------FTP
> > Server                                             
> > ----------------   |               |----------------------|
> > TCP layer         |               | TCP                     |
> > ----------------   |               |--------------------- |
> > TUn:10.8.0.2    |               | tun:10.8.0.1         |
> > ----------------   |               |----------------------|
> > 
> > 
> > FTP client starts a connection and binds to the local IPaddress on a
> > local available port.The connection is taken forward(routed) to tun
> > device and then picked by openvpn client.Similar path is followed by
> > the encrypted packet that comes out of the client and reaches the 
> server.
> > Say there is another openvpn server in the corporate network.And a
> > failover happens.Obviously the tun/tap device at the client loses it
> > IPaddress and openvpn client also negotiates for new session keys and
> > gets the session authentications done with the failed over server.In
> > an ideal case this results in FTP failure.
> > So all I want to know is can this FTP failure be avoided?  I mean can
> > the FTP session state between the first openvpn server and the FTP
> > server be transferred to the second openvpn server without hassles?
> > Basically I do not want my FTP connection to break during/due to
> > re-negotiation.
> > I learned in one of the mailing lists that persist-tun would sustain
> > SIGUSR1 and keep the tun/tap device up.In this case can the
> > re-negotiation happen with the new server without disturbing the FTP
> > session.
> > 
> >
> as you can assure that
> - the client IP address stays the same (tricky but possible with 2
> openvpn servers)
> - the timeout on the FTP connection is not too short
> then the FTP connection from client to server should survive a
> dis+reconnect ; I've seen SSH sessions survive intermittent vpn timeouts
> (and/or wireless timeouts) so it should definitely be possible.
>
> HTH,
>
> JJK
>
> >
> > >>> David Sommerseth <ope...@to...> 12/21/2009 6:43
> > PM >>>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 21/12/09 11:50, Mahmoud Khonji wrote:
> > > On Mon, Dec 21, 2009 at 1:54 PM, Jan Just Keijser <ja...@ni...
> > > <mailto:ja...@ni...>> wrote:
> > >
> > >     David Sommerseth wrote:
> > >     > -----BEGIN PGP SIGNED MESSAGE-----
> > >     > Hash: SHA1
> > >     >
> > >     > On 20/12/09 18:18, Chandrika Sarath wrote:
> > >     >
> > >     >> Hi,
> > >     >>
> > >     >> I would like to know how can openvpn failover be made
> > seamless with
> > >     >> persist-key and persist-tun options in addition to use ucarp
> > >     functionality.
> > >     >> I am really not sure of how the options work.All I get to know
> > >     from the
> > >     >> docs is that the persist-key avoids re-reading the keys and
> > >     persist-tun
> > >     >> sustains SIGUSR1.Does this mean that if these options are used,
> > >     tunnel
> > >     >> re-negotiation does not happen when a failover occurs?
> > >     >>
> > >     >>
> > >     >
> > >     > It depends on what you really mean with seamless tunnel
> > failover.  If
> > >     > you mean that you for example can take down one of the 
> servers and
> > >     > clients connected to this one automatically is transferred 
> to the
> > >     other
> > >     > server without the clients noticing it at all, then I can
> > assure that
> > >     > this will not be possible.  This is due to how the SSL
> > protocol works,
> > >     > and there are no mechanism built in into OpenVPN which makes 
> such
> > >     > transitions possible at all.
> > >     >
> > >     just to add my $ 0.02 to that:
> > >     if somebody were to think up "seamless tunnel failover" I would
> > disable
> > >     it as soon as I can: there would be no difference between 
> "seamless
> > >     tunnel failover" and "server hijack takeover" . IMHO it is a
> > *feature*
> > >     that the connection goes down when the server goes down . If
> > this did
> > >     not happen I would not trust the security of the VPN software.
> > >
> > >     cheers,
> > >
> > >     JJK
> > >
> >
> > (please, don't top post - I've corrected it now)
> >
> > > The answer really depends. "seamless" - alone - doesn't 
> necessarily mean
> > > hijack. It depends how much security we put in such resource
> > > migration/fail-over.
> >
> > I lean towards agreeing with Jan Just Keijser.  Because the SSL/TLS
> > layer do negotiate a temporary encryption key per session, and even
> > replaces this key during the session.  For a seamless failover to
> > happen, this key must be transferred to the OpenVPN process taking over.
> > The same server certificate and server key must be used on all OpenVPN
> > instances.  Doing so is breaking some of the security layers in SSL/TLS.
> > Remember that the SSL/TLS protocol is not designed for 
> migration/failover.
> >
> > Also remember that security is not just about the encryption.  It is
> > also about to know that the server you talk to is really the server you
> > expect to talk with.  In addition, it is also to be sure that the data
> > being transmitted, in addition to being encrypted, it can ensure that
> > the data has not been modified while being transported over the wire.
> > To achieve all these things, the unique server certificate and
> > encryption keys are needed.
> >
> > By giving up some of these features, which will indirectly be given up
> > by spreading the keying material tp several servers, actually weakens
> > the whole SSL/TLS implementation, IMHO.
> >
> > > Although not implemented yet, however It's actually quite possible to
> > > have a proper seamless fail-over without modifying the TLS layer, or
> > > without being insecure. It would be a nice feature in addition to 
> other
> > > great features currently available in OpenVPN.
> > >
> > > OpenVPN, with it's use of TLS, doesn't impose security validations 
> on IP
> > > and TCP headers, which makes it pretty NAT friendly. IP/TCP address
> > > translations can happen without end-user notice. However, changes 
> within
> > > the TCP payload are not permitted by other parties (only legit 
> recipient
> > > could - hopefully)
> > >
> > > If ServerA went down, a load balancer (or whatever with same func),
> > > could do Destination NAT to ServerB (assuming it's alive). However,
> > > issue would arise at decrypting and encrypting data in addition to
> > > renegotiating future keys (As ServerB doesn't know generated keys nor
> > > the private key of ServerA).
> > >
> > > To solve the issue, and let ServerB handle the load seamlessly, all we
> > > need is a mechanism to exchange OpenVPN states across multiple servers
> > > (E.g. ServerA and ServerB). State would include things like (from the
> > > top of my head):
> > >
> > >     * Client IP address + common name + pword (in case of
> > interactive login)
> > >     * Client write MAC key.
> > >     * Client encrypt MAC key.
> > >     * Server write MAC key.
> > >     * Server write encrypt key.
> > >     * Server's private key (for renegotiation).
> > >
> > > I think that is pretty much close to what needs to be shared in 
> order to
> > > insure seamless fail-over.
> > >
> > > Exchanging the session data needs to be encrypted as well. We can 
> think
> > > of different ways to exchange this data, depending on levels of
> > > optimizations we want. It could be shared dynamically as encrypted 
> files
> > > over SSH/NFS/etc, a separate protocol that communicates securely
> > > (hopefully) directly to OpenVPN's process, or other mechanisms -- a
> > > decision that needs to be studied.
> >
> > First of all, you definitely do not want to transfer this keying
> > material as files, as that is beyond madness.  Imagine someone is
> > recording on-going openvpn connection traffic.  Then the person breaks
> > into the network somehow (could even be an unfaithful sysadmin), stops
> > the openvpn server by either killing the process, doing a kind of DoS
> > attack or whatever else - which triggers updating the state files as you
> > suggest.  The attacker can then pick up these files manually and start
> > bruteforcing them.  When those state files are cracked, the attacker can
> > then decrypt all the openvpn sessions which was open/active, including
> > data to/from *all* clients which was connected to that server at that
> > point.
> >
> > IMHO, this approach is completely insane.
> >
> > Using another safer transfer mechanism is also not as good, because you
> > cannot be sure that other openvpn process in such a cluster is
> > trustworthy.  Join in a new openvpn process to such a cluster, which
> > just reads out the keying material, and it can begin to decrypt traffic.
> > Imitating what kind of node connecting to a cluster is a fairly simple
> > task, in this regards.
> >
> > I might be able to agree to a /similar/ approach, *if* and *only if* you
> > run several openvpn processes on the *same box*, doing failover on that
> > box locally.  Then this exchange can happen locally via pipes directly
> > between openvpn processes, as all processes can have direct access to
> > the same keying material - as they are on the same box, share the same
> > disk and hardware memory modules.
> >
> > But I do not recommend doing so across a network to another server.
> > That is usually physically a different server (also if it is
> > virtualised, even though then it is more a "separate" logical server),
> > even if it is NATed.  When changing from one server to another, it is a
> > lot safer to renegotiate the keys and use separate keying material on
> > each server.  And it is mandatory to inform the clients what's going on.
> >
> > Why?  The client do not know why the server became unavailable.  That
> > could be due to an attack, which could compromise the agreed encryption
> > keys.  In this case, you want new keys and not to reuse the same keys
> > against a new server.  At least then it will not be easy to
> > follow/decrypt the continuation of the network traffic.
> >
> >
> > kind regards,
> >
> > David Sommerseth
> >
>