Can no longer connect to internet when I exit PIA app (Ubuntu 16.04)

I haven't had any problems after install v62 for Linux until today when I disconnected and closed the app to discover I could no longer connect to the internet. I can still connect to the internet when PIA is active.

How do fix this so I can access the internet when I'm not running PIA?
«1

Comments

  • I had the same problem with Win 10 and v62 of PIA - all the usual (Winodws) fixes wouldn't work for me.  I went back to v61 and it works fine. 
    When I get time I'll try installing v62 over v61 (instead of uninstalling like I did) and see if that helps.
  • nedder said:
    I haven't had any problems after install v62 for Linux until today when I disconnected and closed the app to discover I could no longer connect to the internet. I can still connect to the internet when PIA is active.

    How do fix this so I can access the internet when I'm not running PIA?
    I had the same problem with v60 with Ubuntu 15.10. It only happened when VPN Kill switch was on (if I remember right).
  • Not sure about the OP, but my problems were happening with the killswitch on or off.
  • Hello nedder,

    Thanks for getting in touch regarding this concern. The killswitch is intended to stop your internet from working if by chance the VPN stops working. If you disconnect from the VPN with the killswitch still enabled, this will remove your connection, so you will need to disable the killswitch when your finished of the VPN in order to restore your connection.

    Here is how we can check to see if the killswitch is still enabled:

    • Disconnect from the VPN
    • Click the PIA icon and click "settings"
    • Click on Advanced
    • Check if the Killswitch box is checked
  • Blue23 said:

    Hello nedder,

    Thanks for getting in touch regarding this concern. The killswitch is intended to stop your internet from working if by chance the VPN stops working. If you disconnect from the VPN with the killswitch still enabled, this will remove your connection, so you will need to disable the killswitch when your finished of the VPN in order to restore your connection.

    Here is how we can check to see if the killswitch is still enabled:

    • Disconnect from the VPN
    • Click the PIA icon and click "settings"
    • Click on Advanced
    • Check if the Killswitch box is checked
    I am familiar with the killswitch. When I turn off the kill switch and exit the program I still cannot connect to the internet. In windows I know how to get the internet working again but in Ubuntu I have no idea. How do I fix this when the above steps do not work?
  • crape said:
    That seems to be a solution for a windows setup.
  • edited November 2017
    Has anyone found a solution for this problem? I have the exact same issue, on Ubuntu 16.04 I installed PIA v75 and (Kill Switch is OFF) but I cannot browse the web (Server not Found) says firefox. Even though I see a strong connection to my wifi. When I connect to a VPN server through PIA I can once again work on the internet normally.

    Edit:
    FYI I now am able to connect regularly to the internet. The solution I found feels like overkill... Seeing as there are several threads discussing how the DNS is the source of the problem and that there is a file /etc/resolv.conf which should be edited, I looked for that file (didn't have it).
    Then I found the below line, which fixed my problem, after a google search:

    sudo su
    apt-get remove --purge resolvconf && apt-get install resolvconf
    then I ran:

    apt-get update --fix-missing

    After a prompt from apt to do so.

    Source:
    https://askubuntu.com/questions/134121/how-to-restore-recreate-etc-resolv-conf-files


  • @_mire_ ; That's a bit odd that you'd need to do this. PIA is supposed to backup the existing /etc/resolv.conf into /tmp, and resolvconf should already reset the resolv.conf anyway after a reboot. Have you tried rebooting or reconnecting your main connection via the network menu?
  • Max-P said:
    @_mire_ ; That's a bit odd that you'd need to do this. PIA is supposed to backup the existing /etc/resolv.conf into /tmp, and resolvconf should already reset the resolv.conf anyway after a reboot. Have you tried rebooting or reconnecting your main connection via the network menu?
    ^^^That is the problem right there.^^^

    I just spent part of my day troubleshooting my Ubuntu notebook because of the PIA client.  The reason it's breaking is because the dhclient service dynamically creates and modifies the resolv.conf file.  The /etc/resolv.conf file is supposed to be a symbolic link to /run/resolvconf/resolv.conf.  I didn't realize anything was wrong until I connected my notebook to another network and DNS was broken.  The PIA client backed up the /etc/resolv.conf file which was generated when connected to my home network while it was a symbolic link.  After running PIA, rather than restore the symbolic link, it restores the backup as a file, which broke DNS and was why I couldn't connect to anything.  The dhclient service was updating the file in /run/resolvconf, but since the file in /etc was no longer linked to it, it was trying to use DNS servers for a network I was no longer connected to.

    it took me a while to find what was wrong, after that it was easy to fix once I realized what happened.  All you have to do is re-create the symbolic link to /run/resolvconf/resolv.conf in /etc and run dhclient to re-create the file.

    This is something that needs to be fixed in the PIA client.  Rather than backing up and creating a new file, then restoring the file after exiting, you should just be modifying the existing file, then when after disconnecting call dhclient to re-create the file for what is needed on the current local network.
  • @NJC2 It backups the symbolic link too. It essentially moves the file to /tmp and then move it back, so it doesn't matter what kind of file it is (it could even be a directory). It would still move it to /tmp and then back.

    What I can see happening however is that something could detect the symlink is no longer there and fallback to some sort of weird older behavior. In all fairness, Ubuntu really looks like they made their DNS solution a lot more complicated than necessary in order to support all the different methods of setting DNS and in particular upgrades from older versions. I think it's the fourth time Ubuntu changes the way it does DNS so far...

    But yes I definitely agree the app shouldn't break it. I still haven't quite figured how it happens yet. The good news is, that part is likely going to have a rewrite soon-ish so hopefully it goes away with it. The correct way to set the DNS on Ubuntu would be to either use resolvconf instead of overriding it, or using systemd-resolved depending on whichever the user is using.
  • interesting. my Ubuntu 17.10 box has a symlink from /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
  • martouf said:
    interesting. my Ubuntu 17.10 box has a symlink from /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf.
    Yup!
    Max-P said:
    I think it's the fourth time Ubuntu changes the way it does DNS so far...

    It's really like Ubuntu doesn't know which one it wants to use, which is the core of the resolv.conf issue with PIA. We basically have to handle all the different ways DNS could be setup, and as we've seen in this thread even backing up the symlink seems to not reliably work :/
  • Max-P said:
    @NJC2 It backups the symbolic link too. It essentially moves the file to /tmp and then move it back, so it doesn't matter what kind of file it is (it could even be a directory). It would still move it to /tmp and then back.

    What I can see happening however is that something could detect the symlink is no longer there and fallback to some sort of weird older behavior. In all fairness, Ubuntu really looks like they made their DNS solution a lot more complicated than necessary in order to support all the different methods of setting DNS and in particular upgrades from older versions. I think it's the fourth time Ubuntu changes the way it does DNS so far...

    But yes I definitely agree the app shouldn't break it. I still haven't quite figured how it happens yet. The good news is, that part is likely going to have a rewrite soon-ish so hopefully it goes away with it. The correct way to set the DNS on Ubuntu would be to either use resolvconf instead of overriding it, or using systemd-resolved depending on whichever the user is using.
    Did an older version of PIA not backup the symlink?  After I re-linked it, it's now properly backing up the link and restoring it.
  • @NJC2 It's a bit weirder than this. It backups the link to /tmp, which is lost between reboots. So the issue is more that if you end up shutting down your computer without PIA having a chance to disconnect properly and restore it, upon reboot the backup file is lost and PIA's DNS are still in /etc/resolv.conf as a normal text file. As a result, NetworkManager thinks it should be managing this file and the system goes in the weird broken state.

    Basically to reproduce just power off your machine by unplugging it or holding the power button. It will boot back with broken DNS.
  • Does somebody have a fix for this? I've tried the apt purge and reinstall mentioned, but that did not help.
  • @RuggedPineapple Haven't tested it (I'm on 17.10), but this should do it for 16.04:

    sudo rm /etc/resolv.conf
    sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
    You might need to reconnect your network in NetworkManager (or reboot) for it to work and resolvconf to update the config.
  • Max-P said:
    @RuggedPineapple Haven't tested it (I'm on 17.10), but this should do it for 16.04:

    sudo rm /etc/resolv.conf
    sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
    You might need to reconnect your network in NetworkManager (or reboot) for it to work and resolvconf to update the config.
    Im on 17.10 as well (xubuntu), am I hosing anything doing this on that?
  • @RuggedPineapple For 17.10 it's 
    sudo rm /etc/resolv.conf
    sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

    @d4rkcat I'd say it depends. If you base yourself on Ubuntu, it's a horrible, horrible mess. On saner distros it's less of an issue. It's like systemd in the Debian family: even as someone that loves systemd, I can't stand it on Debian because the implementation is just so aweful. It's a bit the same for NM: I've had my fair share of trouble with it, but I've never had any problem with it on Arch or any other distro that ships it more "vanilla". By default it just dumps DNS in resolv.conf the good ol' way.
  • edited January 2018
    I had this same issue on Ubuntu 17.10: When PIA is connected everything is fine.  When it's disconnected or closed, I can't connect to the internet.

    • I'm on PIA's Ubuntu client v75
    • Kill Switch is off

    When I'm connected:
    > readlink /etc/resolv.conf
    (no output - not a symlink)
    
    > cat /etc/resolv.conf
    nameserver 209.222.18.222
    nameserver 209.222.18.218
    
    > cat /run/resolvconf/resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    # 127.0.0.53 is the systemd-resolved stub resolver.
    # run "systemd-resolve --status" to see details about the actual nameservers.
    
    nameserver 127.0.0.53
    
    > readlink /tmp/pia_resolv_conf_link 
    /run/NetworkManager/resolv.conf
    
    > cat /tmp/pia_resolv_conf_link 
    # Generated by NetworkManager
    nameserver 127.0.1.1
    

    When I'm disconnected:
    ╰○ readlink /etc/resolv.conf
    /run/NetworkManager/resolv.conf
                                                                                                             
    > cat /etc/resolv.conf
    # Generated by NetworkManager
    nameserver 127.0.1.1
                                                                                                             
    > cat /run/resolvconf/resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    # 127.0.0.53 is the systemd-resolved stub resolver.
    # run "systemd-resolve --status" to see details about the actual nameservers.
    
    nameserver 127.0.0.53
                                                                                                             
    > readlink /tmp/pia_resolv_conf_link 
    /run/NetworkManager/resolv.conf
                                                                                                             
    > cat /tmp/pia_resolv_conf_link 
    # Generated by NetworkManager
    nameserver 127.0.1.1

    When PIA is closed, same results as when I'm disconnected.

    I tried the recommended fix while PIA was connected and it didn't work (for reasons I now understand). Recreating the symlink while PIA is disconnected resolved the issue for me.
  • As an extra note to this, this issue was officially resolved in v76 yesterday as I gave my approval for it :) I'm expecting v76 to come out really soon with this issue finally resolved (no pun intended) in full. v76 will integrate with systemd-resolved and no longer touch the symlink at all unless it absolute needs to.
  • bottom line: know what a sane resolv.conf looks like and when there's trouble --> smack it upside the head and put a sane one in
  • @Max-P i'm on v76 (upgraded from v75, not clean install) and still had to do it manualy the first time, later it worked automatically.
  • awesome! glad it's behaving now
  • Yeah, v76 doesn't fix what's already broken, but once it's fixed it should work fine and not break it anymore :)
  • I am working in Linux 17.10 and am having the same issue, currently running PIA v75. I have read over all of the comments and to no avail. Do we have an update as to when an update will be pushed for this to be fixed? Or do we know how to fix it?

    I have attempted to uninstall PIA to see if that would work and when I did the internet still didn't... I fear that this may have messed everything up network wise.
  • For those looking for v76, you have to opt-in to a beta program right now to get access to it.  For more details see this post:

    https://www.privateinternetaccess.com/forum/discussion/30113/announcing-the-new-beta-program-for-the-desktop-application
  • Confirming: After signing up for the Linux desktop beta and installing v76 beta (9b8d0c5), and fixing the etc/resolv.conf symlink one last time, everything seems to be working!
  • <thumbsup>good news</thumbsup>
Sign In or Register to comment.