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.
JJK
*From:*Ryan Whelan [mailto: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
<mailto: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
