ConnMan VPN support in OSMC

Yes, I have searched all over OSMC including the Wiki. All I have found are very old links to OpenVPN, some random add-ons and guides which seems to be half-baked (e.g. suggesting manual edits of “/etc/resolve.conf”).

I have been trying to craft a config file for connman and I might have a working one created based on this in “/var/lib/connman-vpn” but whenever I run “connmanctl vpnconnection” all I get is the error “Error: The name net.connman.vpn was not provided by any .service files”.

I will admit to being completely confused now.

There’s a VPN add-on that easy to use. Works well

Thanks, but I actually want to avoid having to rely on an addon for a number of reasons, I’d prefer it to connect to the VPN after the network has come up, hence why I was trying with OpenVPN and a systemd service.
And whilst that does work for some things, Kodi does not seem to realise that a VPN is running (which I find rather odd). Hence why I am now trying with connman (assuming that to be the “correct way”).

If this is the “How to”, it no longer works (errors when I try to import the working OpenVPN config file as it tries to access a folder that does not exist):
Error Contents: [Errno 2] No such file or directory: '/home/osmc/.kodi/userdata/addon_data/script.openvpn/MyVPN.ovpn'

I will keep looking for instructions on how to make connman behave, or I’ll have to find some way to force Kodi to user the tun0 created by OpenVPN when I use that.

Now following this that I found here and I am now back at the stage where everything from the command line works, but nothing in Kodi seems to.

I am just so confused.

Is there a guide anywhere to getting connman to manage the VPN client on OSMC?

(And apologies for the spam)

To the best of my knowledge, connman is currently unable to manage the VPN client (specifically OpenVPN) on OSMC. Sam has said that he will get around to doing it but that it is a relatively low priority.

AFAICT, it seems you have successfully installed and configured OpenVPN via the command line but that you are having some issues with Kodi using the VPN tunnel. Perhaps you could clarify what those issues are, since, if the tunnel is up and running, all traffic should automatically be routed via the VPN.

The guide you link to at requires you to install network manager, which is unsupported in OSMC and very likely to cause problems.

I spotted the network-manager bit and ignore that (I’ve made mistakes like that in the past!), I was more trying to check the OpenVPN set-up.

When I test my WAN IP before and after starting the OpenVPN client, I can see it change and the exit IP matches what I expect.
When I do ifconfig, I can see that tun0 is “” or something like that.
But when I go into Kodi and check the IP there, it’s still “192.168.x.y” and I just don’t understand why. I can’t seem to find any option to say “Use tun0”.
My guess is that as connman does not know about OpenVPN, then Kodi does not know either.

It looks like the VPN is working.

Your Pi will always have its own IP address, such as 192.168.x.y, and that isn’t changed by running a VPN. What changes is that the routing table is modified so that external (ie non-LAN) traffic doesn’t go straight to your default gateway but is instead redirected to the VPN tunnel (tun0,

So as far as Kodi is concerned, it’s still running on a box with an IP address of 192.168.x.y but the routing table, which it doesn’t show, has been modified behind the scenes.

Given the current situation with OpenVPN on OSMC, there are two issues that you need to work around right now:

  • DNS leaks; and
  • updating /etc/resolv.conf.

Both of these issues can be addressed by installing the openresolv package from I believe it’s not officially supported but, AFAIK, it’s the only thing that currently works. NB: You should not install the Debian resolvconf package, which is incompatible with OSMC.

Many VPN services have their own DNS resolvers and, if pushed by the VPN server, the openresolv package will automatically update /etc/resolv.conf. In the rare cases where the VPN server does not push a DNS resolver, a different DNS resolver IP address from the one usually used should be manually added to the VPN configuration file in the format:

dhcp-option DNS
dhcp-option DNS

(The above IP addresses are for OpenDNS but they must differ from your usual DNS resolver or a DNS leak will occur.)

1 Like

Try [HOWTO] OSMC/Rasp Pi as OpenVPN client

So, i now spent several days as non native english speaker searching for Sams configuration. As bjoernr mentioned above, he tells in every thread, that there is an easy way, but there is none.

Yes people are going with /etc/network/interfaces because its a working solution and not only meaningless words. I dont know why he do this and leaves everyone searching for things that doesnt exist. Is this a Joke? i cant laugh anymore, sorry.

People using OSMC are streaming things, and there are plenty reasons why they have to use a Proxy.
Using OpenVPN is ok, because its more encryptet than PPTP but if you want to see streams in a really good quality OpenVPN doesnt give you the Bandwith you need. Even tho, full encrypted Streams are not required in most cases, and PPTP is fast enough.

I dont understand why you are not working on that topic, as most people will get Problems in the Future with High Quality Streaming over OpenVPN.

Could you please link me to some information on the background of this claim? Or you refer to the CPU requirements for high bandwidth encryption?

I’m guessing a provider may have said this as a potential cop out as to why streams load slowly, knowing Kodi users focus on OpenVPN.

PPTP can be blocked / throttled very trivially by ISPs. OpenVPN will be performant, unless you run it on a very slow system.

We are working on OpenVPN integration with OSMC

After Stretch, it is my next area to make progress.

OpenVPN should provide you with adequate bandwidth. You won’t see protocol overhead, even in the tens of megabits.

No work is planned for PPTP


I’d just add that the UDP protocol is ideally suited to streaming video, since you can tolerate the odd dropped frame, and will often give you higher speeds than using TCP. Unfortunately, some ISPs will place a cap on continuous UDP traffic, so you might find that TCP gives significantly better performance.

DSL-Speed für Video-Streaming
Anbieter Mindestvoraussetzung HD-Qualität 4K-Qualität
Amazon 0,9 MBit/s 3,5 MBit/s 15 MBit/s
Maxdome 2 MBit/s 6 MBit/s nicht verfügbar
Netflix 0,5 MBit/s 5 MBit/s 25 MBit/s
Magine 2 MBit/s 8 MBit/s nicht verfügbar
Zattoo 4 MBit/s 7 MBit/s nicht verfügbar
TV SPIELFILM live 2 MBit/s 4 MBit/s nicht verfügbar
Sky Go 2 Mbit/s 6 MBit/s nicht verfügbar

There can be a 100 different reasons why OpenVPN might give poor speeds - and many of them are not the fault of OpenVPN.

What does a table of required streaming speeds (apparently taken from ) have to do with the performance of OpenVPN?

1 Like

Because these are the required speeds for HighQuality Streams.
I think i havent made that clear, so i make another try.
The Bandwith output depends on encryption depth and correlates with CPU. Yes it doesnt really matter for your Desktop PC, but in most cases OSMC is working on little machines like RaspberryPi or similar.

Even if you have the fastest VPN Provider (PP) with unlimited Bandwith and use a Pi3 as an OpenVPN Gateway that doesnt do anything else you only get 17-24MBits out of it.
If you make OpenVPN work on OSMC you will not get more, because you will run 4k Video on it too at the same time.

And thats why PPTP is better for OSMC. You will get high Bandwith and you dont need full encryption.

The Pi has two main shortcomings as far as OpenVPN throughput is concerned:

  • a relatively slow ethernet connector that shares the USB bus;
  • no hardware acceleration for AES encryption.

As far as the second point is concerned, you might be surprised by the figures (on a Pi 3):

osmc@osmc:~$ openssl speed aes-128-cbc
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      39545.79k    47180.76k    49610.50k    50413.91k    50645.67k

For the AES-128-CBC cipher, the CPU is able to encrypt 50 megabytes per second with a 1k block size. That’s 400 megabits per second. Clearly, there are other significant overheads with OpenVPN but it’s not as slow as you seem to think.

Here is the same test on a Vero4K:

osmc@osmc:~$ openssl speed aes-128-cbc
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      42325.40k    55580.25k    60183.38k    61385.39k    62100.29k

So 20% faster by default, plus the Vero4K doesn’t share its ethernet with the USB bus.

But if you look at this thread, you’ll see that the Vero4K is actually capable of:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     143775.92k   415486.72k   756965.46k   974767.10k  1064138.07k

That’s almost 1 gigabyte per second encryption with a 1k block. Would that be fast enough?

i dont know where you get those but on my Pi3 it looks different.

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      28432.57k    33765.14k    35682.29k    36030.12k    36164.95k

and this is theoretically the output of 256 cbc.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      22638.64k    25964.93k    26922.58k    27194.03k    27273.90k

On real connections there is more variation but mostly less than theory (Mbit)

Its ok when u want to sell your vero and push this as a “payed feature”, but then make that clear and stop confusing people on telling them that there is a working solution for PPTP or that OpenVPN on a Pi has no Limits.


Dilthedog did not suggest the pi3 had no limits for openvpn, just advised they were better than expected. My pi3 produced these results:

openssl speed aes-128-cbc:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      39668.55k    47030.76k    49528.49k    50323.46k    50528.26k

openssl speed aes-256-cbc:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      32052.38k    36668.59k    38229.08k    38638.59k    38726.31k

These concur with Dil’s results.


yes u are right. my result was caused by underclocking. My pi was running at only 1000Mhz.
I fixed it and it now runs on 1300Mhz wich results in:
openssl speed aes-128-cbc

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      40871.02k    48798.53k    51406.34k    52102.14k    52281.34k

openssl speed aes-256-cbc

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      32601.20k    37413.46k    38926.85k    39315.80k    39565.44k

But ive done some more testing in aes-128-cbc vs aes-256-cbc and got very interesting Results.


It looks like aes-128-cbc encryption is about 40 to 50 percent slower than 256 under real Conditions.