OpenVPN, moving from init.d way to the Stretch/systemd way

Prior to the Stretch update, I had configured OpenVPN as an init.d “service”, but post Stretch update, OSMC expects the damon to be started via systemd/systemctl.

To see if you’ve also previously configured OpenVPN as an init.d service, issue the following:

ls -las /etc/init.d/openvpn.service

if you have a file by this name, you’ll need to move it, as the default startup method is not via systemctl vs service.

sudo mv /etc/init.d/openvpn.service ~/openvpn.service

…that essentially removes the init.d “service” startup of OpenVPN.

Now you’ll need to decide if you want to use the on-system-startup process for running OpenVPN, or use the GUI OpenVPN Kodi app. The first makes the OpenVPN connection every time you start your OSMC machine and is used across ALL non-lan OSMC network traffic, whereas the second you have to do manually, via the gui, after every reboot. It just depends on what kind of addons you run whether you want constant VPN, or VPN only for use of certain addons. Depending on your ISP network speed, and VPN provider, there can be a performance hit using VPN. In some cases, it has been enough that I was only able to reliably play 720p streams vs 1080p streams.

I prefer the command-line on-bootup approach, so the rest of this post is how to migrate from the init.d “service” configuration to the new Stretch/systemd configuration.

For users with a prior configuration (i.e. when you did the first command was a file there?):

First, you’ll need to figure out where your prior VPN service provider config files are, so do the following:

sudo cat ~/openvpn.service

That file contained the following for me:


ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/ --cd /home/osmc/vpn-conf --config servers.ovpn


…the relevant line is:

ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/ --cd /home/osmc/vpn-conf --config servers.ovpn

This tells me that I had created a subdirectory in my home directory called vpn-conf [--cd /home/osmc/vpn-conf], and this is where I placed my OpenVPN config files [--config servers.ovpn].

If I list out all the files in that subdirectory I see the following:

ls -las
4 drwxr-xr-x 2 root root 4096 Jan 10 12:24 .
4 drwxr-xr-x 11 osmc osmc 4096 Jan 10 12:24 …
4 -rw-r–r-- 1 root root 1684 Dec 7 13:10
4 -rw-r–r-- 1 root root 29 Dec 7 13:24 login.conf
4 -rw-r–r-- 1 root root 1811 Jan 10 12:10 servers.ovpn

…this may be different for you, as it all depends on how you originally configured your init.d based OpenVPN client and your specific VPN provider. There should be a minimum of two files: the .crt file and the .ovpn file. If your config files are not located in your home directory, I do recommend that you move your configuration files into a subdirectory of your home directory. That makes backing up all of your “customizations” very easy in the future.

Now, to setup OpenVPN to startup at boot, via systemd, it’s pretty straightforward, create a symlink to your current .ovpn file in the new /etc/openvpn directory.

sudo ln -s ~/vpn-conf/servers.ovpn /etc/openvpn/ipvanish.conf

You can name your symlink whatever you want. I use IPVanish as my VPN provider, so I named the symlink ipvanish.conf The import piece is that the name of the symlink MUST end in .conf this is what systemd uses to determine which config files to run at startup.

So now read the contents of your .conf file.

sudo cat /etc/openvpn/ipvanish.conf

…for me that gives:

dev tun
proto udp
remote 443
resolv-retry infinite
ca /home/osmc/vpn-conf/
verify-x509-name name
auth-user-pass /home/osmc/vpn-conf/login.conf
verb 3
auth SHA256
cipher AES-256-CBC
keysize 256

The important bits to notice are that the filename for ca and auth-user are fully qualified! If these files names are not fully qualified it will expect them to exist in your /etc/openvpn folder, but since we want to keep all of our custom files in our home directory, just make sure the filename is fully qualified to that location!

Now, let’s test that OpenVPN works:

openvpn /etc/openvpn/ipvanish.conf

If you receive any errors, you’ll need to use the output of this command to debug your config file. If you receive no errors, then press <ctrl-C> and Enter, which will stop the OpenVPN client connection.

Now issue:


When the system reboots, enter:

systemctl --no-pager status openvpn@*

This should give you the status of your VPN connection. If there are any errors, you’ll need to use that output to debug (but if you received no errors via the direct run above, you shouldn’t receive any errors this way).

Now to test the VPN connection. Enter:


…this should give you the VPN provided IP address (not your home network’s “external” address. To test that open a browser from another machine, and enter: which should then show a different address that represents you ISP provided IP address).

I created a script in my home directory for easy testing in the future:

nano ~/

systemctl --no-pager status openvpn@*
echo -e “=================================================\nExternal IP: via ‘curl’”

chmod 755 ~/

Now in the future all you have to do is login to your OSMC device via SSH, and execute:


Any idea how this will work with this plugin? Install and Configure OpenVPN on OSMC/Kodi – Nerd Drivel

I like the idea of being able to turn VPN off and switch locations from the UI.


Thanks for creating a new post :slight_smile:

While your solution might work for you, I’d be remiss if I didn’t provide an alternative – and simpler – method, as least as far as the CLI side is concerned.

If you want openvpn to start automatically at system boot, run this command

sudo systemctl enable openvpn

To switch it off, it’s simply:

sudo systemctl disable openvpn

Place your VPN provider’s configuration file in /etc/openvpn (using sudo). Ditto any certificates, etc. Ensure that the configuration files is <something>.conf, not <something>.ovpn.

Edit file /etc/default/openvpn and append the name of the .conf file you want to run to the AUTOSTART= line, less the .conf part. So for myvpn.conf it would read AUTOSTART=myvpn.

If you want to run a VPN configuration that’s not defined as AUTOSTART, but has a config file in /etc/openvpn, you can start/stop it with

sudo systemctl start openvpn@myvpn2
sudo systemctl stop openvpn@myvpn2

And for good measure, install openresolv, rather than resolvconf.

Edit: Fixed an error. Thx @zilexa

1 Like

Actually the post was VERY specific for those that had done a prior install of OpenVPN via init.d, not for doing a new install.

With the Stretch release OpenVPN is now installed by default, so no need to systemctl enable openvpn as it’s on-by-default now. The default systemd startup file will now actually auto start any .conf in /etc/openvpn as it’s default set to “ALL”.

So now to autostart (if you haven’t previously configured OpenVPN a different way), one only need put the .conf file(s) in the /etc/openvpn directory, then reboot.

I still stand by my assertion that it’s best to create a vpn-conf subdirectory in your home directory, then download any VPN provider .ovpn/.crt files there, then create a symlink to the .ovpn as .conf into /etc/openvpn.

Just makes backup/updates easier to remember.

For making it work with the OpenVPN addons, basically everything is already setup and ready-to go in Stretch, you need only install the OpenVPN addon. All the backend is already in place (so no need to do the apt-get stuff from the link you provided).

You just download your VPN providers .opvn/.crt files into your home directory, then via the addon gui you just import the .opvn file, and it will capture the rest.

1 Like

This is a nice write-up, but I would really like to push the ConnMan approach. Once it’s tested, and well proven (configuration via CLI), we can work on a My OSMC GUI option for it.


1 Like

Ok, except, if I’m understanding this all correctly, you added /etc/network/if-up.d/openvpn to the build which checks for the presence of systemd, and if it exists, uses systemctl to start openvpn:



if [ ! -x $OPENVPN ]; then
  exit 0

if [ -n "$IF_OPENVPN" ]; then
  for vpn in $IF_OPENVPN; do
    ## check systemd present
    if [ -d $SYSTEMD ]; then
      $SYSTEMCTL --no-block start openvpn@$vpn
      $OPENVPN_INIT start $vpn

Since systemd binaries are installed, than any init.d service is NOT called, and systemctl is used to start OpenVPN, likewise since you have AUTOSTART="all" set in /etc/default/openvpn, then any .conf file in /etc/openvpn will be automatically started.

All of this does correspond to the OpenVPN install/configuration documentation for debian.

Sooooo, if you do add a gui config for OpenVPN via connmanager, you might want to remove/rename the /etc/network/if-up.d/openvpn file so that it doesn’t attempt to autostart any files via systemctl.

Am I understanding that all correctly?

The script also came with openvpn 2.3.4, which was part of the OSMC jessie build. It’s a standard part of the Debian openvpn package - and, AFAIK, isn’t used by OSMC.

There isn’t room for overlap here fortunately.

Which “script” are you speaking of?

Prior to this morning Stretch release I had the following config file in place:

Via this file, init.d would start OpenVPN during bootup.

After this morning’s Stretch release, OpenVPN was no longer running during startup, and the following two config related files are in place:


Via these two config file, if there is any “.conf” file placed in /etc/openvpn, then systemd will attempt to run them via systemctl at startup. Based on my reading of /etc/network/if-up.d/openvpnif the systemd executable is installed, then that script it will use systemd/systemctl to run OpenVPN, vs. using init.d/service.

Since I previously had OpenVPN running via /etc/init.d/openvpn.service that tells me that /etc/network/if-up.d/openvpn had to have been modified, or /etc/init.d/openvpn.service was being executed from another script? As of the push of Stretch my /etc/init.d/openvpn.service was not being called during bootup, which is why I created this post.

There isn’t room for overlap here fortunately.

But there is already overlap, which is what I’m trying to convey.

Right now, “out of the box”, if you add a .conf file to /etc/openvpn then systemd will automatically launch OpenVPN with those files.

So if you add OpenVPN configuration for ConnMan, with the current files in place:


…I believe it will try to run OpenVPN via both ConnMan, and via systemd, so if you add ConnMan configuration, then as part of that deploy, you’ll need to remove/rename these two scripts.


ConnMan won’t do that – it only invokes OpenVPN with the presence of its own VPN files in a specific ConnMan controlled directory.


Riiiiight, but I think you’re missing what I’m trying to say…

If someone like me, already has an openVPN .conf file at: /etc/openvpn, then these two existing scripts:


…WILL run those configs.

SO, if you add a GUI config to My OMSC and I use that tool (maybe forgetting that I has set up OpenVPN via /etc/openvpn/vpn.conf), then your GUI will write out the new ConnMan config, and I’ll have two “startup configurations” both trying to run OpenVPN at startup.

I’m just saying that a LOT of people already have OpenVPN configured, so if you’re going to add a new way to config/run OpenVPN, then as part of that release you’ll need to remove the scripts the run those “previously configured” startup scripts.

Make sense?

We would take care of that during migration.
Once you activate it via My OSMC, we disable the other mechanism.

BTW: if-up.d doesnt properly work on OSMC. It will only work for the loopback device (if you are lucky) as every other device is controlled by CM which doesn’t implement this.

As of right now, it works to start OpenVPN, as that is how I currently have it configured…

Will you check the current contents of your: /etc/network/if-up.d file?

This is what mine contains:



if [ ! -x $OPENVPN ]; then
exit 0

if [ -n “$IF_OPENVPN” ]; then
for vpn in $IF_OPENVPN; do
## check systemd present
if [ -d $SYSTEMD ]; then
$SYSTEMCTL --no-block start openvpn@$vpn
$OPENVPN_INIT start $vpn

Which, if I’m reading it correctly, uses systemctl to start openvpn. Is that correct, or am I misreading something? Said another way, is this script /etc/network/if-up.d being executed at startup, or is systemctl daemons ran via another script? If so, what script?

It’s starting it on loopback; which is risky.
It’s not starting in reaction to actual PHYs.

It will be handled by OSMC properly in the future, don’t worry.


1 Like

Zac. If you give us a grab-logs -A I’ll be better able to comment on your particular installation.

But the jessie version of OSMC used systemd for openvpn, as does the stretch version. If you had configured your system to bypass systemd in OSMC jessie, then that was not necessary since commands like sudo systemctl enable openvpn worked just fine.

And AFAICT AUTOSTART=“all” is commented out in /etc/default/openvpn, so openvpn is not configured to run all config files. You can check for yourself:

cd /tmp
apt-get download openvpn
dpkg -X openvpn_2.4.0-6+deb9u2_armhf.deb ovpn
grep AUTOSTART ./ovpn/etc/default/openvpn

That’s straight from the Debian repo, so unless Sam has overwritten it from another OSMC package (which he hasn’t done on my system) then AUTOSTART=“all” is not set.

I have it working for me, so I’ll take you word for it. Do you want me to delete the post?

Thanks a lot for this post, it was exactly what I was looking for. But how to ensure there is no leakage? For example when the VPN server goes down or something? I want my device only to connect to the internet via OpenVPN.

1 remark, 1 other question:

For me, this is called AUTOSTART, not AUTORUN.

Also could you please check if this systemd.service correct? I installed Openvpn a long time ago but didn’t use it, I don’t remember if I messed around with this file back then or if this is the default:

# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

Description=OpenVPN service



For me too. Just a mistake.

If you’ve upgraded to OSMC stretch, it’ll be correct. (I double-checked and it’s correct.)

Leakage is difficult to prevent 100%. I’ll have to reply a bit later.