3

My ProtonVPN connection keeps breaking. I'm using Ubuntu 18.04. ProtonVPN informs me that the issue is with Ubuntu, they won't help me fix it, and that I should post here. This is a cross-post of this Unix SE question.

Right now, in the broken state, the two ProtonVPN device profiles proton0 and ipv6leakintrf0 are listed as "unmanaged" and "disconnected", respectively, by nmcli:

$ nmcli d
DEVICE          TYPE      STATE         CONNECTION 
wlp3s0          wifi      connected     WifiAP
ipv6leakintrf0  dummy     disconnected  --         
enp2s0          ethernet  unavailable   --         
lo              loopback  unmanaged     --         
proton0         tun       unmanaged     --

ProtonVPN support has not been able to resolve the issue after working on it for nearly two months, but they did inform me they don't support unmanaged connections. So, I'm struggling on my own to make both proton0 and ipv6leakintrf0 be "managed".

From what I can piece together from the NetworkManager configuration documentation, NetworkManager configures devices from the following sources, in order:

  1. /usr/lib/NetworkManager/conf.d/
  2. /run/NetworkManager/conf.d/
  3. /etc/NetworkManager/conf.d/
  4. /etc/NetworkManager.conf
  5. /var/lib/NetworkManager/NetworkManager-intern.conf

Within the three directories, files are parsed in their listed order. On my system, the file /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf exists and contains the following directive:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan

This appears to set all non-wifi and non-wan network devices to "unmanaged", which would explain why proton0 and probably ipv6leakintrf0 are unmanaged. However, given how poorly-designed the NetworkManager UX is, there's no way for me to be certain that subsequent configuration I don't understand isn't overriding this directive.

I searched the above configuration list for another unmanaged-devices directive and found none, so I can only assume the one in 10-globally-managed-devices.conf is the only one. In that case, it seems like I could correct the problem and make proton0 a managed device by creating a file /usr/lib/NetworkManager/conf.d/80-proton-vpn.conf with the following contents:

[device]
match-device=interface-name:proton0
managed=true

[device]
match-device=interface-name:ipv6leakintrf0
managed=true

where I've pieced the syntax together as best I can from the poor documentation linked above. I restarted network-manager. ProtonVPN worked for several days before breaking again, giving the $ nmcli d output shown above that indicates proton0 (and probably ipv6leakintrf0) are still unmanaged, despite my best efforts at changing the config.

This AskUbuntu answer indicates that the listing of a device in /etc/network/interfaces will cause it to be unmanaged by NetworkManager. In my case that does not apply, the only contents of that file are

$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

I've also tried explicitly excepting the ProtonVPN devices in 10-globally-managed-devices.conf as suggested by a comment on the Unix SE post I linked above:

[keyfile]
unmanaged-devices=*,except:type:wifi,except:type:wwan,except:interface-name:proton*,except:interface-name:ipv6leakintrf*

After restarting network-manager, this config made no change in the problem.

What else do I have to do to make these device profiles be managed by NetworkManager?

Edit

For the question "How do I set a network device to be managed?", the answer to start with is:

"Run the command

$ nmcli device set <name> managed yes

where <name> is the relevant entry under the DEVICE column of the output of $ nmcli d."

I've been working on this problem for such a soul-drainingly long time that I forgot to include the results of doing this. Here they are:

When I run

$ nmcli device set proton0 managed yes

it does not affect 'proton0' in any way. The output of $ nmcli d continues to show 'proton0' as "disconnected" (because I can't connect), and the output of $ nmcli device show continues to show 'proton0' as having GENERAL.STATE: 10 (unmanaged).

'ipv6leakintrf0' has appeared and disappeared throughout the troubleshooting process. I don't know why, but ProtonVPN support didn't find it noteworthy, so I assume it's expected. When it exists, running

$ nmcli device set ipv6leakintrf0 managed yes

has no effect. The output of $ nmcli d continues to show it as "unmanaged". When it doesn't exist, running the $ nmcli device set command returns the error Error: Device 'ipv6leakintrf0' not found., which seems normal. It currently does not exist.

extra info

Here is the 'proton0' portion of the output of $ nmcli device show:

GENERAL.DEVICE:                         proton0
GENERAL.TYPE:                           tun
GENERAL.HWADDR:                         (unknown)
GENERAL.MTU:                            1500
GENERAL.STATE:                          10 (unmanaged)
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off
Darien Marks
  • 329
  • Is it possible to try another VPN provider just for a short time to test? – David Aug 24 '21 at 11:44
  • @David Working on that with Mozilla VPN. Currently waiting on their support team to respond for a different problem installing that. – Darien Marks Aug 24 '21 at 11:47
  • 2
    I am using ProtonVPN on Ubuntu 18.04 without any problem. I have the same entries in the 10-globally-managed.devices.conf and /etc/network/interfaces, so I doubt that this is the problem. I assume you went through log files and disabling any additional functions like Killswitch, Netshield, Split Tunneling with Proton support already? Have you tried downloading their *.ovpn config files and loading those directly with openvpn? – Sebastian Aug 24 '21 at 12:21
  • @Sebastian I've done all of ProtonVPN's procedures many times. They suggested the OpenVPN thing, too, but I haven't tried it because that's not what I'm paying them for and because I expect OpenVPN to be the same type of user-hostile nightmare all of my dealings with unfamiliar open source software always turn out to be. – Darien Marks Aug 24 '21 at 12:54
  • @sancho.sReinstateMonicaCellio Thank you for compiling that information, but I can't tell that you're suggesting anything. You link to the Udev Properties portion of the documentation, but as far as I know, I'm already forcing a managed connection via Network Manager configuration, so without a more explicit explanation, I don't know what you want me to do – Darien Marks Sep 01 '21 at 13:19
  • Well, I was actually suggesting a couple of things:
    1. Compare your 10-globally-managed-devices.conf, try using my version, post if you see anything worth reporting.
    2. Compare your /run/NetworkManager/devices/... files, post if you see anything worth reporting.
    3. Post the output of the command I listed.
    4. Try using nmcli device set..., post if you see anything worth reporting.

    And I added a 5th action. If you have further doubts, please comment.

     – sancho.s ReinstateMonicaCellio Sep 01 '21 at 18:45
  • PS: Sometimes an answer comes in a full, detailed, and specific list of commands/actions. Sometimes it comes as hints, partly because of the lack of full info on your system or because of a lack of absolute knowledge on the answerer. These answers may report possible directories/files to look for, information that has to be compared with what you have, etc., and that can set you on track to the final solution (requiring further research on the side of the OP). I wonder why you do not see this as: 1) a valid answer, 2) useful. Plus, posting requested info can help others help you. – sancho.s ReinstateMonicaCellio Sep 01 '21 at 18:50

  • There is no relevant difference between your 10-globally-managed-devices.conf and mine.

  • Instead of files called 18 and 19, I have files with different numbers in the /run/NetworkManager/devices/ directory. That's not unexpected, since I imagine they're named randomly on each system. What I need is a way to determine which ones are related to ProtonVPN. Since my VPN doesn't work, I can't compare files between the connected and disconnected states like you can. Lacking any other method, I don't know what I'm comparing, so this is a dead end.

    • – Darien Marks Sep 02 '21 at 12:56
  • The output of $ nmcli device show is over 160 lines, and I'm certain most of those are not relevant. Including this would add a massive amount of clutter to the page and risk accidentally posting sensitive information, since the output is largely gibberish to me and I don't know what information it represents.
    • – Darien Marks Sep 02 '21 at 12:57
  • (continued) If there's a particularly useful subset of lines I could vet and post, I'd be happy to. I've edited my post to contain the 'proton0' section, for example. But better yet, you could explain what information I'm looking for and how it helps answer the question "How do I set a connection to be managed?", which would help not only me, but anyone in the future who finds this page by having the same question, and who can't all post their output for your review.
    • – Darien Marks Sep 02 '21 at 12:58