[HOWTO] OSMC/Rasp Pi as OpenVPN client

[Loop]

Nice one!! Might have to give this a try!

[boneskull]

I’ve installed OpenVPN via apt-get. I have an /etc/init.d/openvpn and a proper configuration file for my server.

Everything is configured properly. Like above, I receive this error.

Mon May 4 15:37:39 2015 /sbin/ip route add 0.0.0.0/0 via (IP of VPN)
RTNETLINK answers: File exists

The default route fails to be established, and the VPN does not function unless I manually change the default route thereafter via:

$ /sbin/ip route change default via <ip-address> dev tun0

From what I can tell via my searching, the problem is in connman. I have only found the problem mentioned; no solutions. connman monkeys with the default route somehow before it should, and prevents it from being set by openvpn.

So, I’m thinking one of two things is true:

1. This is a bug in connman, or
2. This is a default system misconfiguration by OSMC

Anyone have any insight?

[fzinken]

@boneskull

/etc/init.d/openvpn

OSMC doesn’t use init scripts, use system sudo service openvpn restart
Also sometimes it help to first start the client manually to see any errors openvpn --config /etc/openvpn/client.conf

[boneskull]

Whether or not I use init.d, systemd or whatever doesn’t have any bearing on the error. Here’s the output from systemd:

Sep 11 12:56:18 wight openvpn[273]: /sbin/ip route del 0.0.0.0/0
Sep 11 12:56:18 wight openvpn[273]: /sbin/ip route add 0.0.0.0/0 via 10.10.10.5
Sep 11 12:56:18 wight openvpn[273]: ERROR: Linux route add command failed: external program exited with error status: 2

The command always fails, I’m almost certain, because connman does something w/ the default route which makes it impossible to remove. /sbin/ip route del 0.0.0.0/0 should delete it so /sbin/ip route add 0.0.0.0/0 via 10.10.10.5 can add it.

I have an identical configuration on another box running Rasbian (which does not use connman); there are no problems.

[Lanimul]

I’ve got this rough tutorial for a openvpn client that Ive gotten to work,

sudo apt-get update

sudo apt-get install openvpn

cd /etc/openvpn

add .ovpn file to dir /etc/openvpn
Add lines to .ovpn for user/pass

sudo sed -i '/auth-user-pass/cauth-user-pass user.txt' *.ovpn

sudo nano user.txt

In this file create only two lines of text
username(your username)
password(your password)
press crtl+x to save the file then press y and enter.

Since the file we have created contains sensitive info we need to ensure that only the user that created the file can read and write to it. Type:

sudo chmod go-rwx user.txt

Rename ovpn file, vpn.conf
Start/Enable Service

sudo systemctl enable openvpn@vpn.service
sudo systemctl start openvpn@vpn.service

Check status:

Type:

curl http://checkip.dyndns.org

[Toast]

thinking of doing a AIO script based of this discussion and a server discussion here on the forum not that i use vpn for Kodi/OSMC but it seems to be popular a request

[boneskull]

I was able to hack around the problem; I created a script in /etc/systemd/system/multi-user.target.wants:

[Unit]
Description=Change Default Route
Requisite=openvpn.service
After=openvpn.service

[Service]
Type=oneshot
ExecStart=/sbin/change-route

[Install]
WantedBy=mult-user.target

Which executes /sbin/change-route:

#!/bin/bash

COUNT=60
while [ $COUNT -gt 0 ]
do
  if [[ -n `/sbin/ip route | grep tun0` ]]
  then
	break
  fi
  sleep 1
  let COUNT-=1
done
IP=`/sbin/ip route | grep 'tun0  proto kernel' | cut -d ' ' -f12`
/sbin/ip route change default via $IP dev tun0

The script above waits (60s max) until device tun0 is created by OpenVPN. Once it is, it grabs the gateway address then changes the default route to use it.

[boneskull]

This is not about running an OpenVPN server; this is about running an OpenVPN client.

From what I can gather, something is broken in OSMC prevents OpenVPN clients from working properly which needs addressing. I haven’t been able to pinpoint the problem, however.

My best guess is that connman is either bugged or misconfigured in OSMC. I’m not sure why connman is needed by OSMC. I’m curious why this tool was chosen instead of a more established one, like some other users on this thread. If I wanted to propose it be replaced with something else, where would I do that?

[Toast]

not recommended, im sure @sam_nazarko can fill in why better then me

[boneskull]

It’s not recommended to replace it or to propose to replace it? Because if the latter is true, then that’s a problem.

[Toast]

its not recommended to replace it on your system atm… as to the reasons why im gonna refer to Sam cause i dont remember the specifics

[boneskull]

I wouldn’t do it as a user, but rather to propose it be replaced at the distribution level

[ActionA]

You could propose it but your use case is somewhat niche and is unlikely to result in the change you are seeking here.
Here’s why you wouldn’t want to attempt to change it as a user

Going full systemd

Why are you trying to replace connman ? We don’t use the Debian connman package, we provide our own custom compiled and patched version of connman, and we provide it with a proper systemd service unit. Connman is intricately linked into the design of OSMC - in particular the entire networking GUI in OSMC settings is designed around Python DBus calls to the connman DBus API - if you remove connman and replace it with something else you will completely break the Networking GUI. You will also bre…

[sam_nazarko]

@miralibu

i dont know why osmc developers decided to use this shitty network manager, as a vpn/proxy is essential on a streaming platform…

One man’s shit is one man’s treasure.

ConnMan fully supports VPN configuration. The reason for choosing ConnMan over the legacy networking system is that while it worked for you, the large majority (99%) of our users do not wish to configure networking via a command line. ConnMan provides us with a stable DBus interface so we can make configuring connections simple and manageable from Kodi. It also has a very low footprint.

It is easy for you to copy over /etc/network/ files to remedy the situation, and that’s what we expect from power users. We need to support the most common use case scenarios and make these as easy as possible for users to employ. ConnMan lets us do that.

With that said, I don’t anticipate a reason why we won’t have GUI based VPN configuration eventually

@boneskull

I’m curious why this tool was chosen instead of a more established one, like some other users on this thread. If I wanted to propose it be replaced with something else, where would I do that

Here. What would you consider as more established? NetworkManager is a lot more resource intensive and wouldn’t work any magic: we’d still need to develop our addon to support VPN via the GUI, and additionally, have to rewrite all of the networking code.

@boneskull

connman is either bugged or misconfigured in OSMC

If you can provide a better description of the issue then we can have a look.

Edit:

@boneskull

connman monkeys with the default route somehow before it should

You are likely being caught out by WISPR. To determine true network connectivity (and in the future, to allow login to WiFi networks that ask for a username and password), ConnMan will configure a route and try to connect to osmc.tv. If it receives HTTP-X-OSMC then it knows that it is really connected to the Internet, and not a web page asking for credentials.

I see you are using a legacy /etc/init.d/ script. The solution is to write a proper systemd unit (I am sure one already exists for OpenVPN) and add After=connman.service.

ConnMan assumes that as it is the network manager it is permitted to configure routes accordingly. Other network managers will do the same

Sam

[DBMandrake]

@sam_nazarko

The solution is to write a proper systemd unit (I am sure one already exists for OpenVPN) and add After=connman.service.

An even more generic solution that would still work on OSMC would be to specify After=network.target in your OpenVPN service.

This is the established way in systemd of specifying that your service should start after the network manager (whatever it might be) is up and running. (network.target does not mean that the network connection is configured and up and running, only that the network manager daemon has started running)

Because our connman.service has Before=network.target it must finish starting before any service that specifies After=network.target is allowed to start, but because network.target is a well known, generic, network manager agnostic target name it should work on any systemd system.

[Wod_Ka]

Question guys, have openvpn successfully installed and tested on my Rasp Pi but when configuring the Kodi add-on my folder /usr/sbin seems to be empty (show hidden files and folder enabled in file lists)

Probably a small thing i overlook but hope somebody can point me in good direction

thanks…

Sorry already solved, editing trough the context menu of the add-on did the trick

[a1840317]

hi guys!

Is there any way to add visual feedback to OSMC while an openvpn connection is active? Maybe a tiny flag or text on any of the corners of the main menu (only) would do…

Just a thought…

[basherpi]

Hi all, I am a total novice at Pi as only received it today. So any help would be appreciated.

When typing into Putty I get the response: openvpn: command not found.

Does that mean I have typed incorrectly into putty or the original configuration file.

Thanks, James

[fzinken]

@basherpi

When typing into Putty I get the response: openvpn: command not found

Did you actually install and configure openvpn or you thought it was preinstalled?

[basherpi]

Ok, got past the putty problem, but now when I try to run openvpn i get the message:

An error has occurred whilst trying to connect OpenVPN
Unable to connect to OpenVPN management interface

Any suggestions please.