While I can start OpenVPN manually with sudo systemctl start [email protected] ("server" being the name of my config file), trying to get OpenVPN to open automatically after a reboot after having set up the required symlink with the command sudo systemctl enable [email protected] failed.

4 Answers 4



In /etc/openvpn/ your configs must end in .conf and not .ovpn!


I'm about to make some bold claims that are specific to...

pi@raspberrypi:~ $ uname -a && lsb_release -a
Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie

(imaged from 2017-04-10-raspbian-jessie-lite)


1. For me it was enough to simply install OpenVPN via:

sudo apt install openvpn

2. Then copied my offsite-client.ovpn to /etc/openvpn

3. Then I enabled the service via:

sudo systemctl enable openvpn

4. This is the initial state of /etc/default/openvpn:

# This is the configuration file for /etc/init.d/openvpn

# Start only these VPNs automatically via init script.
# Allowed values are "all", "none" or space separated list of
# names of the VPNs. If empty, "all" is assumed.
# The VPN name refers to the VPN configutation file name.
# i.e. "home" would be /etc/openvpn/home.conf
# If you're running systemd, changing this variable will
# require running "systemctl daemon-reload" followed by
# a restart of the openvpn service (if you removed entries
# you may have to stop those manually)
#AUTOSTART="home office"
# WARNING: If you're running systemd the rest of the
# options in this file are ignored.
# Refresh interval (in seconds) of default status files
# located in /var/run/openvpn.$NAME.status
# Defaults to 10, 0 disables status file generation
# Optional arguments to openvpn's command line
# If you need openvpn running after sendsigs, i.e.
# to let umountnfs work over the vpn, set OMIT_SENDSIGS
# to 1 and include umountnfs as Required-Stop: in openvpn's
# init.d script (remember to run insserv after that)

I did not need to change anything. (Though I did uncomment AUTOSTART="all" when I was losing my mind, I changed it back and rebooted to confirm the statement If empty, "all" is assumed.)

4. I lost my mind reading 2 dozen articles explaining everything about installing EasyRSA and everything else that was redundant to step #1.

5. I realized that I left the wrong extension on my config and did:

sudo mv /etc/openvpn/offsite-client.ovpn /etc/openvpn/offsite-client.conf
sudo reboot now

And all was well.

  • This is fine, but it's a client setup, whereas the OP seems to have been asking about the server. Commented Jan 13, 2019 at 19:14
  • Great answer - but it would be even better if it didn't require a full reboot.
    – Rebroad
    Commented Dec 6, 2019 at 16:04
  • 1
    @Rebroad it may not require a reboot. You could probably just do sudo systemctl stop openvpn and then sudo systemctl start openvpn. But it really depends on what your goal is. I wasn't concerned about uptime. I was concerned with being assured that I could put this RPi in the mail and when my client plugs it in, it will phone home and not need a keyboard and monitor to be connected and not require me to coach them on how to fix it. Commented Dec 14, 2019 at 4:27
  • @AtomHeartFather I realize the OP was talking about the server when they asked the question 2 years before I answered it. But, they didn't specify that in the title, and this is where google brings people. SE is much more about the community that comes after, than it is about the person who asks the original question. Commented Dec 14, 2019 at 4:33

I solved it. It turned out what was blocking OpenVPN from starting at boot was the local IP. The steps I took to make this work were:

  1. Commenting out the local IP address in /etc/openvpn/server.conf
  2. Switching to root with sudo -s
  3. Adding @reboot systemctl start [email protected] to root's crontab
  • 1
    Hi. I don't understand how the repeated call of systemctl start upon boot should improve the behaviour over one systemctl enable?
    – Ghanima
    Commented Nov 24, 2015 at 23:03
  • You may be right. After commenting out the local IP address in the config file, there may be several ways to start OpenVPN automatically after a reboot. Before I discovered that the local IP prevented OpenVPN from starting, all my previous attempts, including systemctl enable failed. The problem was OpenVPN trying to bind to it before the network connection was established (see bbs.archlinux.org/viewtopic.php?id=183818).
    – haadaa
    Commented Nov 24, 2015 at 23:13
  • @reboot is the time when the cron daemon starts. Could it be that this might be before some other services are started via systemd such as network? In this case the solution would not be robust. (Just guessing here.)
    – Ghanima
    Commented Nov 24, 2015 at 23:20
  • I don't really know. However, sudo systemctl enable [email protected] (which I tried first) didn't work either. The local IP certainly got in the way also there.
    – haadaa
    Commented Nov 24, 2015 at 23:45
  • Using a cron job may get it to start, but it is the wrong way to do it. I'd like to see this get a correct answer. I'll keep searching. Commented May 31, 2017 at 0:59

I manage my Pi 3 jessie with Webmin ( don't ask! ) and I found the removing the "local" line was sufficient to enable the VPN server to start.


To me openvpn starts well via systemctl only if I configure static IP of eth0 in the /etc/network/interfaces. Unfortunately this causes double routing entries in the table as the new mechanism for configuration of interfaces is via dhcpcd.

Working, but bad solution is to remove manually doubled entries on boot.

I added static configuration in dhcpcd.conf. I changed target of the openvpn init script to network-online instead network but it is still not enough. I checked in logs that dhcpcd set the IP of the eth0 five seconds after openvpn fails.

A working solution is to deactivate dhcpcd:

systemctl disable dhcpcd.service

and edit /etc/network/interfaces

iface eth0 inet static
 address 192.168.0.x
 gateway 192.168.0.y


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.