|
From: Chandrika S. <sch...@no...> - 2009-12-22 17:04:01
|
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 > > > |