local 10.0.0.2 #ip/hostname of server
port 1194 #default open port
dev tap0 #If you need multiple tap devices, add them here
up "/etc/openvpn/up.sh br0 tap0 1500"
down "/etc/openvpn/down.sh br0 tap0"
#certificates and encryption
key /etc/openvpn/keys/server.key #this file is secret
#tls-auth /etc/openvpn/ta.key #this file is secret
cipher BF-CBC #Blowfish (default)
server-bridge 10.0.0.2 255.255.255.0 10.0.0.100 10.0.0.110
push "dhcp-option DNS 10.0.0.1"
#push "dhcp-option DOMAIN yourdomain.com"
max-clients 10 #set this to the max number of clients to be connected at a time
#log and security
keepalive 10 120
Do I have the maximum security?
Can I increase the secrity level to an even higher one?
Is AES-256-CBC more secure than BF-CBC? Or is it just another way of encryption?
Larger keys, yep, seems senseful. Will it slow down the connection?
I tried myself on the tls-auth directive, though was not successfull. What I did, was copying the key to both sides client and server and then setting the directive on it, but the connection would not be estabilished. I did not quite understand why. How do I setup the tls-auth?
Ok, thanks for your reply and for all these advices.
I tried to change BF-CBC to AES-256-CBC by replacing the new keyword on the client side (client.conf) and the server side (server.conf).
After reboot of both machines the connection couldn't be estabilished anymore.
I believe further steps are necessary.
What do I have to do to change the encryption from BF-CBC to AES-256-CBC?
The CAMELLIA-xxx-CBC (European and Japanese standard) cipher would be roughly equivalent to the AES-xxx-CBC (United States standard) cipher. Both of these are currently secure at all three key sizes, and are slightly to massively better than any of the alternatives even in OpenVPN 2.3.0.
For authentication, SHA512, the largest SHA2 digest, is definitely the most secure choice. The U.S. NIST has recently chosen Keccak as SHA3, also available in 256, 384, and 512 bit versions, but has announced that SHA2 is still deemed secure - they will both be in use for the forseeable future, side by side. I am not aware of EU or Japanese hash standards, regrettably.
For tls-cipher, 2.2.x doesn't have any of the really modern ciphers (note that it's SHA1, not SHA256, SHA384, or SHA512), but DHE-RSA-AES256-SHA seems to be the best choice based on OpenVPN/OpenSSL recommendation.
With 2.3.0, I'm trying to figure out precisely what RSA-SHA512 does as a digest vs. plain SHA512 (and what the RSA parameters are), and I'd really like to get the TLS cipher suite ECDHE-RSA-AES256-GCM-SHA384 working, as Galois Counter Mode, a SHA2 hash, and elliptical curve cryptography are all significant improvements.
Regrettably, with the Windows 2.3.0 I004 binary install, the elliptical curve modes appear to simply error out when I try them as drop-in replacements.
At this time, I do not know how to have OpenVPN require multiple modes of authentication at once, i.e. require a certificate, and one or more a TOTP tokens, perhaps even and a username/password. Username/password by itself is an incredibly poor choice; TOTP token plus something else is going to be better than that something else by itself.
Hi, my dd-wrt has openvpn server, I have the option of doing AES-512-CBC cipher but OpenVPN client does not recognize it. Are there any future plans of updating this? Or is this something I missed and need to update my client?
19:58:10 $ openvpn --version
OpenVPN 2.3.4 i686-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on May 3 2014
library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <email@example.com>
Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no
19:59:09 $ openvpn --show-ciphers
The following ciphers and cipher modes are available
for use with OpenVPN. Each cipher shown below may be
used as a parameter to the --cipher option. The default
key size is shown as well as whether or not it can be
changed with the --keysize directive. Using a CBC mode
DES-CBC 64 bit default key (fixed)
IDEA-CBC 128 bit default key (fixed)
RC2-CBC 128 bit default key (variable)
DES-EDE-CBC 128 bit default key (fixed)
DES-EDE3-CBC 192 bit default key (fixed)
DESX-CBC 192 bit default key (fixed)
BF-CBC 128 bit default key (variable)
RC2-40-CBC 40 bit default key (variable)
CAST5-CBC 128 bit default key (variable)
RC2-64-CBC 64 bit default key (variable)
AES-128-CBC 128 bit default key (fixed)
AES-192-CBC 192 bit default key (fixed)
AES-256-CBC 256 bit default key (fixed)
CAMELLIA-128-CBC 128 bit default key (fixed)
CAMELLIA-192-CBC 192 bit default key (fixed)
CAMELLIA-256-CBC 256 bit default key (fixed)
SEED-CBC 128 bit default key (fixed)
It is possible that the implementation of OpenVPN on your router offers --cipher AES-512-CBC as an extra option but you will need a router with support for AES-512-CBC as a client .. not true OpenVPN.
The Rijdael cipher comes in 128, 160, 192, 224, and 256-bit variants,
officially there is not 512bit variant by its original authors...
one of the 512bit variants is Moh'd, A., Jararweh, Y., & Tawalbeh, L. (2011) AES-512: 512-bit Advanced Encryption Standard algorithm design and evaluation. Information Assurance and Security (IAS),
2011 7th International Conference on. pp. 292 - 297. DOI 10.1109/ISIAS.2011.6122835
keep in mind though that these 512bit variants have not under gone the same deep analysis as the derivative of Rijndael that became AES.
my personal opinion is that for now AES-256 is enough....
This is a long running topic with lot's of usefull information. And since the release of 2.4.0 we had some awesome new features.
As i'm constantly trying to improve security in my vpn-configs, i'm trying to wrap-up my ideas over here. Any comment would be very helpfull!
As thoroughly explained in the security-overview, we need to take care of 2 different security-issues:
The first is handled with a TLS-handshake, takes care of the authentication of both client and server and the exchange of keys for the data-channel. So it's very important to have a reliable crypto-channel here with Perfect Forward Secrecy , meaning an adversary cannot retreive keys over lang time (i do have tunnels running for years allready).
Luckily for us, this is all solved in current TLS versions, thus choosing a good TLS-ciphersuite does help us.
As this is pretty difficult to choose for a non-crypto-specialist (openvpn --show-tls gives lots of options) you can let OpenVPN choose for you, but enforcing a high-level of crypto by using:
In both client and server config.
One of the great new features of 2.4 is the option tls-crypt , which crypts packets and lots of awesome things (see manpage and this topic )
Generate the tls-crypt key using:
Now we have a state-of-the-art control-channel which we use to setup our data-channel. As the data-channel has symmetric encryption, we need to use another set of crypto (openvpn --show-ciphers shows you the options) and hashing algoritm (HMAC).
As this another part of black magic for the most of us, i did someresearch(1)research(2)research(3) on some sources, including the openvpn documentation and for now it's advised to use AES-256-GCM and SHA256 (Eventually AES-256-CBC when GCM is not available) Remark: I haven't played with the NCP-cipher options yet. More to follow
Now we need to use a good HMAC (Message Authentication using a hash-algoritm) protocol. SHA256 will do for this, as it it's recommended:
Every now and then we need to renegotiate the key, used for crypto of the data-channel. The default value is 3600 seconds, which would be a secure enough option. If you are really paranoia you could lower this value to, i.e., 10 minutes by adding