PIA on Ubuntu 17.10

edited November 16 in Linux VPN Setup Posts: 8
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.

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:

  1. Remove the nohup and env calls altogether - didn't work
  2. Remove the env call and leave nohup - didn't work
  3. 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
This is a mistery to me.
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=dnsmasq
After 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  :D

You can verify your DNS by typing:

nmcli device show [your nework interface in use] | grep IP4.DNS
Just 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
«1

Comments

  • Posts: 265
    Both of these issues should have already been fixed in v74! Make sure you're using the latest (and optionally delete your ~/.pia_manager folder to be sure nothing is left). You also need to make sure to have Ubuntu's appindicator extension enabled as the app still relies on that to work. If you're on vanilla Gnome, you'll have to use the TopIcons Plus extension instead to provide a legacy tray.


  • Posts: 8

    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...
  • Posts: 265
    Yup :) v73 fixed 17.04, and we released v74 shortly after with additional fixes for 17.10. Both should work out of the box now with v74.
  • Posts: 8
    Max-P said:
    Yup :) v73 fixed 17.04, and we released v74 shortly after with additional fixes for 17.10. Both should work out of the box now with v74.
    Sorry, it seems I updated my thread before noticing your response. Thanks very much for that. I had to revert to 17.04 anyway due to unrelated issues, but it's good to know the installer is still maintained and improving.
  • Posts: 2
    I am able to confirm that issue #2 above continues to be a problem under 17.10 with v74, specifically, DNS works only if PIA is on.  Just experienced this on two fresh installs of 17.10 and PIA v74 on separate Thinkpad T530 units, networking was fine until PIA was installed, PIA worked fine, but when exiting PIA DNS would no longer work.  Yes, I am aware that internet killswitch needs to be disabled when exiting PIA, and yes, I have legacy tray enabled via TopIcons Plus gnome extension. 

    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.
  • Posts: 2
    whoops, make that NetworkManager.conf not NetworkManager.com in my previous post, sorry 'bout that.
  • edited October 24 Posts: 265
    I'll have to do some more testing on my end to find out why it does that, but it would look like PIA failed to revert (or failed to backup) the resolv.conf. Ubuntu 17.10 uses systemd-resolved not dnsmasq, so reaolv.conf is supposed to be a symlink.

    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
    ```
    Post edited by Max-P on
  • Posts: 8
    I have just upgraded to 17.10 (from 16.04LTS) and now PIA no longer seems to work.
    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).
  • Posts: 265
    @mmassenz ; Those are the typical symptoms of a conflict with Ubuntu's encrypted home directories. I would recommend having a look at this article to see if this is your case, and if so how to fix it.
  • Posts: 8
    Max-P said:
    @mmassenz ; Those are the typical symptoms of a conflict with Ubuntu's encrypted home directories. I would recommend having a look at this article to see if this is your case, and if so how to fix it.

    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:
    cd /opt/pia_manager
    ./pia_manager/run.sh
    
    I get logs to stdout, and I can see something  like

    ip6tables: No chain/target/match by that name.
    ip6tables: No chain/target/match by that name.
    ip6tables: No chain/target/match by that name.
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    security error
    ....
    ip6tables: No chain/target/match by that name.
    ip6tables: No chain/target/match by that name.
    net.ipv6.conf.all.disable_ipv6 = 0
    net.ipv6.conf.default.disable_ipv6 = 0
    net.ipv6.conf.lo.disable_ipv6 = 0
    ip6tables: No chain/target/match by that name.
    ip6tables: No chain/target/match by that name.
    ip6tables: No chain/target/match by that name.
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    security error
    

    Does the above help?
  • edited October 24 Posts: 8
    $ tail -f pia_manager.log
    
    yields this:
    [2017-10-24T05:10:34.465Z]  #4325/12425060 |OpenvpnManager| Connecting to OpenVPN
    [2017-10-24T05:10:34.466Z]  #4325/12425060 |OpenvpnManager| #Errno::ECONNREFUSED: Connection refused - connect(2)
    /home/marco/.pia_manager/pia_manager/openvpn_manager.rb:1334:in `initialize'
    /home/marco/.pia_manager/pia_manager/openvpn_manager.rb:1334:in `open'
    /home/marco/.pia_manager/pia_manager/openvpn_manager.rb:1334:in `block (2 levels) in cmd'
    /home/marco/.pia_manager/pia_manager/pia_common.rb:314:in `timeout'
    /home/marco/.pia_manager/pia_manager/openvpn_manager.rb:1332:in `block in cmd'
    :10:in `synchronize'
    /home/marco/.pia_manager/pia_manager/openvpn_manager.rb:1328:in `cmd'
    /home/marco/.pia_manager/pia_manager/openvpn_manager.rb:1361:in `block in start_connection_status_polling'
    /home/marco/.pia_manager/pia_manager/pia_common.rb:31:in `block in safe'
    [2017-10-24T05:10:34.479Z]  #4325/12473660 |OpenvpnManager| Management didn't come up
    [2017-10-24T05:10:34.479Z]  #4325/12473660 |OpenvpnManager| hardkill
    
    So it tries to connect, but "connection refused" - if only we knew why?
    Post edited by mmassenz on
  • Posts: 265
    That's odd. Everything from the console output is normal except the "security error" part, which essentially means that PIA's OpenVPN wrapper refused to start because it thinks the command is unsafe or has been tampered with. That's the first time I see that security error that's not me toying with it to find flaws in QA.

    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.
  • edited October 24 Posts: 8
    I followed the instructions to email a log; never got the second dialog showing the log ID.
    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?
    Post edited by mmassenz on
  • Posts: 265
    @mmassenz ; That's even stranger. Something indeed doesn't look quite right about your system. I remember having loads of trouble when updating from 17.04 to 17.10 so I would suggest maybe booting off the live CD/USB and try in the live environment if you have any of those issues?

    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.
  • Posts: 7
    I've been having the exact same issue as jfinkler. Couldn't figure it out at first. Once I upgraded from Ubuntu Gnome 17.04 to Ubuntu 17.10, I no longer had an internet connection. I started up Virtualbox to get a document I had left on windows and wala, it connected to the internet (??) even though I had no connection on my Ubuntu host. So I shut that down and tried PIA. It connected. So I jumped on Ubuntu forums looking for info. Found a thread on askubuntu about removing the resolv.conf file and recreating it. It works, but then it doesn't stick. Have to do it every time I turn PIA off. 
    But from what I'm reading, it's not specific to PIA. Some users with other VPN's have the same issue. So maybe it's an Ubuntu bug. I'll try totally removing PIA and reinstalling soon. Just tried adding the dnsmasq fix above and i'm back on my ISP again. 
    Here's the commands to do that for reference. Similar to what Max-P posted above.
    sudo rm /etc/resolv.conf
    sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
    
    sudo resolvconf -u
    or can just use:
    sudo dpkg-reconfigure resolvconf
    Say yes to "prepare /etc/resolve.conf for dynamic updates?"
    
    sudo reboot
  • Posts: 265
    @beameup ; Yeah, those should work too. There are currently no less than three ways to handle DNS on Linux right now, and Ubuntu has gone through all three in the last couple releases:
    1. There the original, old way that relies entirely on putting the DNS servers directly in /etc/resolv.conf
    2. The dnsmasq caching way (since 16.04 iirc? Haven't used Ubuntu myself in a long time). This is what NetworkManager also uses by default as well, and I think this persists after doing an upgrade. So, coming from an older version, your fix is the one to use.
    3. The systemd-resolved way (the newest, which Ubuntu started using in 17.10 and maybe 17.04), which is what my fix addresses.
  • Posts: 7
    So you think it would be better for me to remove dnsmasq from the NM config file and try your fix? 
    I see the systemd-resolved thing loading at boot-up. Maybe I'm confusing network-manager :)
    The machine I use has been continually upgraded since 14.04 I think. Has never been clean installed since new.
    I had initially set up PIA using the OpenVPN method. I just removed that while troubleshooting as I have been using the app. 
    So I probably have remnants hanging around.
  • Posts: 269
    yes, i think the suggestion is to make configuration adjustments so that the PIA software can rely on the new systemd-resolved mechanism
  • Posts: 265
    It should work either way, the app overrides resolved anyway. All three ways are correct ways to do it, I was just pointing out what are the options and what the default is in a fresh 17.10 install. My 17.04->17.10 upgrade used dnsmasq too so it's not like it has to be resolved.

    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
  • Posts: 7
    Thanks. It's filed as an openvpn bug BTW:

  • Posts: 8
    @Max-P - that's really disappointing.
    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.
  • Posts: 265
    @mmassenz Sure, we can have a look and see if we can get it to work.

    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:

    1. Edit the VPN profile you want to use in /etc/NetworkManager/system-connections/ with your favorite text editor
    2. Change "password-flags=1" to "password-flags=0"
    3. Add a new section as follow:
      [vpn-secrets]
      password=YOUR_PASSWORD_HERE
    4. Save the file
    5. Run "sudo nmcli connection reload"
    6. Try connecting again
    This should bypass the password prompt by embedding it directly into the config file instead of your keyring.
  • Posts: 269
    i looked at the bug report. folks, DNS configuration is not complicated. resolv.conf either does or does not have at least one entry telling your system the right place to go to resolve a name to an address.

    if nothing else, you can lock it down to use Google's servers for all DNS:

    nameserver 8.8.8.8
    nameserver 8.8.4.4

    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 started getting this "security error" problem today too. I'm on ubuntu 17.04. It happened spontaneously, I was connected to PIA, I disconnected leaving the tray app running, after about 10 minutes I tried to reconnect and it would not work. I was running v73 so I upgraded to v74, that did not fix it. Went through a reboot cycle and it still was not fixed. I manually rolled back the last batch of software updates, and still no joy. I can manually run openvpn without any problems. Its just the gui that's broken. I verified that openvpn_launcher.64 is producing the "security error" message.
  • Posts: 265
    @AnkleBiter That's rather strange. Can you try deleting the directory entirely (rm -r ~/.pia_manager), reboot and then try reinstalling? For it to do that suddenly with no reason and to persist even with a rollback of the software updates it sounds like something in it got stuck... Never seen that one.
  • No effect. I even wiped ~/.config/Private Internet Access/ too
  • Now its working. I had reinstalled before rebooting. When I reinstalled after rebooting that seems to have fixed it.
  • Posts: 265
    Awesome! Yeah, the order was a bit important. What I think happens is that PIA normally copies backup copies of a bunch of files into /tmp and something probably got stuck. Since /tmp is in RAM, this specific order ensures everything PIA has been removed, that it cannot be running anymore and that /tmp will be clean and everything else like /etc/resolv.conf back to system defaults.

    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.
  • I hope you can automate that. I easily do 10+ disconnect/reconnects nearly every day and I don't think I've seen this particular failure in the 2+ years I've been using PIA. However, I upgraded to v73 on Oct 15 so it had been only about 2 weeks on that version.
  • edited October 28 Posts: 8
    @Max-P
    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.
    Post edited by mmassenz on
Sign In or Register to comment.