What is best secure setup for OpenVPN?

[bayern1975]

hello, i would like to know what setup is best secure for runing OpenVPN? here is my setup and would like to know if it ok....

 

[martinr]

I see you have Username/password authentication set to No. I have mine set to Yes, and when you set it to Yes, another option immediately pops up: "Username/Password auth only", and I set that to No. So with these settings you have public key infrastructure (PKI) (keys and certs) AND usernames/passwords. (If you set Username/Password auth only to Yes, then you would not have PKI and you'd be solely reliant on the username and password combination for security.). What I then do, in the table on the General OpenVPN settings page, is give each client device a unique username and password so that if, say, I lost that device, I'd merely revoke the username/password pair for that device rather than having to set up OpenVPN from new again to generate fresh keys and certs followed by then have to reconfigure every client device. More importantly, with this Yes-No pairing, you have the added layer of username and passwords on top of PKI.

I see you've changed the port from 1194 to 1197, and that seems to me to be a good idea, though I'm sure some argue it won't give you much extra protection. But the logic is that it hides you from those scanners set to probe for only the common ports; it wouldn't protect you from a scanner set to probe all your ports, but if you've ever tried scanning all your ports externally and seen how long it takes, it makes you realise why hackers looking for targets of opportunity probe just the common ports.

The only other thing that comes to mind (aside from security) is something Merlin points out: if your home network is set to a common address range eg 192.168.1.0/24 or 192.168.0.0/24 you could run into problems if you are using OpenVPN from a remote network with the very same common address range. So it's best to have your home network range set to something uncommon eg 192.168.21.0/24 etc.

 

[bayern1975]

I have my network range set to 10.10.10.1 so I think I do not have conflict with other networks...

 

[elorimer]

What I then do, in the table on the General OpenVPN settings page, is give each client device a unique username and password so that if, say, I lost that device, I'd merely revoke the username/password pair for that device rather than having to set up OpenVPN from new again to generate fresh keys and certs followed by then have to reconfigure every client device. More importantly, with this Yes-No pairing, you have the added layer of username and passwords on top of PKI.

If you lost a device, the exported config file on the device is going to contain the key/cert, won't it, and not the username/password, so wouldn't you want to regenerate the key/cert rather than revoke the username/password?

I didn't realize you could have both. Does that improve the security of the tunnel, or just get around a key logger?

 

[bayern1975]

i change my configuration and now i can` t connect to my openvpn?

i get TLS errors when i try to connect?

Feb  5 14:10:11 openvpn[1394]: Initialization Sequence Completed
Feb  5 14:14:42 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:14:42 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:48578
Feb  5 14:14:51 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:14:51 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:36664
Feb  5 14:15:17 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:17 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:59078
Feb  5 14:15:24 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:24 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:34055
Feb  5 14:15:28 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:28 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:34055
Feb  5 14:15:35 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:35 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:53631
Feb  5 14:15:36 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:36 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:53631
Feb  5 14:15:49 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:49 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:40312
Feb  5 14:15:53 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:53 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:40312
Feb  5 14:17:26 openvpn[1394]: 188.198.101.213 TLS: Initial packet from [AF_INET6]::ffff:188.198.101.213:56549, sid=5f54cea7 34e8a8f7
Feb  5 14:18:26 openvpn[1394]: 188.198.101.213 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb  5 14:18:26 openvpn[1394]: 188.198.101.213 TLS Error: TLS handshake failed
Feb  5 14:18:26 openvpn[1394]: 188.198.101.213 SIGUSR1[soft,tls-error] received, client-instance restarting
Feb  5 14:18:52 openvpn[1394]: 188.198.101.213 TLS: Initial packet from [AF_INET6]::ffff:188.198.101.213:50121, sid=c03e4883 3110ce1a
Feb  5 14:19:52 openvpn[1394]: 188.198.101.213 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb  5 14:19:52 openvpn[1394]: 188.198.101.213 TLS Error: TLS handshake failed
Feb  5 14:19:52 openvpn[1394]: 188.198.101.213 SIGUSR1[soft,tls-error] received, client-instance restarting

 

[martinr]

If you lost a device, the exported config file on the device is going to contain the key/cert, won't it, and not the username/password, so wouldn't you want to regenerate the key/cert rather than revoke the username/password?

I didn't realize you could have both. Does that improve the security of the tunnel, or just get around a key logger?

You are right: I probably would regenerate the keys and certs, but without someone guessing the correct username and password for one of the other devices, they would not be able to connect to the vpn server from the lost device (provided I'd revoked its username/password).

I don't know nearly enough about it to say whether the username/password combination improves the security of the tunnel. My guess - and it is only speculation - would be that it doesn't improve the security of the tunnel in the sense that the packets would be encrypted to the same degree as they would be if you didn't have username/password protection as well. As I see it, the username/password only provide an additional layer or hurdle to be overcome to prevent unauthorised connections to the server. Once the connection is made, the username and password have done their job. And when I say "it doesn't improve the security of the tunnel", that makes it sound like the tunnel is somewhat insecure, but so far as we know, this level of encryption has not been cracked by anyone, and certainly not by target-of-opportunity hackers.

As for key loggers, if you've got one of them, I imagine it's game over anyway, especially if, when it can't connect back home for whatever reason, it merely stores what it's grabbed and waits until it can connect. I can't see a vpn being of any use if you have a keylogger. But as I say, I'm no expert in this area, I'm just speculating.

 

[martinr]

i change my configuration and now i can` t connect to my openvpn?

i get TLS errors when i try to connect?

Feb  5 14:10:11 openvpn[1394]: Initialization Sequence Completed
Feb  5 14:14:42 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:14:42 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:48578
Feb  5 14:14:51 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:14:51 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:36664
Feb  5 14:15:17 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:17 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:59078
Feb  5 14:15:24 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:24 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:34055
Feb  5 14:15:28 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:28 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:34055
Feb  5 14:15:35 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:35 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:53631
Feb  5 14:15:36 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:36 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:53631
Feb  5 14:15:49 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:49 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:40312
Feb  5 14:15:53 openvpn[1394]: tls-crypt unwrap error: packet too short
Feb  5 14:15:53 openvpn[1394]: TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:188.198.101.213:40312
Feb  5 14:17:26 openvpn[1394]: 188.198.101.213 TLS: Initial packet from [AF_INET6]::ffff:188.198.101.213:56549, sid=5f54cea7 34e8a8f7
Feb  5 14:18:26 openvpn[1394]: 188.198.101.213 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb  5 14:18:26 openvpn[1394]: 188.198.101.213 TLS Error: TLS handshake failed
Feb  5 14:18:26 openvpn[1394]: 188.198.101.213 SIGUSR1[soft,tls-error] received, client-instance restarting
Feb  5 14:18:52 openvpn[1394]: 188.198.101.213 TLS: Initial packet from [AF_INET6]::ffff:188.198.101.213:50121, sid=c03e4883 3110ce1a
Feb  5 14:19:52 openvpn[1394]: 188.198.101.213 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb  5 14:19:52 openvpn[1394]: 188.198.101.213 TLS Error: TLS handshake failed
Feb  5 14:19:52 openvpn[1394]: 188.198.101.213 SIGUSR1[soft,tls-error] received, client-instance restarting

Did you re-export the new .ovpn files to your client devices after changing the setting? In fact, you'll need to delete the current OpenVPN setup on your client devices and then import the new .ovpn file into your client devices. Don't forget: you also need to make up username/password pairs for the client devices you want to connect and put them on the General Settings OpenVPN page in the router.

Then, the first time you connect from the client device, it will ask for your username and password.

 

[Wutikorn]

i change my configuration and now i can` t connect to my openvpn?
i get TLS errors when i try to connect?

Are you connecting from Android, Windows or iOS? iOS default app has yet to be updated to support TLS-Crypt, while I am not sure about Android, but there is a good alternative app that supports TLS-Crypt. For Windows, if you update client to 2.4.0, you should be able to connect with TLS-Crypt on.

 

[bayern1975]

yes, i use openvpn over android phone. Didn't test with windows...

 

[martinr]

yes, i use openvpn over android phone. Didn't test with windows...

I'm confident that, by deleting your current client-device OpenVPN setup and importing the new .ovpn config file, you should be up and running provided you have entered the username/password pair on the router's General OpenVPN settings page.

 

[bayern1975]

yes, I deleted and create new ovpn file....it working now with disabled TLS control channel security settings...I think we need new update of openvpn app for android?

 

[martinr]

yes, i use openvpn over android phone. Didn't test with windows...

If you ever do use OpenVPN with Windows, you must open OpenVPN with administrator rights otherwise it won't work. (That's another one of Merlin's warnings; credit where it's due.)

EDIT: THIS IS NO LONGER TRUE, THANKS TO AN OPENVPN UPDATE

 

[martinr]

yes, I deleted and create new ovpn file....it working now with disabled TLS control channel security settings...I think we need new update of openvpn app for android?

You are far braver than I am, then: I think it's worth the price premium to buy Apple rather than Android if only because Apple vet all apps for malicious code and there is only one app store for Apple apps . (One dodgy Apple app did slip through the net a while ago, but at least there is a net.). Not that I want to go off at a tangent and set off an iOS vs Android sub-thread.

 

[Wutikorn]

yes, I deleted and create new ovpn file....it working now with disabled TLS control channel security settings...I think we need new update of openvpn app for android?

It probably takes sometimes for both iOS and Android apps to get support for TLS-Crypt. An alternative app I was talking about is "OpenVPN for Android" which you can use for now while waiting for updates.

 

[Martineau]

If you ever do use OpenVPN with Windows, you must open OpenVPN with administrator rights otherwise it won't work. (That's another one of Merlin's warnings; credit where it's due.)

If using Openvpn 2.4 Client this no longer true

OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Windows version 6.2 (Windows 8 or greater) 64bit

https://openvpn.net/index.php/open-source/downloads.html

 

[Fitz Mutch]

Requiring "tls-version-min 1.2" on the server will protect customers who accidentally, but understandably, try to use the Windows Certificate System Store and expect a TLS v1.2 control channel. Otherwise, OpenVPN will silently downgrade the control channel to TLS v1.1, when the client specifies the --cryptoapicert option. The idea is to force customers to put their cert & key in a PKCS #12 file, or their "plain text" config, and not use the Windows Certificate System Store. Unfortunately, Microsoft has moved on to a new .NET interface and TLS v1.2 is not available on the old interface used by OpenVPN. At least that's my understanding anyway.

/jffs/scripts/openvpnserver1.postconf

#!/bin/sh
CONFIG="$1"
source /usr/sbin/helper.sh

pc_append "tls-version-min 1.2" "$CONFIG"

 

[martinr]

If using Openvpn 2.4 Client this no longer true

OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Windows version 6.2 (Windows 8 or greater) 64bit

https://openvpn.net/index.php/open-source/downloads.html

View attachment 8463

Many thanks, Martineau. That's good to know: the fewer things with admin rights the better. Much appreciated.

 

[RMerlin]

Since you are running 2.4.0 at both ends, AES-256-GCM is strongly recommended - lower packet overhead than AES-256-CBC, as it will handle the packet auth portion.

if you need to stick to CBC, then using a SHA512 hash for packets is a complete waste of CPU power, and will dramatically reduce performance. These are only used to ensure that packets haven't been modified in transit - due to the nature of how HMAC works, even SHA1 would be secure. You can use SHA256 if you believe you might be at risk.

 

[Lost Dog]

Correct me if I'm wrong but I had read that AES-128 is fine for those who are simply looking to protect their browsing from general snooping. AES-256 is secure for governmental type encryption but for staying secure while traveling, etc then the lower grade encryption is fine. Being at 128 will also help throughput on lower end devices.

I hope this is not much of a threadjack but it is about trying to keep secure... While running 2.4.0 on the router as a server and there are clients who are not yet at 2.4.0, does the following line allow the 2.3.x clients to select AES-128-CBC or AES-256-CBC while allowing 2.4.0 clients use -GCM?

Negotiable ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC

 

[RMerlin]

I hope this is not much of a threadjack but it is about trying to keep secure... While running 2.4.0 on the router as a server and there are clients who are not yet at 2.4.0, does the following line allow the 2.3.x clients to select AES-128-CBC or AES-256-CBC while allowing 2.4.0 clients use -GCM?

Yes. 2.3.x clients will use what's in the legacy "cipher" field instead.