PIA on Ubuntu 17.10
I have recently upgraded from Ubuntu 17.04 to 17.10.
This page was helpful when setting up for 17.04.
After upgrading, I found some issues, one of which I haven't managed to resolve.
Why do I still need to set the desktop name as Unity for PIA, when it was supposed to work on GNOME without this workaround?
In other words, I couldn't get any wired or wireless connection without PIA connected.
The change that solved this for me was to manually edit /etc/NetworkManager/NetworkManager.conf as root.
I then realized that under the [main] section, there was no dns setting, so I re-added:
Maybe this will help someone.
The weird part was that the UI settings for NetworkManager were set to retrieve the DNS servers automatically (and they wouldn't work even if I disabled the auto feature and added my ISP's DNS servers manually).
Edit, I haven't followed this thread for a while and just read my post again, realizing that I completely forgot to specify the following:
The implication with the solution for issue #2 is that your DNS servers are set up as PIA's in NetworkManager's config.
Otherwise your DNS searches might be visible to your ISP, which wouldn't make for a great DNS "experience", I guess
You can verify your DNS by typing:
"Most grateful if anyone with an explanation/idea on issue #1."
Edit #2
This has been resolved for me with the latest versions of the installer (73, 74 and 75), but I see the discussion has evolved...
Thanks in advance!
This page was helpful when setting up for 17.04.
After upgrading, I found some issues, one of which I haven't managed to resolve.
Issue #1
With 17.04, I was using the following call to launch PIA:nohup env XDG_CURRENT_DESKTOP=Unity /home/mena/.pia_manager/pia_manager/run.sh > /dev/null 2>&1 &
Now, as 17.10 is rid of Unity and back to GNOME, I tried the following modifications:
- Remove the nohup and env calls altogether - didn't work
- Remove the env call and leave nohup - didn't work
- Keep both, but use a number of substitutes for Unity as the new value of XDG_CURRENT_DESKTOP: ubuntu:GNOME, GNOME, ${XDG_CURRENT_DESKTOP/:*/} and just ${XDG_CURRENT_DESKTOP} - none worked
Why do I still need to set the desktop name as Unity for PIA, when it was supposed to work on GNOME without this workaround?
Issue #2 - resolved
I'm not sure this is directly related to PIA, but upon upgrading, I realized my DNS would only work if PIA was on.In other words, I couldn't get any wired or wireless connection without PIA connected.
The change that solved this for me was to manually edit /etc/NetworkManager/NetworkManager.conf as root.
I then realized that under the [main] section, there was no dns setting, so I re-added:
dns=dnsmasqAfter restarting NetworkManager (sudo systemctl restart NetworkManager) I could connect sans PIA.
Maybe this will help someone.
The weird part was that the UI settings for NetworkManager were set to retrieve the DNS servers automatically (and they wouldn't work even if I disabled the auto feature and added my ISP's DNS servers manually).
Edit, I haven't followed this thread for a while and just read my post again, realizing that I completely forgot to specify the following:
The implication with the solution for issue #2 is that your DNS servers are set up as PIA's in NetworkManager's config.
Otherwise your DNS searches might be visible to your ISP, which wouldn't make for a great DNS "experience", I guess

You can verify your DNS by typing:
nmcli device show [your nework interface in use] | grep IP4.DNSJust nslookup the IPs if you're not sure.
"Most grateful if anyone with an explanation/idea on issue #1."
Edit #2
This has been resolved for me with the latest versions of the installer (73, 74 and 75), but I see the discussion has evolved...
Thanks in advance!
Post edited by p6924320 on
Tagged:
Comments
Update
I have just noticed that PIA provides a new version of the installer (I was on v. 72, now it's 74).I had to revert to 17.04 for different reasons (graphics card/processor performance) and v. 74 seems to work out of the box now for 17.04.
Maybe it does for 17.10 too...
In each case, the aforementioned addition of "dns=dnsmasq" to the NetworkManager.com file fixed the problem.
So this does not look to have been fixed in v74.
Also worth mentioning that the networking icon (wifi or ethernet) doesn't always revert from a "?" to the appropriate symbol after exiting PIA using this workaround, sometimes it remains a "?" while networking is operational without PIA.
Without dnsmasq, this should also fix it:
```
echo nameserver 127.0.0.53 | sudo tee /etc/resolv.conf
```
EDIT: And the default is a symlink to /run/systemd/resolve/stub-resolv.conf which can be restored like this:
```
sudo rm /etc/resolv.conf; sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
```
I have done a clean install of v74 (pia-v74-installer-linux.tar.gz): I can get the icon in the system tray, but when I try to connect, it keeps trying for a long while, then it fails.
I've noticed there are a bunch of log files in the .pia_manager directory, which ones would be relevant here? (I've tried to eyeball them, none gave any indication of what went wrong).
Thanks for this; I had already tried this (maybe I should've mentioned that, my bad) as I had already had the same problem with 16.04.
However, I followed the instructions in that article, and I'm still finding the same issue.
The `openvpn.log` is empty.
If I do this:
I get logs to stdout, and I can see something like
Does the above help?
The connection refused in this case would be the result of OpenVPN not starting at all, so the OS just rejects the connection.
Can you generate a complete bug report for me using these instructions and give us the log ID? There's probably something weird with the OpenVPN command it generates that the binary doesn't like.
In the meantime, you should be able to get online using the NetworkManager guide instead. It's still OpenVPN, just not with PIA's GUI and extra features.
Anywhere I can go looking for it?
Also, followed the NM guide: this is truly weird: when I select one of the options, it just doesn't do anything... it just shows them OFF, I click on one (US Silicon Valley, nearest location) then nothing happens.
I am pretty much convinced there's somethins seriously borked about my system...
Update: just found this bug, maybe it's related?
Both are working fine on my end, I've even used them both (to double-hop on a known good network) at the same time to troubleshoot bottlenecks/speed issues for other threads/tickets:
The easiest route is probably to reinstall your system. It's fairly possible that jumping from 16.04 with Unity to 17.10 with a whole desktop environment change some components are missing. I had a bit of trouble getting the PIA app to run on my broken install too, in the end it was because the AppIndicator extension wasn't loaded for some reason.
It's Linux tho, if you really want to fix it I'm pretty sure you could compare the installed package list on a fresh install and yours and do some apt-fu to revert everything to how it's supposed to be. Could also be configs in your home directory from the previous systems, you could also try creating a new user and check if it works there.
systemd-resolved in itself is a bit confusing because it can be both a provider of resolv.conf, or a consumer of it. The documentation will explain it better than me: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
I won't be able to do a clean install on this system, as re-installing all the tooling I have for development etc. would be a major pain - also, this is my main personal computer and not being able to use PIA (or any VPN, apparently) is a major privacy concern for me.
Is there any more information I can provide (logs, running tests, etc.) I can provide you to try and solve the problem?
I've been running Ubuntu as my main platform for around 10 years, so I'm not exactly a newbie, but I am not familiar at all with the innards of OpenVPN and the kernel.
Thanks.
I think the easiest route would be to get NetworkManager going as I don't have code access to the PIA app, so it's as much of a black box to me as anyone else.
Usually when NetworkManager fails to prompt for a password, it's because it wasn't able to request the password from the applet over DBus so it can't connect. Try the following:
- Edit the VPN profile you want to use in /etc/NetworkManager/system-connections/ with your favorite text editor
- Change "password-flags=1" to "password-flags=0"
- Add a new section as follow:
- Save the file
- Run "sudo nmcli connection reload"
- Try connecting again
This should bypass the password prompt by embedding it directly into the config file instead of your keyring.[vpn-secrets]
password=YOUR_PASSWORD_HERE
if nothing else, you can lock it down to use Google's servers for all DNS:
that's it.
decide how you want your system to do DNS. PIA servers for DNS when VPN up? if yes, then use the two addresses pushed as the VPN comes up. Local router when VPN is down? if yes, then replace the file with one that contains "nameserver 192.168.1.1" (or whatever the address is for your local router).
i would dump all the old methods of manipulating the file in favor of whatever is the new method in my distro -- because i expect the distro will make that assumption as more updates/upgrades come out of the distro pipeline.
I have no idea why it would do that tho, I'll have to leave it running in my VM and do a bunch of connect/disconnect cycles in hope it does it to me too so I can send that to the devs.
thanks for that - I tried it, still no joy.
Is there a way to bypass the NM (I have been pretty vocal in the past about it being a piece of junk) and just use the command line?
Using NM I don't get any feedback / logs at all, so it's totally unclear what the issue may be.
Incidentally, looking at other entries in this thread, I have completely uninstalled everything; rebooted; re-installed PIA - both v66 (which used to work, but didn't) and then again with v74, which never did - but nothing still.
I think I've also cleaned up a lot of the issues in my 17.10 install, pretty much everything now works as it should, only PIA is left in this rather unsatisfactory state.
BTW - today my PIA connection from my MacOS laptop started failing too (the nameservers were not resolving anything at all) - but that's probably another story.