On Thu, Apr 28, 2016 at 11:14 AM, Jan Just Keijser <janj...@nikhef.nl>
wrote:
> On 28/04/16 16:26, j.witvl...@mindef.nl wrote:
>
> Putting a load-spreaders in front of a set of vpn-processes (or even
> vpn-servers) is obtainable with basic iptables/ip6tables rules.
>
> Simply statistic multiplexing over a number of destination
> ports/ip-addesses with nat.
>
> (it is actually one of the few valid reasons for using NAT on IPv6)
>
>
>
> However why would you want to involve the CN?
>
> All VPN-clients are equal, but some are more equal than others….
>
> True, but you would not get seamless failover - for that, you need keying
> material.
> And it's the "export keying material" patch that is needed to make that
> work.
>
Is there an interface planned to export this info from one instance and
import it into another? (management interface?) Or will it require a
custom plugin to access?
I will defiantly look into this, thank you much!
ryan
>
> JJK
>
>
>
> *From:* Ryan Whelan [mailto:rcwhe...@gmail.com <rcwhe...@gmail.com>]
> *Sent:* donderdag 28 april 2016 16:10
> *To:* Jan Just Keijser
> *Cc:* openvpn-users@lists.sourceforge.net
> *Subject:* Re: [Openvpn-users] Detecting client certificate CN during
> connection
>
>
>
>
>
>
>
> On Thu, Apr 28, 2016 at 3:10 AM, Jan Just Keijser <janj...@nikhef.nl>
> wrote:
>
> Hi,
>
> On 27/04/16 20:02, Ryan Whelan wrote:
>
> I may have a need to design a load balancer / demultiplexer that can route
> in-bound OpenVPN client connections to a specific server based on the
> clients certificate.
>
> If this is possible, the setup would be a LB of sorts in front of a farm
> of OpenVPN servers. This LB would look at the CN in the certificate of the
> inbound connection (UDP or TCP) and setup a route to the proper OpenVPN
> server based on which server that client is associated with.
>
> Is it possible to read the CN of a client without completing the entire
> connection? I figure I can setup an OpenVPN server as the router and via
> connection scripts, read the CN of connecting clients and build routing
> rules that way, but that would require the client to connect to the OpenVPN
> instance running on the 'router' before its traffic starts getting routed
> to the correct server at which point it will have to re-establish the
> connection to the new server. Is there a more elegant solution?
>
> I know its an unusual ask and I'm not expecting there to be a simple
> answer, but if possible, this could simply other parts of the project.
>
> interesting question :)
> the short answer is: no this is not possible. If this were possible, then
> SSL load balance vendors would already be using this.
>
> The longer answer is: the initial TLS handshake does not allow for this.
> When a client connects, a key exchange process is initiated to secure the
> connection. This process also involves exchanging public certificate info.
> If you want to 'route' (or redirect) the incoming TLS session to a
> different host then you'd also have to transfer all keying information. You
> might as well wait for the handshake to complete and *then* transfer the
> keying info. A patch for this has been submitted, BTW: in theory, such a
> patch would allow for a seamless transfer from one IP to another (e.g.
> behind a load balancer).
>
>
>
> With this patch, it would be possible complete the OpenVPN connection on a
> multiplexer/LB and then 'move' the connection to another host? Am I
> understanding that correctly?! That would work well for me if I'm not
> misunderstanding. If that is the case, which patch is it and how would
> this transfer be coordinated?
>
>
>
>
> To make the answer even longer: an OpenVPN TLS handshake is not the same
> as a webbrowser TLS handshake. In theory, we could extend the OpenVPN
> protocol to allow for such a 'redirect' but very special care would have to
> be taken to ensure security: you wouldn't want a rogue server to be able to
> intercept and redirect traffic transparantly. Another option might be to
> split control channel traffic and data channel traffic even more and
> redirect only the data channel traffic to another host. This would also
> require a change in the OpenVPN protocol, so don't bet on this before v2.5
> , if ever.
>
> HTH,
>
> JJK
>
>
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
>
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
