VPN client connects to server as normal, but websites cannot be found when connected
To connect with the PIA servers I use PIA-suppled scripts from the openvpn command line in Debian Linux Stretch, because I haven't been able to get network-manager of the PIA app to reliably hide my IP address. The scripts had been working for years. Then I had to reinstall my operating system with the same os..
The scripts now connect to their respective servers, but after I'm connected I can't get to any websites. The browser error is: blah blah blah URL cannot be found.
If I try
ping google.com
it fails. But If I try
ping 172.217.4.46
which is google's ip, it works. If I put
google.com
in the browser, it fails.
If I put
172.217.4.46
in the browser, it somehow figures out it's google's ip, but then it goes to look up google.com and can't find it. So, I think the problem is with DNS resolution on the vpn. Do I have to specify DNS servers somewhere? Mind you this was working a few days back, and I didn't change the scripts at all, so it is some detail I'm overlooking.
The scripts now connect to their respective servers, but after I'm connected I can't get to any websites. The browser error is: blah blah blah URL cannot be found.
If I try
ping google.com
it fails. But If I try
ping 172.217.4.46
which is google's ip, it works. If I put
google.com
in the browser, it fails.
If I put
172.217.4.46
in the browser, it somehow figures out it's google's ip, but then it goes to look up google.com and can't find it. So, I think the problem is with DNS resolution on the vpn. Do I have to specify DNS servers somewhere? Mind you this was working a few days back, and I didn't change the scripts at all, so it is some detail I'm overlooking.
Comments
[quote][email protected]:~/openvpn$ sudo openvpn 'US Midwest.ovpn'
[sudo] password for tom:
Fri Mar 2 20:52:50 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Mar 2 20:52:50 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Enter Auth Username: p5363566
Enter Auth Password: **********
Fri Mar 2 20:52:55 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]104.207.136.122:1194
Fri Mar 2 20:52:55 2018 UDP link local: (not bound)
Fri Mar 2 20:52:55 2018 UDP link remote: [AF_INET]104.207.136.122:1194
Fri Mar 2 20:52:55 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Mar 2 20:52:55 2018 [cda9b73ac1e35346d444a54becd708a3] Peer Connection Initiated with [AF_INET]104.207.136.122:1194
Fri Mar 2 20:53:01 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Fri Mar 2 20:53:01 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Fri Mar 2 20:53:01 2018 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Fri Mar 2 20:53:01 2018 TUN/TAP device tun0 opened
Fri Mar 2 20:53:01 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Mar 2 20:53:01 2018 /sbin/ip link set dev tun0 up mtu 1500
Fri Mar 2 20:53:01 2018 /sbin/ip addr add dev tun0 local 10.51.10.6 peer 10.51.10.5
Fri Mar 2 20:53:01 2018 Initialization Sequence Completed[/quote]
ip route:
[quote][email protected]:~$ ip route
0.0.0.0/1 via 10.51.10.5 dev tun0
default via 192.168.111.1 dev enp4s0 proto static metric 100
10.51.10.1 via 10.51.10.5 dev tun0
10.51.10.5 dev tun0 proto kernel scope link src 10.51.10.6
104.207.136.122 via 192.168.111.1 dev enp4s0
128.0.0.0/1 via 10.51.10.5 dev tun0
169.254.0.0/16 dev enp4s0 scope link metric 1000
192.168.111.0/24 dev enp4s0 proto kernel scope link src 192.168.111.165 metric 100
[/quote]
I discovered this on my system:
ls -al /etc/resolve.conf
lrwxrwxrwx 1 root root 35 Mar 3 19:34 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf
instead of
lrwxrwxrwx 1 root root 35 Mar 3 19:34 /etc/resolv.conf -> /var/run/resolve/stub-resolv.conf
So, network-manager is managing resolve. and
systemctl status systemd-resolved.service
Showed that the service systemd-resolved is disabled and not running. So I decided to go with network-manager to manage the vpn connections. PIA uses openvpn, so I installed
apt-get install network-manager-openvpn network-manager-openvpn-gnome
restarted network manager
systemctl restart NetworkManager.service
Then I clicked on the nm-applet, went to settings, created a new vpn connection by importing one of the ovpn scripts PIA supplies. I filled in the user name and password, turned off IPv6 networking on the connection (although I'm not sure that's necessary) and that was it. I connected and it worked.
The problem I was having is a persistent problem with PIA, spanning years. I really hope the staff will explain in some document on the site how DNS is managed in a Linux system, that openvpn tries to always use resolved, regardless of which service is actually managing DNS, that a user can find out which service that is by
ls -al /etc/resolv.conf
and looking at the link to the file, and then can either activate resolved, or use the program that is currently managing DNS resolution to handle the openvpn connections. This took me two days to solve, with no help from tech-support, and it should be in the troubleshooting steps.
as of recently the servers that have been extremely slow for me and normal speeds now. something is going on for sure!
Seems like yours is definitely not using resolved, so PIA won't be using resolved in the first place.
By the way, we have a NetworkManager installer script here, which is a bit more reliable than importing the .ovpn in some situations: https://www.privateinternetaccess.com/pages/client-support/ubuntu-openvpn
v78 adds support for when the configuration is managed through resolvconf.
DNS on some Linux distros is a complete mess of backwards compatibility with the backwards compatibility of the backwards compatibility.
Had the same issue on a fresh ubuntu install but that (above protocol) worked to get PIA up and running again. Thanks for posting!