On 03/03/17 14:04, saato...@keemail.me wrote: > 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 > error (timestamps and IPs omitted/redacted): > > > 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 > TCP/UDP: Socket bind failed on local address [AF_INET][undef]:443: > Address already in use > Exiting due to fatal error > > > The server configuration looks as follows for the moment: > 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
