[Openvpn-users] Multiple connections from a single client to a single server

David Sommerseth

2017-03-03 14:38:25 UTC

Post by s***@keemail.me
Hi!
I'm working on a tool assessing my OpenVPN server and to speed up the
process I'm trying to establish multiple OpenVPN connections between a
single client and my OpenVPN server.
All established connections should share the configuration and client keys on the client.
Without any special adjustments or modification I get the following
OpenVPN 2.4.0 [git:master/f5bf296bacce76a8+] x86_64-pc-linux-gnu
[SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built
on Dec 29 2016
library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.08
TCP/UDP: Preserving recently used remote address: [AF_INET]
127.0.0.2:443
Address already in use
Exiting due to fatal error
server 172.16.0.0 255.255.255.0
port 443
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh4096.pem
tls-crypt /etc/openvpn/server/tls-crypt.key
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
cipher AES-256-CBC
auth SHA512
verb 3
comp-lzo
duplicate-cn
Is there any way to establish multiple connections from a single client to a single server?

Not within the same client configuration (single process connecting to
multiple servers or more times to the same server). But you can have
multiple OpenVPN client processes running against the same server. But
it is advisable to add --nobind to the client configurations.

And a side-track ...

Just a detail, I see you use --auth SHA512. I'd probably recommend you
it use SHA256 or SHA384, even though in HMAC context (which --auth is
all about) even SHA1 is safe. SHA512 doesn't give that much extra
security compared SHA256/SHA384, but it requires more CPU cycles of work.

Also, if all your clients are going to be v2.4 based, you can even move
up to --cipher AES-256-GCM (in this case --auth doesn't have any
effect, as GCM pulls in a different authentication scheme which can't be
changed). If you have a few 2.3 clients, you can add --ncp-cipher
AES-256-GCM:AES-256-CBC which allows those client configurations to use
--cipher AES-256-CBC.

One of my 2.4 servers have --cipher AES-256-CBC
--ncp-cipher AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC. There is
a variety of 2.3, 2.4 and git-master clients, which connects using
--cipher {AES-128-CBC, AES-256-CBC, AES-256-GCM}. The 2.4/git master
clients not having --cipher AES-256-GCM in the client configurations are
automatically upgraded to that.

And just to mention it. You will also find people saying that AES-128 is
mostly more than safe enough today as AES-256 isn't considered that much
stronger [1], but it adds more CPU cycles for the outcome. However, if
I have understood this correctly (I'm no cryptographer), if accounting
for a post-quantum world AES-256 increases the difficulty over AES-128.
But I do not know how this changes between the various
AES-*-{CBC,CFB,OFB} vs AES-*-GCM.

[1] <https://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html>

--
kind regards,

David Sommerseth