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

I did upgrade yes.
I tried to check if Transmission is running via OpenVPN. Strangely, it isn’t.
I tested by adding the magnet link from this site via SSH to Transmission:
https://torguard.net/checkmytorrentipaddress.php

Weirdly, in Transmission it showed my actual IP (provided by my ISP). Perhaps I messed around a while ago when I tried this (never got that working). Don’t remember. Maybe I should do a clean install.

Network namespaces seem to be more trouble than they’re worth. If you can’t reverse the configuration, then I guess a reinstall is on the cards. Out of interest what does route -n show when the VPN is running?

Just local stuff:

Kernel IP routing table                                                                                  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface                            
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth0                             
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0                             
192.168.1.254   0.0.0.0         255.255.255.255 UH    0      0        0 eth0

Fyi 192.168.1.254 is my router address.

So no tun0.

A belated reply on the subject of leakage.

DNS leakage. As long as the VPN is directing all external traffic through the tunnel, no DNS leakage should occur. There was an issue with Connman where traffic to DNS resolvers was being sent outside the VPN but that’s been fixed in 2017.12-1. The one remaining possibility for leakage is if your DNS resolver is on your locall network, eg your router or a local instance of PiHole. So whenever using a VPN make sure that your DNS resolver is not on the local network. In practice, most VPNs will push their own resolver, so this isn’t usually such an issue.

Data leakage. You can mess around with iptables and create a bulletproof set-up but in my opinion it’s overkill for 99% of cases. However, what is very useful is to define an automatic restart for the openvpn service, so if it fails the downtime will be measured in seconds. The best way to do this is:

sudo mkdir /etc/systemd/system/openvpn@.service.d
sudo nano /etc/systemd/system/openvpn@.service.d/restart.conf

and in the file paste these three lines:

[Service]
Restart=always
RestartSec=5

Thanks a lot for this information, I keep learning about tunneling and IP or DNS leakage since I started using OSMC.

I never understood why a VPN tunnel is used for all internet traffic. In most cases, you only want one for P2P and perhaps the same tunnel or a different one for some videostreams like iBBC Videoplayer when you are not in the UK. All other traffic doesn’t need encryption or tunneling.

I spend a lot of time figuring out network namespaces, too complex even after finding this tool called NSDO.

This morning I stumbled upon this guide for dummies to setup VPN Split Tunneling, to only force certain applications to go via the tunnel, with automatic killswitch when the tunnel goes down and auto restart.

I believe this is the way to go if you don’t want Spotify, Kodi and whatever else to use VPN and thus increase resource usage and have a slower connection.

Even if you do need VPN for certain streams/addons, you probably want to manage that from Kodi. For P2P this guide simply seems like an absolute requirement these days.

Allow me to list a few reasons:

Your DNS can be hijacked to point to incorrect IP addresses.
Your DNS can be censored and/or blocked.
Your traffic metadata will be recorded and sold to third parties.
Your traffic can have unique tracking identifiers added.
Your ISP can inject adverts (and iffy javascript) into your browser.

There’s more, but I think you get the idea.

Sure but my brain could also fry from radiation. And for advertising, 99% of the people already share plenty of stuff that is being sold for targeting.

All the other stuff should not really be an issue for 90% of the users.

Unless you live in countries with lots of censorship, P2P is still the only reason you would want to limit to the tunnel.

It’ll depend on our personal perspective.

1 Like

Yes I should add this is my opinion ofcourse! :slight_smile:
Still there is reason to limit 1 tunnel to specific apps and there is little documentation on this topic. I believe this forum now basically has all the info needed for all use cases.

Great to hear, any ETA for it?

I did a clean install of OSMC but still have the same issue. I only added auth-user-pass /etc/openvpn/login.txt to my etc/openvpn/myconffile.conf and also created the file /etc/openvpn/login.txt with my VPN user/pw.

I just do sudo systemctl start openvpn
this gives me a weird message:

osmc@Vero:/$ sudo systemctl start openvpn
osmc@Vero:/$
Broadcast message from root@Vero (Mon 2018-01-22 21:31:41 CET):

Password entry required for 'Enter Auth Username:' (PID 3827).
Please enter password with the systemd-tty-ask-password-agent tool!

Also tried sudo systemctl start openvpn@myconffile
This doesn’t give me weird messages, but there is no tunnel either!

Something very strange is happening!

Hi,

What happens if your try and run openvpn manually:

sudo openvpn –config /etc/openvpn/myconffile.conf

Thanks Tom.

Strange, I keep getting errors about TLS handshake, but my credentials are correct

osmc@Vero:~$ sudo openvpn  --config /etc/openvpn/se8.nordvpn.com.udp1194.conf
Mon Jan 22 21:52:54 2018 OpenVPN 2.4.0 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Mon Jan 22 21:52:54 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Auth Username: myusername
Enter Auth Password: ***********
Mon Jan 22 21:53:04 2018 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Mon Jan 22 21:53:04 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 22 21:53:04 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 22 21:53:04 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]193.105.134.166:1194
Mon Jan 22 21:53:04 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Jan 22 21:53:04 2018 UDP link local: (not bound)
Mon Jan 22 21:53:04 2018 UDP link remote: [AF_INET]193.105.134.166:1194
Mon Jan 22 21:54:04 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jan 22 21:54:04 2018 TLS Error: TLS handshake failed
Mon Jan 22 21:54:04 2018 SIGUSR1[soft,tls-error] received, process restarting
Mon Jan 22 21:54:04 2018 Restart pause, 5 second(s)

I believe user and password must be on separate lines, with user on the first line.

When I run the manual command, it seems my login.txt file is ignored because the system asks for my credentials first.

Hi,

Is 193.105.134.166 the correct IP for the vpn server?

Thanks Tom.

It is.
I noticed I had auth-user-pass twice in my conf, it was already there and I added it again with the value /etc/openvpn/login.txt. I removed the double entry, now the system does not ask for my credentials anymore.
But I still get the TLS error and it takes forever…

Just as we generally can’t give an informed comment without logs, here we can’t give an informed comment without seeing your openvpn config file. Passwords not necessary. :wink:

Hi,

Also you can generate to a log file by adding:

log-append /var/log/openvpn.log

To the conf file, this may give more insight into whats going on; the path doesn’t really matter its just an example. You probably want to remove this once the issue resolved.

Thanks Tom.