its got
Generated by Connection Manager
#nameserver 194.168.4.100
#nameserver 194.168.8.100
#new mode
nameserver “new dns provided by surfshark”
nameserver “new dns provided by surfshark”
where
new dns provided by surfshark is the dns addresses they gave me 
Hi,
Ok looks like openresolve isn’t going to work, so please remove these lines from the config:
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Did you add these yourself either by updating /etc/resolv.conf or via connman:
#new mode
nameserver 141.98.90.208
nameserver 206.189.180.64
These are surfshark’s dns servers, but they don’t seem to be working:
dig google.com @141.98.90.208
; <<>> DiG 9.11.6-P1-RedHat-9.11.6-5.P1.fc30 <<>> google.com @141.98.90.208
;; global options: +cmd
;; connection timed out; no servers could be reached
dig google.com @206.189.180.64
; <<>> DiG 9.11.6-P1-RedHat-9.11.6-5.P1.fc30 <<>> google.com @206.189.180.64
;; global options: +cmd
;; connection timed out; no servers could be reached
If you did add them I suggest changing these to something like cloudflares dns: 1.1.1.1 & 1.0.01
If you didn’t add the above nameservers, this means surkshark is pushing these both someother method; probably push dhcp-option. If this is the case I suggest contacted their support, as the issue appears to be on their end.
Tom.
well looks like that sorted it 
I removed the script as instructed and changed the dns to cloudflares and it now works
now I just have to try and replicate on my pi zero and my pi4 when osmc comes out for it
but not tonight.
Thank you so much
For anyone that’s following I rebooted and got the same issue
The conf got overwritten on reboot
To fix I put in the cloudflare dns again and used sudo chattr +i /etc/resolv.conf to lock it
Rebooted again and it now starts the vpn on boot
Hi,
Glad to hears its working. Please mark this topic as solved.
Thanks Tom.
My issue had ZERO to do with OSMC. That is a very special use-case.
Don’t forget that use of chattr +i on the file. There are just too many cooks messing with the resolv.conf file the last few years. IMHO.
I’d prefer to edit it myself or script the editing of it as needed like we did in the 1990s. I had an issue where DNS wasn’t working on a client machine. There were like 5 possible reasons - resolvconf, systemd-resolv, nm-*, and a few others. In the end, I purged all of them just to get my sanity back which finally stopped the resolv.conf from being changed to useless settings. Manually edited the file then setup a script to swap in the one file for normal networking and a different one for VPN networking. I’d wasted about 20 minutes cussing first. ;(
This was on an internal server that provides about 5 infrastructure services to the rest of the network. Sorta sucks when your APT caching and web proxy server can’t resolve external hosts.
My VPN pushes my own DNS server and the paid VPN provider lets me set which VPN is actually used. I’ve been using dnscrypt-proxy on my web-proxy. Clients here don’t have access to internet DNS, they must use the LAN proxy to get out. There are ways around all that, but most users don’t know it.
That’s definitely going to break resolvconf, isn’t it?
Yes, also surfsharks setup is unusual in the fact that they are pushing their own dns servers without being request. My understanding was the that the norm was for vpn providers to only push their own dns when requested, with openresolv for example. So chattr +i /etc/resolv.conf shouldn’t normally be required or recommended, although I see the need when using surfshark.
Although my recommendation is not use openresolv, and actually just set /etc/resolv.conf to use either your vpn provider ones (if they allow traffic without the vpn tunnel) or non-logged dns servers such as cloudflare or quad9. (My VPN provider allows access to there dns servers without the vpn tunnel, but I prefer cloudflares.) I would also look dnsovertls:
http://dnsprivacy.org/dns_privacy_daemon_-_stubby/
Thanks Tom.
Surfshark didn’t push the dns though I manually entered the dns provided by them in the resolv.conf file. Just seems the dns provided by them was no good
Hi,
Bit confused now, so what was over writing resolv.conf on reboot? If it wasn’t the surfshark config, I’m not convinced chattr +i /etc/resolv.conf was required.
Thanks Tom.
Yes it did. From your log:
Jul 07 21:25:13 osmc-Mortimer ovpn-client[323]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 162.252.172.57,dhcp-option DNS 149.154.159.92,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,block-outside-dns,route-gateway 10.8.8.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.8.3 255.255.255.0,peer-id 1,cipher AES-256-GCM'
1 Like
maybe my inexperience showing here but when I first ‘fixed’ the problem by using couldflares dns when I rebooted the new dns details were gone and I had the original resolv.conf file back. At that stage I commented out the original again and re-entered cloudflares dns and then used chattr +i to lock it and it has worked ever since
That would be expected. chattr is a way to prevent root processes from modifying config files you don’t want modified.
chmod won’t stop root processes from modifying a file … at least not without something like SELinux limiting the role for root. That’s whole-nether can-o-worms nobody here wants to touch.
chattr definitely was needed and is the most expedient solution, but you’ll want to remember that you used it so when it is time to change that file eventually, when you try and cannot, you’ll remember to chattr -i the file. BTW, I speak from experience. Last year I did the exact same thing on a box here (described above), and a few weeks ago, I needed to change the settings, but forgot that I’d chattr’d the file. chattr isn’t used very often at all. It is mentioned in 1 paragraph for Linux admins, but never again anywhere. In 25 yrs as a Unix admin, I’ve used it … er … maybe 5 times.