Three resolv-conf files are availble selected with a link named: update-resolv-conf to keep it standard.
Your file: connman-update-resolv being used here.
export PATH=$PATH:/sbin:/usr/sbin:/bin:/usr/bin are duplicated. Remove the line?
IFACE=$(connmanctl services | awk ‘/*AR Wired/ {print $NF}’) to avoid an Error
should contain *AO instead *AR, right ?
In the configuration file I commented : #down-pre .
After stopping openvpn with: systemctl stop openvpn@evpn_myproxy would be possile proceeding: # systemctl enable openvpn@evpn_myproxy, Reboot and see if the connection is up?
No this is required as OpenVPN runs scripts in a restricted environment, where PATH may be minimal or missing important dirs like /usr/sbin. Tools like:
I’ll update post above, as sudo systemctl edit openvpn@evpn_myproxy should have been sudo systemctl start openvpn@evpn_myproxy. But to test this is working the connection needs to be up when rebooting. Running sudo systemctl stop openvpn@evpn_myproxy has been working as expected as the non vpn dns severs are restored to resolv.conf, but this wasn’t working on shutdown or reboot.
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Confirm the contents of /etc/resolv.conf (should be the vpn providers ones)
Confirm the contents of /etc/resolv.conf.connman-backup (should be 192.168.1.1).
Confirm the contents of /etc/resolv.conf (should be the vpn providers ones)
Confirm the contents of /etc/resolv.conf.connman-backup (should be 192.168.1.1).
/etc/resolv.conf wasn’t changed.
/etc/resolv.conf.connman-backup created, contains the direct dns address.
It seems, with reboot, 10 m earlier, /etc/resolv.confn was created with the vpn dns addrss.
/etc/resolv.conf seems to have been rewritten, but with the direct dns.
So with the vpn up, its still showing your local dns servers rather than the VPN one.
Right, however, checking with osmc the vpn dns is shown and the vpn connection ist established.
Where does /etc/resolv.confn come from? This isn’t is part of the script I’ve provided..
Don’t know. It’s created on startup anyway. It might be an error, additional n somwhere.
The Address written in the file is indeed the vpn dns. Perhaps it’s intended to be written
in the right file, instead a new one with a wrong name is created?
Btw, I checked the default editor: it is nano, just looking similar to Emacs.
I’m used to vi end NEdit on Unix, never using all others: pico, nano and emacs,fused.
Just issued systemctl stop, None of the resolv files has been touched,
However Kodi works normally with internet. The network setup still showing the vpn dns though.
Where does osmc get the dns from?
I’ve rewritten to the script to use connman to determine the the non vpn dns servers. The script can be reviewed here
I suggest you start with a clean environment, so remove all update-resolv-conf (including symlink to connman-update-resolv), and actually use the following in your conf file so its less confusing:-
script-security 2
up /etc/openvpn/connman-update-resolv
down /etc/openvpn/connman-update-resolv
Also remove /etc/resolv.confn, I don’t know where that came from.
Please follow the below:-
# clean up
sudo rm /etc/openvpn/connman-update-resolv
sudo rm /etc/resolv.conf.connman-backup
# download new script and set permissions
cd /etc/openvpn
sudo wget https://raw.githubusercontent.com/tomdoyle87/bash-scripts/main/connman-update-resolv
sudo chmod u+x connman-update-resolv
# make sure your vpn configuration file contains
script-security 2
up /etc/openvpn/connman-update-resolv
down /etc/openvpn/connman-update-resolv
# Systemd override should now contain:-
[Service]
ExecStartPre=/bin/sh -c "IFACE=$(connmanctl services | sed -n \"s/^\\*.* \\([^ ]*\\)$/\\1/p\"); if [ -n \"$IFACE\" ] && [ -f /etc/openvpn/pre-vpn-dns ]; then PRE_VPN_DNS=$(cat /etc/openvpn/pre-vpn-dns); connmanctl config \"$IFACE\" --nameservers $PRE_VPN_DNS; fi"
# Now make sure systemd can see the override by issuing:-
`sudo systemctl daemon-reload`
# Now we do some sense checking before we reboot
sudo systemctl stop openvpn@evpn_myproxy
Lets make sure connman has the correct dns servers, you can do this with:-
IFACE=$(connmanctl services | awk ‘/^\*/ {print $NF; exit}’)
connmanctl services “$IFACE”
| sed -n ‘s/.*Nameservers.Configuration = \[(.*)\].\*/\\1/p’
| tr -d ‘,’
| xargs
If they are wrong ones, set it with connman so for example:-
connmanctl config "$IFACE" --nameservers 192.168.1.1
Lets start the service:-
sudo systemctl start openvpn@evpn_myproxy
Check the vpn is up and working. If it isn't stop the service and start openvpn with config manually and check for errors. Check /etc/resolv.conf.connman-backup exists and contains the pre-vpn dns servers, any issues with this check the status for errors:-
systemctl status openvpn@evpn_myproxy
I'd do a few stops, starts and restarts of the service and make sure everything is working as expected.
Now lets let if it survives a reboot. I'd try with both the vpn up and down. Make sure the service is enabled before restarting.
Same caveat as before though, if you ever change the dns servers the vero uses when not connected to vpn, either via MyOSMC or manually (use connmanctl config), you need to remove /etc/resolv.conf.connman-backup so:-
sudo rm /etc/resolv.conf.connman-backup
Then restart the openvpn@ service (don’t reboot before this), so a /etc/resolv.conf.connman-backup can be generated.
repeated start / stop successfully, resolv.conf and resolv.conf.connman-backup always with correct content.
/etc/resolv.confn is no longer appearing.
Reboot with vpn Active and Inactive: Restart, in both cases with vpn Inactive and correct dns.
Manually Start / Stop via sytemctl should be working now.
Its a fallback if the down script doesn’t restore the correct DNS on shutdown.
So you may have scenerio during a shutdown or a reboot, that openvpn attempts to restore the prevpn dns, but it is unable to complete due to the connman service already being down.
So the the override restores the pre-vpn dns from /etc/resolv.conf.connman-backup on startup before bringing up the vpn connection.
By all means if you finding the down script is now running correctly on shutdown and reboot, then remove the override.
