I recently seem to have the same DNS issues that others have reported recently. I'm using PIA and have been successfully for the past couple of years. This problem has developed recently though not exactly sure when, and I have automatic updates enabled.
Basically, after connecting to PIA I lose the ability to perform DNS lookups since my DNS settings are still set to that of my ISP rather than the PIA DNS servers.
Here are the logfile entries from openvpn.log when I connect:
Wed Jul 4 10:48:05 2018 WARNING: file '/storage/.kodi/addons/service.vpn.manager/PIA/pass.txt' is group or others accessible
Wed Jul 4 10:48:05 2018 OpenVPN 2.4.0 x86_64-libreelec-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD] built on Apr 15 2018
Wed Jul 4 10:48:05 2018 library versions: OpenSSL 1.0.2o 27 Mar 2018, LZO 2.09
Wed Jul 4 10:48:05 2018 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Jul 4 10:48:05 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]194.187.249.181:1198
Wed Jul 4 10:48:05 2018 Socket Buffers: R=[1880000->1880000] S=[1880000->1880000]
Wed Jul 4 10:48:05 2018 UDP link local: (not bound)
Wed Jul 4 10:48:05 2018 UDP link remote: [AF_INET]194.187.249.181:1198
Wed Jul 4 10:48:05 2018 TLS: Initial packet from [AF_INET]194.187.249.181:1198, sid=11215183 2c6b50e5
Wed Jul 4 10:48:05 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 4 10:48:05 2018 VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, [email protected]
Wed Jul 4 10:48:05 2018 Validating certificate key usage
Wed Jul 4 10:48:05 2018 ++ Certificate has key usage 00a0, expects 00a0
Wed Jul 4 10:48:05 2018 VERIFY KU OK
Wed Jul 4 10:48:05 2018 Validating certificate extended key usage
Wed Jul 4 10:48:05 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Jul 4 10:48:05 2018 VERIFY EKU OK
Wed Jul 4 10:48:05 2018 VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=7ecfe90795b20f017ca8095e02244cd0, name=7ecfe90795b20f017ca8095e02244cd0
Wed Jul 4 10:48:05 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Jul 4 10:48:05 2018 [7ecfe90795b20f017ca8095e02244cd0] Peer Connection Initiated with [AF_INET]194.187.249.181:1198
Wed Jul 4 10:48:06 2018 SENT CONTROL [7ecfe90795b20f017ca8095e02244cd0]: 'PUSH_REQUEST' (status=1)
Wed Jul 4 10:48:11 2018 SENT CONTROL [7ecfe90795b20f017ca8095e02244cd0]: 'PUSH_REQUEST' (status=1)
Wed Jul 4 10:48:11 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.57.10.1,topology net30,ifconfig 10.57.10.6 10.57.10.5,auth-token'
Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: compression parms modified
Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: route options modified
Wed Jul 4 10:48:11 2018 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Jul 4 10:48:11 2018 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Jul 4 10:48:11 2018 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 4 10:48:11 2018 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Jul 4 10:48:11 2018 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 4 10:48:11 2018 TUN/TAP device tun0 opened
Wed Jul 4 10:48:11 2018 TUN/TAP TX queue length set to 100
Wed Jul 4 10:48:11 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Jul 4 10:48:11 2018 /sbin/ip link set dev tun0 up mtu 1500
Wed Jul 4 10:48:11 2018 /sbin/ip addr add dev tun0 local 10.57.10.6 peer 10.57.10.5
Wed Jul 4 10:48:11 2018 /storage/.kodi/userdata/addon_data/service.vpn.manager/PIA/up.sh tun0 1500 1558 10.57.10.6 10.57.10.5 init
Wed Jul 4 10:48:12 2018 /sbin/ip route add 194.187.249.181/32 via 192.168.0.1
Wed Jul 4 10:48:12 2018 /sbin/ip route add 0.0.0.0/1 via 10.57.10.5
Wed Jul 4 10:48:12 2018 /sbin/ip route add 128.0.0.0/1 via 10.57.10.5
Wed Jul 4 10:48:12 2018 /sbin/ip route add 10.57.10.1/32 via 10.57.10.5
Wed Jul 4 10:48:12 2018 Initialization Sequence Completed
Display More
I can see the DNS servers in the PUSH reply, but these do not take effect since nslookups are still using my ISPs DNS, and eventually timeout:
# nslookup www.google.com
Server: 194.168.4.100
After reading this thread I tried activating the "Potential DNS Fix" in the advanced settings but this gave the error:
A DNS fix was not possible. Refer to the Kodi log... which looks like this:
11:03:37.389 T:140547394086656 NOTICE: VPN Mgr : (common.py) Creating a new APPEND.txt for Private Internet Access to try and fix DNS issues
11:03:37.399 T:140547394086656 ERROR: VPN Mgr : (common.py) To attempt a DNS fix, you need to install update-resolv-conf script in /etc/openvpn
11:03:37.400 T:140547394086656 ERROR: VPN Mgr : (common.py) Alternatively for systemd enabled installations, install update-systemd-resolved in /etc/openvpn/scripts
11:03:37.400 T:140547394086656 ERROR: VPN Mgr : (common.py) After installation of one of the scripts, apply the DNS fix again.
I'm running LibreELEC 8.2.5.
Any help with resolving this would be greatly received and I'll be happy to run further tests to help debug where it's going wrong.
For the time being, as a workaround, I think I will adjust my LE network settings to point at the google DNS servers.