Proton VPN Zombie Kill Switch

Ask Fedora
, ,
1

I’ve encountered a strange bug and need some help trying to fix it. I’m using up to date Fedora 43 KDE Desktop, and I have both proton-vpn-cli and proton-vpn-gnome-desktop.

At some point I enabled the Kill Switch toggle in the GUI. While troubleshooting some network issues, I turned off the kill switch and re-connected to the VPN in the GUI. Now any time I connect, using either the CLI or the GUI, the kill switch connection is re-established. I can’t kill it!

I’ve tried the following:

I removed the kill switch connection using nmcli. It didn’t change anything.

  • I deleted all Proton files in .config and .cache, removed all Proton packages and reinstalled. Didn’t change anything. In fact, it still remembered my login.

  • I believe the culprit is system-wide, as when I logged into the root account on my computer, Proton VPN was already logged in and ready to connect.

I’m at my wits’ end. I’ve been using Arch quite happily since 2013 (I only recently switched to Fedora), yet I’m still not very experienced at advanced troubleshooting. I’d appreciate some advice regarding where to look in order to discover why the kill switch continues to re-engage.

Thanks in advance!

ekard

Here is a journalctl excerpt recorded while executing protonvpn -v connect in the CLI:

~$ journalctl -fu NetworkManager
Mar 18 15:38:09 fedora nm-openvpn[21864]: SIGTERM received, sending exit notification to peer
Mar 18 15:38:10 fedora NetworkManager[1762]: <info>  [1773873490.0103] device (ipv6leakintrf0): state change: activated -> deactivating (reason 'connection-removed', managed-type: 'full')
Mar 18 15:38:10 fedora NetworkManager[1762]: <info>  [1773873490.0114] audit: op="connection-delete" uuid="7244036a-4cf4-4443-b4cd-2f24ecafc6a7" name="pvpn-killswitch-ipv6" pid=12099 uid=1000 result="success"
Mar 18 15:38:10 fedora NetworkManager[1762]: <info>  [1773873490.0141] device (tun0): state change: activated -> unmanaged (reason 'unmanaged', managed-type: 'removed')
Mar 18 15:38:10 fedora NetworkManager[1762]: <info>  [1773873490.0159] policy: set '[*Redacted: My Wifi SSID*]' (wlp0s20f3) as default for IPv6 routing and DNS
Mar 18 15:38:10 fedora nm-openvpn[21864]: SIGTERM[soft,exit-with-notification] received, process exiting
Mar 18 15:38:10 fedora NetworkManager[1762]: <info>  [1773873490.0215] device (ipv6leakintrf0): state change: deactivating -> disconnected (reason 'connection-removed', managed-type: 'full')
Mar 18 15:38:10 fedora NetworkManager[1762]: <info>  [1773873490.0391] device (ipv6leakintrf0): state change: disconnected -> unmanaged (reason 'user-requested', managed-type: 'removed')
Mar 18 15:38:10 fedora NetworkManager[1762]: <warn>  [1773873490.0409] dns-sd-resolved[d3156b5df8476810]: send-updates SetLinkDomains@20 failed: GDBus.Error:org.freedesktop.resolve1.NoSuchLink: Link 20 not known
Mar 18 15:38:12 fedora NetworkManager[1762]: <info>  [1773873492.4301] audit: op="statistics" interface="wlp0s20f3" ifindex=2 args="2000" pid=2950 uid=1000 result="success"
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5111] manager: (pvpnksintrf0): new Dummy device (/org/freedesktop/NetworkManager/Devices/30)
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5121] device (pvpnksintrf0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5130] audit: op="connection-add" uuid="a01ca2e3-7949-4927-8c34-db524ca31945" name="pvpn-killswitch" pid=24111 uid=1000 result="success"
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5136] device (pvpnksintrf0): state change: unavailable -> disconnected (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5139] policy: auto-activating connection 'pvpn-killswitch' (a01ca2e3-7949-4927-8c34-db524ca31945)
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5141] device (pvpnksintrf0): Activation: starting connection 'pvpn-killswitch' (a01ca2e3-7949-4927-8c34-db524ca31945)
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5141] device (pvpnksintrf0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5143] device (pvpnksintrf0): state change: prepare -> config (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5272] device (pvpnksintrf0): state change: config -> ip-config (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5276] policy: set 'pvpn-killswitch' (pvpnksintrf0) as default for IPv4 routing and DNS
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5277] manager: NetworkManager state is now CONNECTING
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5277] policy: set 'pvpn-killswitch' (pvpnksintrf0) as default for IPv6 routing and DNS
Mar 18 15:38:42 fedora NetworkManager[1762]: <warn>  [1773873522.5307] dns-sd-resolved[d3156b5df8476810]: send-updates SetLinkDNS@25 failed: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid DNS server address
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5314] device (pvpnksintrf0): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5610] device (pvpnksintrf0): state change: ip-check -> secondaries (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5612] device (pvpnksintrf0): state change: secondaries -> activated (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5614] manager: NetworkManager state is now CONNECTED_GLOBAL
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5622] device (pvpnksintrf0): Activation: successful, device activated.
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5953] manager: (pvpnrouteintrf0): new Dummy device (/org/freedesktop/NetworkManager/Devices/31)
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5967] device (pvpnrouteintrf0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.5986] audit: op="connection-add" uuid="36219528-5497-425b-ba39-903698e41864" name="pvpn-routed-killswitch" pid=24111 uid=1000 result="success"
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6000] device (pvpnrouteintrf0): state change: unavailable -> disconnected (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6009] policy: auto-activating connection 'pvpn-routed-killswitch' (36219528-5497-425b-ba39-903698e41864)
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6013] device (pvpnrouteintrf0): Activation: starting connection 'pvpn-routed-killswitch' (36219528-5497-425b-ba39-903698e41864)
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6013] device (pvpnrouteintrf0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6021] device (pvpnrouteintrf0): state change: prepare -> config (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6113] device (pvpnrouteintrf0): state change: config -> ip-config (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <warn>  [1773873522.6187] dns-sd-resolved[d3156b5df8476810]: send-updates SetLinkDNS@25 failed: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Invalid DNS server address
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6191] device (pvpnrouteintrf0): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6204] device (pvpnrouteintrf0): state change: ip-check -> secondaries (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6205] device (pvpnrouteintrf0): state change: secondaries -> activated (reason 'none', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6207] device (pvpnrouteintrf0): Activation: successful, device activated.
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6366] device (pvpnksintrf0): state change: activated -> deactivating (reason 'connection-removed', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6373] audit: op="connection-delete" uuid="a01ca2e3-7949-4927-8c34-db524ca31945" name="pvpn-killswitch" pid=24111 uid=1000 result="success"
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6379] device (pvpnksintrf0): state change: deactivating -> disconnected (reason 'connection-removed', managed-type: 'full')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6517] policy: set '[*Redacted: My Wifi SSID*]' (wlp0s20f3) as default for IPv4 routing and DNS
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6517] policy: set 'pvpn-routed-killswitch' (pvpnrouteintrf0) as default for IPv6 routing and DNS
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.6816] device (pvpnksintrf0): state change: disconnected -> unmanaged (reason 'user-requested', managed-type: 'removed')
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.8585] audit: op="connection-add" uuid="517133aa-07e8-4735-a678-17d69b404cb9" name="*Redacted: My Proton Server Name*" pid=24111 uid=1000 result="success"
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.8831] vpn[0x557b4f1da740,517133aa-07e8-4735-a678-17d69b404cb9,"*Redacted: My Proton Server Name*"]: starting openvpn
Mar 18 15:38:42 fedora NetworkManager[1762]: <info>  [1773873522.8835] audit: op="connection-activate" uuid="517133aa-07e8-4735-a678-17d69b404cb9" name="*Redacted: My Proton Server Name*" pid=24111 uid=1000 result="success"
Mar 18 15:38:42 fedora nm-openvpn[24443]: OpenVPN 2.6.19 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
Mar 18 15:38:42 fedora nm-openvpn[24443]: library versions: OpenSSL 3.5.4 30 Sep 2025, LZO 2.10
Mar 18 15:38:42 fedora nm-openvpn[24443]: DCO version: N/A
Mar 18 15:38:42 fedora nm-openvpn[24443]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 18 15:38:43 fedora nm-openvpn[24443]: TCP/UDP: Preserving recently used remote address: [AF_INET]*Redacted: My Proton IP*
Mar 18 15:38:43 fedora nm-openvpn[24443]: UDPv4 link local: (not bound)
Mar 18 15:38:43 fedora nm-openvpn[24443]: UDPv4 link remote: [AF_INET]*Redacted: My Proton IP*
Mar 18 15:38:43 fedora nm-openvpn[24443]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mar 18 15:38:43 fedora nm-openvpn[24443]: [*Redacted: My Proton VPN IP*] Peer Connection Initiated with [AF_INET]*Redacted: My Proton IP*
Mar 18 15:38:44 fedora nm-openvpn[24443]: NOTE: setsockopt TCP_NODELAY=1 failed
Mar 18 15:38:44 fedora nm-openvpn[24443]: TUN/TAP device tun0 opened
Mar 18 15:38:44 fedora nm-openvpn[24443]: /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 24434 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_36 --tun -- tun0 1500 0 10.96.0.37 255.255.0.0 init
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2023] manager: (tun0): new Tun device (/org/freedesktop/NetworkManager/Devices/32)
Mar 18 15:38:44 fedora nm-openvpn[24443]: UID set to nm-openvpn
Mar 18 15:38:44 fedora nm-openvpn[24443]: GID set to nm-openvpn
Mar 18 15:38:44 fedora nm-openvpn[24443]: Capabilities retained: CAP_NET_ADMIN
Mar 18 15:38:44 fedora nm-openvpn[24443]: Initialization Sequence Completed
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2356] device (tun0): state change: unmanaged -> unavailable (reason 'connection-assumed', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2365] device (tun0): state change: unavailable -> disconnected (reason 'connection-assumed', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2369] device (tun0): Activation: starting connection 'tun0' (983d52f7-c85a-444a-a5f8-f090d097e478)
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2370] device (tun0): state change: disconnected -> prepare (reason 'none', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2371] device (tun0): state change: prepare -> config (reason 'none', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2372] device (tun0): state change: config -> ip-config (reason 'none', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2374] policy: set '*Redacted: My Proton Server Name*' (tun0) as default for IPv4 routing and DNS
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2613] device (tun0): state change: ip-config -> ip-check (reason 'none', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2647] manager: (ipv6leakintrf0): new Dummy device (/org/freedesktop/NetworkManager/Devices/33)
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2665] device (ipv6leakintrf0): state change: unmanaged -> unavailable (reason 'managed', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2678] audit: op="connection-add" uuid="6c9e2490-33d5-4511-a18f-b276bb6d1f40" name="pvpn-killswitch-ipv6" pid=24111 uid=1000 result="success"
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2689] device (tun0): state change: ip-check -> secondaries (reason 'none', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2693] device (ipv6leakintrf0): state change: unavailable -> disconnected (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2707] device (tun0): state change: secondaries -> activated (reason 'none', managed-type: 'external')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2716] device (tun0): Activation: successful, device activated.
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2724] policy: auto-activating connection 'pvpn-killswitch-ipv6' (6c9e2490-33d5-4511-a18f-b276bb6d1f40)
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2728] device (ipv6leakintrf0): Activation: starting connection 'pvpn-killswitch-ipv6' (6c9e2490-33d5-4511-a18f-b276bb6d1f40)
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2729] device (ipv6leakintrf0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2738] device (ipv6leakintrf0): state change: prepare -> config (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.2941] device (ipv6leakintrf0): state change: config -> ip-config (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3034] device (ipv6leakintrf0): state change: ip-config -> ip-check (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3043] device (ipv6leakintrf0): state change: ip-check -> secondaries (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3044] device (ipv6leakintrf0): state change: secondaries -> activated (reason 'none', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3048] device (ipv6leakintrf0): Activation: successful, device activated.
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3172] device (pvpnrouteintrf0): state change: activated -> deactivating (reason 'connection-removed', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3180] audit: op="connection-delete" uuid="36219528-5497-425b-ba39-903698e41864" name="pvpn-routed-killswitch" pid=24111 uid=1000 result="success"
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3239] device (pvpnrouteintrf0): state change: deactivating -> disconnected (reason 'connection-removed', managed-type: 'full')
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3255] policy: set 'pvpn-killswitch-ipv6' (ipv6leakintrf0) as default for IPv6 routing and DNS
Mar 18 15:38:44 fedora NetworkManager[1762]: <info>  [1773873524.3405] device (pvpnrouteintrf0): state change: disconnected -> unmanaged (reason 'user-requested', managed-type: 'removed')
Mar 18 15:38:51 fedora NetworkManager[1762]: <info>  [1773873531.7905] audit: op="statistics" interface="ipv6leakintrf0" ifindex=28 args="2000" pid=2950 uid=1000 result="success"
Mar 18 15:38:51 fedora NetworkManager[1762]: <info>  [1773873531.8007] audit: op="statistics" interface="wlp0s20f3" ifindex=2 args="2000" pid=2950 uid=1000 result="success"
Proton VPN victim
3

Welcome to Fedora @ekardscribner73

It looks like you are dns leaking with your ipv6. Kill switch is for that to protect you from leaking. This means some other dns than this from ProtonVPN , tries to resolve your IP.

resolvectl show you the dns settings.

I could not use proton-vpn-cli anymore. From where/how did you install it?

5
6

Thank you for your response. I don’t see evidence of any ipv6 leaks, but it appears that pvpn-killswitch-ipv6 corresponds to a dummy interface blocking ipv6 traffic only. Curiously, when I enable IPv6 in Proton VPN settings, “pvpn-killswitch-ipv6” still appears.

Do you think I’m correct in calling this a bug?

I could be wrong as I’m fairly new to Fedora, but I believe that protonvpn-cli is the deprecated package. The “new” CLI that is offered by Proton is available through their repository, and is named “proton-vpn-vli.noarch”.

Here is a video showing what happens when I connect. This is with Kill Switch and IPv6 disabled in Proton settings.

Requested output:

~$ resolvectl
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp0s20f3)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 3 (enp34s0u2u4)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 16 (proton0)
    Current Scopes: DNS
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.2.0.1
       DNS Servers: 10.2.0.1 2a07:b944::2:1
        DNS Domain: ~.
     Default Route: yes

Link 17 (ipv6leakintrf0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no
7

I have read those resources, but I appreciate you pointing them out. Are you aware of any specific information that I have missed? I’m trying to figure out why kill switch connections are appearing even though the setting is turned off.

~$ protonvpn config list

Current configuration
Setting                  Value
-----------------------  ------------
vpn-accelerator          on
moderate-nat             off
ipv6                     on
anonymous-crash-reports  on
port-forwarding          off
custom-dns               off
kill-switch              off
netshield                malware-only
8

Did you try nmcli connection delete pvpn-routed-killswitch

9

Yes, I deleted the killswitch connection using nmcli. It reappears the next time the VPN is connected, whether using the CLI or GUI.

10

Is on the gnome GUI the Kill switch off to?
Does the Gnome-Gui work 100% with KDE Desktop?

11

On the Video it writes a message that ProtonVPN not works 100% with OpenVpn. You should consider to use Wire Guard.

12

The kill switch in the GUI is turned off. The GUI and CLI seem to share settings, as a change in one also appears in the other. The only restriction I have seen is that when one is actively running, the other cannot be started. In this case, the app itself shares this warning and exits.

Thank you, I use both. During the day, I connect to a network that blocks my WireGuard connection, but allows OpenVPN. Both protocols function just fine and the killswitch issue is present in both cases.

13

You might check with proton to see If they have news about KDE. As they write for now just support the gnome desktop.

Proton VPN Linux GUI app

The official Proton VPN Linux GUI app (with a graphic user interface) lets you protect your Linux devices with Proton VPN while controlling the VPN via an intuitive and easy-to-use graphical interface.

We officially support the latest stable versions of the following distributions using the GNOME desktop environment. Click on a link for full setup instructions:

14

Thanks, Proton VPN works fine on KDE. I’m in conversation with Proton support and they don’t seem to think that could be causing an issue. I’ve used it without problem in the past too. Any other ideas?

I deleted all the files in .config and .cache hoping to reset, but it didn’t even so much as log me out. I can’t figure out where the rest of the files could be stored to purge them.

15

Did you give a try to the flatpak version of the gui app? The local app caused a ton of errors on my system. So if I use the Gui app, I can work. However most time I use WireGuard.

16

I hadn’t even considered that before; thank you for mentioning it! I prefer to use WireGuard but can’t always do so. I’ve been contemplating creating various wireguard and openvpn NetworkManager connections to attach as secondaries to the various networks that I use, but I would miss some of the features of Proton’s apps such as automatically selecting the fastest server.

17

Is this not the normal behaviour? KDE only shows loud and clear which connections are created by NetworkManager. Proton extensively uses NetworkManager to set-up the VPN, and adds new interfaces to protect traffic leaking through the normal connection, e.g. IPv6. I understood NetworkManager has now volatile connections which disappear upon reboot. If you reboot, do you have normal internet access ?

I have a connection pvpn-killswitch which creates an device pvpnksintrf0 of type dummy, so for communication a black-hole. It has an IPv4 and an IPv6 address. Highest priority default route goes to this interface, so internet access is blocked. The same for IPv6, which is not supported on all servers as far I know. So you have only access to your local network, and Proton’s OpenVPN server which gets a dedicated route. After closing the VPN, the kill switch is gone.

18

You’re suggesting that the ipv6 killswitch connection will be created every time because the servers do not yet support any IPv6 traffic? This could be the case. My internet connection works, I just found it vexing that killswitch connections continued to reappear despite the setting being turned off. Perhaps I just didn’t notice this behavior before recently?

19

I think the name as changed, there was a dedicated IPv6 trap before. Now there is a permanent “pvpn-killswitch-perm” connection in “Advanced mode”, which survives reboot to prevent any internet access without VPN, and “pvpn-killswitch” which is created during connection to trap IPv6 and IPv4 outside VPN. I’m not a regular KDE user and was surprised about the stack of notifications appearing when activating a connection. I think you do not have to worry, if you have normal internet connection after reboot, everything should be fine.

For the rest the IPv6 state of proton is not clear for me, there are (free) servers where I’m able to have manually an IPv6 connection with OpenVPN and Wireguard, but from the app I do not know.

Actual: It works on Wireguard, with OpenVPN I do not manage yet to get IPv6 anymore.

20

Thank you for weighing in. I think you’re right to point out the KDE notification stack–it seems to be revealing some of Proton’s automatic behind-the-scenes behavior that isn’t normally apparent. Thinking back to my previous usage in Arch Linux with KDE, I either had notifications turned off or I used nmcli connections to initialize WireGuard and OpenVPN tunnels directly, so it’s entirely possible that the behavior has been consistent and I have failed to notice.

It’s frustrating that the GUI seems a little hit-and-miss when it comes to re-connecting after sleep. If I physically move to a new building on the same network, or travel home, and then wake the computer, it sometimes has a difficult time re-connecting to the VPN and I have to initialize the connection manually. Using NetworkManager connections attached to Wi-Fi networks as secondaries, I never experienced these failures. So I may have been blaming these incidents on the automatically populating killswitches that I perceived as new.

Anyway, for the most part it’s working great, and I appreciate the GUI / CLI utilities, even simply for the ability to automatically connect to the fastest server.

Cheers
Ekard

21

May be you can try to start the protonvpn app from a terminal, then there is logging. When I just bring the (wired) internet connection down, the app starts a reconnector service, and the killswitch is replaced by a routed-killswitch with a huge number of routes into it. It tries to reconnect with increasing intervals. If I start the internet connection again, it manages to get it’s IPv4 and IPv6 addresses. If the reconnector’s interval has expired, everything restores to original and the VPN works again. In sleep mode, there is no chance for the reconnector to do anything, so this simulation may be not representative, but the log might reveal why you have problems to revive the connection.

22

Thank you, this is a good suggestion. I used the CLI in verbose mode, but did not consider running the GUI from a terminal.

It’s looking more like this is a combination of Proton’s default behavior and the GUI applet’s inability to recover after sleeping. Maybe not “bugs,” but still not appreciated. I may switch back to using manually configured NetworkManager connections to connect for the time being–we’ll see.