Running OpenVPN as a client (daemon)

Noone else was facing this, did I really miss the solution?

Running a (holiday) router to connect to the home network with OpenVPN set up

  • as a server at home
  • as a client on the holiday router

But starting the service openvpn with ovpn config file on OpenWRT doesnt let me set the client key password?
Please let me know what I am missing, I could not find it in the openwrt openvpn docs ( nor on the search engines. using "askpass" in /etc/openvpn/vpnclient.ovpn does not help anyways.

Or do I need to start the "service" in dialog mode?

Log error is

daemon.err openvpn(vpnclient)[21975]: neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'.  If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.
Wed Nov  7 11:11:47 2018 daemon.notice openvpn(vpnclient)[21975]: Exiting due to fatal error

The error message says it all - you would need a tty console to be able to enter a password. The only way I know of to fix the issue is to make a set of crypto files that do not require a password.

I have the same general setup of a home vpn server and remote client device. I just don’t use the password option.

But it means that I would need to create an additional key without password - if this is possible. The client key for other devices must be password protected.
It would be ok for me to start the openvpn service in dialog mode like with --daemon but I did not figure out how to get this --askpass working.

In the article, follow instructions for
Additional configuration for commercial third party OpenVPN provider:
using the sed and cat command.

Remember to substitute

yeah, I just tried the equivalent parameters (it requires the parameter askpass) successfully:

askpass /etc/openvpn/vpnclient.auth

and the file vpnclient.auth contains the password only

is this a case for adding the info to the Wiki?

I tried to edit the Wiki :face_vomiting:

  • Configuration for passphrase-protected keys:
    In file /etc/openvpn/vpnclient.ovpn
    add parameters
    askpass /etc/openvpn/vpnclient.auth

cat << "EOF" > /etc/openvpn/vpnclient.auth && chmod 600 /etc/openvpn/vpnclient.auth

service openvpn restart

There's no point using encrypted private key on your own router.

Is this possible to use more than one key for more than one device?
And even if -

There is no point of using several keys on personal devices.

First you create a root certificate with CA authority. Every device needs a copy of the public part of that certificate. The private key though is used only to sign new certificates. You should keep that in a very safe place and have a password on it. If someone gets the private CA key they can make their own certificates and compromise the whole system.

Each client or server has its own individual certificate which you have signed with the root certificate. The device holds a full copy (public and private) of that certificate. It is not necessary to distribute it to other devices. You should not reuse the same user certificate on more than one device. This lets you revoke the one certificate if a device is lost or stolen. Though when you only have a small number of users you could just make a new CA and rebuild everything.

It doesn't add any security to encrypt a private key when you must also store the passphrase in plaintext on the filesystem to facilitate automated use.

Noone mentioned that it adds security if the password for the key is stored in plain text. It is like writing the pin number of your credit card on a piece of paper and putting it next to it in your wallet. If both, the credit card and the piece of paper gets lost with the wallet, the credit card account gets compromised. This is very similar to a private key and the password. It does in fact not make really sense to store the password in plaintext in a file on the device.

Please visit the guide here

  • and note this sentence: "After you've saved .ovpn-file to your device, distribute it to any additional devices that will use the OpenVPN client."

This might help to get a bigger picture and to spot the topic of this thread.

In this scenario, the requirement for using a password protected key and simply having a password protected key is more in regard to:

  • transporting the ovpn file - the key is leaving the device and is transferred via another media to another device
  • using one and the same ovpn file on multiple devices whereas you need to notice that the file contains the private key.

You know that you can encrypt/decrypt private key anytime, don't you?

Yeah, this seems to be an option for a workaround. [] comes with a really good knowledge base with lots of useful information.
Fortunately, there is a way to copy the ovpn file as-it-is and to set the askpass /etc/openvpn/vpnclient.auth
It would be much better to use some kind of secure storage (instead of storing the pass in plain text), is this also described on that site?

It's common practice to keep TLS-keys unencrypted while using CLI-services and that's not limited to OpenVPN.

In that case, of course, you must question why the script includes such a part:
PASSPHRASE MUST BE SET (4 chars minimum, 16+ chars recommended)

I have never seen private keys used for authentication or encryption (also of the transport layer) that are not password protected. Maybe in a garage in test environment, but not in real life.

The overall goal of this post was not to tell or learn, it was about finding or enhancing the documentation for

askpass /etc/openvpn/vpnclient.auth

OpenVPN Basic guide isn't solo-written, and I'm not motivated enough to argue about that topic with other authors.
If you check OpenVPN Dual Stack guide, you will notice another point of view.

You've seen at least OpenVPN server key, which is unencrypted.

:sweat_smile: "OpenVPN Dual Stack guide" - because you are the author? Good one!

Not a good one is:
Recommending "nocrypt" for client keys that are supposed (!!!) to leave a device / to be transported / to be used on a mobile device is grossly negligent.
I don't want to need to notice this view, it feels very uncomfortable!

There is a need for dual stack setup for openvpn for me too, but I cannot follow this guide in general.

Security is never absolute, it's always relative and depends on threat modeling.
Nobody stops you from additional security hardening.
That's one of the reasons the code isn't completely scripted, so you can adapt it to your needs.

1 Like