Hello everyone,
does anybody has the same problem that Brian Hornsby’s VPN script doesn’t work anymore after the official stretch update?
Here is my log (I hope I did it right because it’s my first log post)
http://paste.osmc.tv/wujocicize
I like the script very much because it’s so fast and stable…
Thanks in advance
Greets
18:01:01.745 T:3355439872 DEBUG: OpenVPN: ERROR: [Errno 111] Connection refused
Giving us a Kodi log is unfortunately insufficient. We need at least the system journal and a copy of the log from Brian Hornsby’s add on.
Ok that make sense.
Here is the script log.
http://paste.osmc.io/ixiceheruf.mel
I will send the system journal as fast as possible.
Thanks
It looks like OpenVPN is creating a data channel using AES-256-GCM encryption:
Wed Jan 10 19:01:01 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jan 10 19:01:01 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
It also says that you have OpenSSL 1.0.2l , whereas the latest for Debian stretch is 1.1.0f. I have a feeling that the GCM cipher won’t be in 1.0.2l, though I can’t easily check.
I think a full set of logs would be useful here.
You might also be able to force a different cipher by including this line in your VPN config file:
ncp-ciphers AES-256-CBC:AES-128-CBCHello again, sorry for the big delay.
First of all thanks for the fast responses.
The support here is amazing and also people like me with less linux skills will always be supported with patience!!!
Now I finally have uploadad the complete logs:
http://paste.osmc.io/titewodano
I tested your suggestion but no luck.
It seems that OSMC comes with libssl versions 1.0.2l and 1.1.0f - and OpenVPN links to the former.
Further investigation shows that the AES-256-GCM cipher is supported in the current OpenVPN/OpenSSL configuration.
That points to some kind of network-related issue being the problem here. It’s possible that version 2.4.0 has tightened up a bit on protecting against replay attacks, so you’re only seeing this now.
The next step is to try one of two things:
Change to connecting with the VPN server using the TCP protocol, rather than the more usual UDP. Your VPN provider will probably have a config file for this.
Slacken the replay protection a little by increasing the window size a little. To do this add this to the config file: replay-window 64 30 (the default is 64 15). The number 30/15 is the window size in seconds. This option is only applicable to a UDP connection.
I’m having issues as well.
When I try to start the VPN via Brian’s Addon, I get:
An error has occurred whilst trying to connect OpenVPN
Unable to connect to OpenVPN management interface
But when I do an ‘ip a’, the tunnel actually was established and if I run ‘ps -ef |grep openvpn’ I can see the process running.
Looking at the openvpn.log after the first attempt:
Fri Jan 12 22:23:13 2018 OpenVPN 2.4.0 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Jan 12 22:23:13 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Fri Jan 12 22:23:13 2018 setsockopt(IPV6_V6ONLY=0)
Fri Jan 12 22:23:18 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:xxxx
Fri Jan 12 22:23:18 2018 UDP link local: (not bound)
Fri Jan 12 22:23:18 2018 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:xxxx
Fri Jan 12 22:23:19 2018 [fbb220df2a4500648073188d0f062120] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:xxxx
Fri Jan 12 22:23:20 2018 TUN/TAP device tun0 opened
Fri Jan 12 22:23:20 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Jan 12 22:23:20 2018 /sbin/ip link set dev tun0 up mtu 1500
Fri Jan 12 22:23:20 2018 /sbin/ip addr add dev tun0 local xxx.xxx.xxx.xxx peer xxx.xxx.xxx.xxx
Fri Jan 12 22:23:20 2018 Initialization Sequence Completed
If I try a subsequent time, it obviously fails with a similar “Address already in use” error that you ha.
Fri Jan 12 22:27:38 2018 OpenVPN 2.4.0 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Jan 12 22:27:38 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Fri Jan 12 22:27:38 2018 setsockopt(IPV6_V6ONLY=0)
Fri Jan 12 22:27:38 2018 MANAGEMENT: Socket bind failed on local address [AF_INET6]::1:xxxx: Address already in use
Fri Jan 12 22:27:38 2018 Exiting due to fatal error
I was just wondering if you checked to make sure that the tunnel wasn’t actually established?
I’m gonna start digging into Brian’s Addon now to see if I can see why it’s displaying an error even though it’s actually establishing the tunnel.
To be honest, I’d be fine living with the error until Sam and crew implements OpenVPN with ConnMan, but my problem is that I don’t know that the tunnel is actually established without pulling out my laptop and SSH’ing to the Pi to verify. And since the Addon doesn’t know that it’s established, there’s no way for me to disconnect the VPN.
ok, in my case it looks like the Management Interface is now listening on the IPv6 loopback address after updating.
osmc@osmc-Test:~$ netstat -ltun | grep 1337
tcp6 0 0 ::1:1337 :::* LISTEN
On my OSMC install that hasn’t been updated yet, the Management Interface is listening on the IPv4 loopback address.
osmc@osmc-lr:~$ netstat -ltuno | grep 1337
tcp 0 0 127.0.0.1:1337 0.0.0.0:* LISTEN
Looking through the code in Brian’s Addon, it looks like it’s trying to query the Management Interface on the IPv4 loopback address (127.0.0.1). It also looks like he’s trying to set the Management Interface on the IPv4 loopback as well, but I’m guessing that the newer version of OpenVPN is forcing that to IPv6.
FYI - I resolved this by changing the below in my ovpn:
OLD:
management localhost 1337
NEW:
management 127.0.0.1 1337
Ok you’re right. Shame on me that I didn’t realize that the first attempt to connect is successful and the following aren’t. The changement in the configs are working too.
@gmccauley: For getting my WAN adress within Kodi I’m using a small addon from the kodinerds repo called WAN-Ip.
Thanks for all your help…
gmccauley is there anything else I need to do to my updated ovpn files?
I updated them all with the change you describe above but I still have the same error message ‘Unable to connect to OpenVPN Management interface’.
Thanks for any advice.
So what do you see when you run the above command?
Thanks for replying. When I run that command I get the following line:
tcp6 0 0 ::1:1337 :::* LISTEN
So it’s still listening in IPv6.
If you changed the line as advised by @gmccauley in post #9 and restarted your Vero4K , I’m surprised to see it still using IPv6.
(If you changed the file, which file did you change?)
Thanks for the fast reply, mate!!
I’m running this on a Raspberry Pi 2 and have definitely rebooted a couple times since I changed that line in each of my .ovpn config files. (the ones which you set up for each of the different VPN servers)
Ok, Pi2.
And your .conf files are in /home/osmc/vpn-config, not in /etc/openvpn?
If so, you’ll probably need to contact the author.
Yeah. They are in /home/osmc/vpn-config
The files I have are .ovpn though
Do you know of a better way you can recommend to do this on a Pi2?
Thanks again for responding so fast! 
When you “import” the OVPN into the addon, it creates a copy in /home/osmc/.kodi/userdata/addon_data/script.openvpn.
I suggest re-importing them or changing them in that folder.
You can confirm the exact path of the OVPN being used by using ps.
osmc@osmc-Test:~$ ps -ef |grep openvpn
root 2098 1 3 19:22 ? 00:00:00 /usr/sbin/openvpn --cd /home/osmc/.kodi/userdata/addon_data/script.openvpn --daemon --management 127.0.0.1 1337 --config /home/osmc/.kodi/userdata/addon_data/script.openvpn/blah.ovpn --log /home/osmc/.kodi/userdata/addon_data/script.openvpn/openvpn.log
Thanks for that extra bit of info! I finally had some time this morning to set this up and check that things are working as they were before.
I went into the add-on settings and deleted all my ovpn configs (I had WAY too many) and then reimported the ones I had changed and copied over to vpn-config. The add-on is now working great!! I checked the IP by using my ssh connection and the command “curl ipv4.icanhazip.com” (Thanks @stim) and it seems to be working. One slightly worrying thing is that initially this morning that command gave me my actual home IP and not the VPN one - I had tested it last night and it was working but must have disconnected by this morning. I chose the same ovpn config as last night and it has been showing that one since. I wish there was some indication if the VPN servers connection drops. Another weird thing I noticed is that although under the OSMC/Settings/System Information it shows internet as ‘connected’, when I was checking my DNS settings under My OSMC/Network it says 'Status: eth0 (no internet). But the internet is definitely working and I can stream some video with no problem.
Anyway @gmccauley I want to thank you for all your help and for giving me that extra little bit of information which so ofter makes all the difference!!
If you want to enable automatic restart of openvpn in the event of the process being killed, see here.