Split tunneling option visible, but does not work on CachyOS

[Goldkraw]

We are happy to answer your questions about the code or discuss technical ideas.

Please complete the following checklist (by adding [x]):

• I have searched open and closed issues for duplicates
• This isn't a feature request
• This is not a report about my app not working as expected

---

Kernel Version: 6.18.9-2 cachyos, also tested with 6.12.69-2 cachyos and 6.12.69-1 unpatched kernel.

Expected Behaviour: With split tunneling enabled, traffic should only be tunneled through the VPN for the included apps.

Actual Behaviour: Split tunneling shows up as enabled in the app, but upon connecting to the VPN, the specified rules are not applied.

in ~/.cache/Proton/VPN/logs/vpn-app.log, the following is logged when connecting:

2026-02-08T22:22:34.462467+00:00 | proton.vpn.connection.states:314 | ERROR | Error setting split tunnel configuration
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/client.py", line 148, in set_config
    await _backwards_compatible_asyncio_timeout(
    ...<3 lines>...
    )
  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/client.py", line 94, in _backwards_compatible_asyncio_timeout
    await func(*args)
  File "/usr/lib/python3.14/site-packages/dbus_fast/aio/proxy_object.py", line 111, in method_fn
    BaseProxyInterface._check_method_return(msg, intr_method.out_signature)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/site-packages/dbus_fast/proxy_object.py", line 85, in _check_method_return
    raise DBusError._from_message(msg)
dbus_fast.errors.DBusError: The service interface raised an error: Failed to attach BPF program b'syscall__execve' to kprobe b'sys_execve', it's not traceable (either non-existing, inlined, or marked as "notrace").
['  File "/usr/lib/python3.14/site-packages/dbus_fast/aio/message_bus.py", line 490, in _done\n    result = fut.result()\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/service.py", line 97, in set_config\n    await self._service.set_config(uid, config)\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/split_tunneling.py", line 53, in set_config\n    self._app_split_tunneling.start(self._config_by_uid)\n    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/apps/service.py", line 66, in start\n    return self._process_monitor.start(config_by_uid=config_by_uid)\n           ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/apps/process_monitor.py", line 106, in start\n    self._attach_bpf()\n    ~~~~~~~~~~~~~~~~^^\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/apps/process_monitor.py", line 157, in _attach_bpf\n    self._bpf.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")\n    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n', '  File "/usr/lib/python3.14/site-packages/bcc/__init__.py", line 883, in attach_kprobe\n    raise Exception("Failed to attach BPF program %s to kprobe %s"\n                    ", it\'s not traceable (either non-existing, inlined, or marked as \\"notrace\\")" %\n                    (fn_name, event))\n']

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/proton/vpn/connection/states.py", line 307, in run_tasks
    await self.context.split_tunneling.set_config(
    ...<2 lines>...
    )
  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/client.py", line 158, in set_config
    raise exceptions.SplitTunnelingError(
    ...<2 lines>...
    ) from excp
proton.vpn.split_tunneling.exceptions.SplitTunnelingError: Error setting new split tunneling configuration for 1000
2026-02-08T22:22:34.463617+00:00 | proton.vpn.core.connection:508 | INFO | CONN:STATE_CHANGED | Connected

Additionally, systemctl status proton.VPN shows the following:

feb 09 00:22:11 cachyos-x8664 systemd[1]: Starting Proton VPN Daemon...
feb 09 00:22:11 cachyos-x8664 python3[999]: 2026-02-08T22:22:11.491973+00:00 | __main__:41 | INFO | Starting Proton VPN daemon v0.13.4
feb 09 00:22:11 cachyos-x8664 systemd[1]: Started Proton VPN Daemon.
feb 09 00:22:28 cachyos-x8664 python3[999]: 2026-02-08T22:22:28.469843+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:63 | INFO | Clearing config for user 1000
feb 09 00:22:30 cachyos-x8664 python3[999]: 2026-02-08T22:22:30.695170+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:49 | INFO | Setting SplitTunnelingConfig(mode=<SplitTunnelingMode.INCLUDE: >
feb 09 00:22:30 cachyos-x8664 python3[999]: 2026-02-08T22:22:30.696620+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:114 | INFO | Starting socket monitor (with fwmark 13501235)
feb 09 00:22:30 cachyos-x8664 python3[999]: 2026-02-08T22:22:30.696798+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:100 | INFO | Starting process monitor
feb 09 00:22:30 cachyos-x8664 python3[999]: 2026-02-08T22:22:30.768985+00:00 | proton.vpn.daemon.split_tunneling.apps.process_matcher:134 | INFO | Existing processes inspected in 72 ms
feb 09 00:22:34 cachyos-x8664 python3[999]: cannot attach kprobe, Invalid argument

[ptr1337]

Can reproduce:

2026-02-09T17:41:41.802232+00:00 | proton.vpn.app.gtk.widgets.vpn.quick_connect_widget:105 | INFO | UI.TRAY:CONNECT | Connect to fastest server
2026-02-09T17:41:41.956646+00:00 | proton.vpn.core.connection:400 | INFO | CONN.CONNECT:START | Server: DE#533 / Domain: node-de-28.protonvpn.net / IP: 149.88.24.180 / OpenVPN Ports: ProtocolPorts(udp=[80, 51820, 4569, 1194, 5060], tcp=[443, 7770, 8443]) / WireGuard Ports: ProtocolPorts(udp=[443, 88, 1224, 51820, 500, 4500], tcp=[443]) / Protocol: wireguard / Backend: None
2026-02-09T17:41:41.957461+00:00 | proton.vpn.core.connection:415 | INFO | Using certificate based authentication for openvpn: True
2026-02-09T17:41:41.957797+00:00 | proton.vpn.core.connection:508 | INFO | CONN:STATE_CHANGED | Connecting
2026-02-09T17:41:42.022127+00:00 | proton.vpn.backend.networkmanager.core.networkmanager:91 | INFO | VPN server REACHABLE.
2026-02-09T17:41:42.129446+00:00 | proton.vpn.backend.networkmanager.core.localagent_mixin:69 | INFO | Waiting for agent status from node-de-28.protonvpn.net...
2026-02-09T17:41:42.190267+00:00 | proton.vpn.backend.networkmanager.core.localagent_mixin:131 | INFO | Requesting VPN connection features...
2026-02-09T17:41:42.190531+00:00 | proton.vpn.local_agent/transport_stream.rs:56 | INFO | Sending: Request { features_set: Some(AgentFeatures { netshield_level: Some(0), randomized_nat: Some(true), split_tcp: Some(true), port_forwarding: Some(false), forwarded_port: None, jail: None, bouncing: Some("6") }), status_get: None }
2026-02-09T17:41:42.190665+00:00 | proton.vpn.backend.networkmanager.core.localagent_mixin:134 | INFO | VPN connection features requested.
2026-02-09T17:41:42.470471+00:00 | proton.vpn.local_agent/transport_stream.rs:80 | INFO | Receiving: Response { status: Some(StatusMessage { state: Connected, reason: None, features: Some(AgentFeatures { netshield_level: Some(0), randomized_nat: Some(true), split_tcp: Some(true), port_forwarding: Some(false), forwarded_port: None, jail: Some(false), bouncing: Some("38") }), connection_details: Some(ConnectionDetails { device_ip: Some("178.27.93.69"), device_country: Some("DE"), server_ipv4: Some("149.88.24.219"), server_ipv6: Some("2a02:6ea0:1703:5031::49") }), features_statistics: None }), error: None }
2026-02-09T17:41:42.470568+00:00 | proton.vpn.backend.networkmanager.core.localagent_mixin:139 | INFO | Agent status received: Status { state: CONNECTED, reason: None, features: Some(AgentFeatures { features: AgentFeatures { netshield_level: Some(0), randomized_nat: Some(true), split_tcp: Some(true), port_forwarding: Some(false), forwarded_port: None, jail: Some(false), bouncing: Some("38") } }), connection_details: Some(ConnectionDetails { device_ip: "178.27.93.xxx", device_country: Some("DE"), server_ipv4: Some("149.88.24.219"), server_ipv6: Some("2a02:6ea0:1703:5031::49") }) }
2026-02-09T17:41:42.470984+00:00 | proton.vpn.core.connection:508 | INFO | CONN:STATE_CHANGED | Connected
2026-02-09T17:41:42.672908+00:00 | proton.vpn.local_agent/transport_stream.rs:80 | INFO | Receiving: Response { status: Some(StatusMessage { state: Connected, reason: None, features: Some(AgentFeatures { netshield_level: Some(0), randomized_nat: Some(true), split_tcp: Some(true), port_forwarding: Some(false), forwarded_port: None, jail: Some(false), bouncing: Some("6") }), connection_details: Some(ConnectionDetails { device_ip: Some("178.27.93.69"), device_country: Some("DE"), server_ipv4: Some("149.88.24.187"), server_ipv6: Some("2a02:6ea0:1703:5031::17") }), features_statistics: None }), error: None }
2026-02-09T17:41:42.673001+00:00 | proton.vpn.backend.networkmanager.core.localagent_mixin:139 | INFO | Agent status received: Status { state: CONNECTED, reason: None, features: Some(AgentFeatures { features: AgentFeatures { netshield_level: Some(0), randomized_nat: Some(true), split_tcp: Some(true), port_forwarding: Some(false), forwarded_port: None, jail: Some(false), bouncing: Some("6") } }), connection_details: Some(ConnectionDetails { device_ip: "178.27.93.xxx", device_country: Some("DE"), server_ipv4: Some("149.88.24.187"), server_ipv6: Some("2a02:6ea0:1703:5031::17") }) }
2026-02-09T17:41:44.582594+00:00 | proton.vpn.connection.states:314 | ERROR | Error setting split tunnel configuration
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/client.py", line 148, in set_config
    await _backwards_compatible_asyncio_timeout(
    ...<3 lines>...
    )
  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/client.py", line 94, in _backwards_compatible_asyncio_timeout
    await func(*args)
  File "/usr/lib/python3.14/site-packages/dbus_fast/aio/proxy_object.py", line 111, in method_fn
    BaseProxyInterface._check_method_return(msg, intr_method.out_signature)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/site-packages/dbus_fast/proxy_object.py", line 85, in _check_method_return
    raise DBusError._from_message(msg)
dbus_fast.errors.DBusError: The service interface raised an error: Failed to attach BPF program b'syscall__execve' to kprobe b'sys_execve', it's not traceable (either non-existing, inlined, or marked as "notrace").
['  File "/usr/lib/python3.14/site-packages/dbus_fast/aio/message_bus.py", line 490, in _done\n    result = fut.result()\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/service.py", line 97, in set_config\n    await self._service.set_config(uid, config)\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/split_tunneling.py", line 53, in set_config\n    self._app_split_tunneling.start(self._config_by_uid)\n    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/apps/service.py", line 66, in start\n    return self._process_monitor.start(config_by_uid=config_by_uid)\n           ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/apps/process_monitor.py", line 106, in start\n    self._attach_bpf()\n    ~~~~~~~~~~~~~~~~^^\n', '  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/apps/process_monitor.py", line 157, in _attach_bpf\n    self._bpf.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")\n    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n', '  File "/usr/lib/python3.14/site-packages/bcc/__init__.py", line 883, in attach_kprobe\n    raise Exception("Failed to attach BPF program %s to kprobe %s"\n                    ", it\'s not traceable (either non-existing, inlined, or marked as \\"notrace\\")" %\n                    (fn_name, event))\n']

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/proton/vpn/connection/states.py", line 307, in run_tasks
    await self.context.split_tunneling.set_config(
    ...<2 lines>...
    )
  File "/usr/lib/python3.14/site-packages/proton/vpn/daemon/split_tunneling/client.py", line 158, in set_config
    raise exceptions.SplitTunnelingError(
    ...<2 lines>...
    ) from excp
proton.vpn.split_tunneling.exceptions.SplitTunnelingError: Error setting new split tunneling configuration for 1000
2026-02-09T17:41:44.583301+00:00 | proton.vpn.core.connection:508 | INFO | CONN:STATE_CHANGED | Connected

It seems that bpf fails, but its exposed.

[ptr1337]

I was able to fix it with following patch on ProtonVPN Daemon, this is due n kernel 6.18+, sys_execve (the arch-specific syscall entry point) is marked as notrace, which prevents kprobe attachment

diff --git a/proton/vpn/daemon/split_tunneling/apps/process_monitor.bpf.c b/proton/vpn/daemon/split_tunneling/apps/process_monitor.bpf.c
index c28ce91..3a3cfb4 100644
--- a/proton/vpn/daemon/split_tunneling/apps/process_monitor.bpf.c
+++ b/proton/vpn/daemon/split_tunneling/apps/process_monitor.bpf.c
@@ -24,14 +24,14 @@ struct data_t {

 BPF_PERF_OUTPUT(events);

-static int __submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data)
+static int __submit_arg(void *ctx, void *ptr, struct data_t *data)
 {
     bpf_probe_read_user(data->argv, sizeof(data->argv), ptr);
     events.perf_submit(ctx, data, sizeof(struct data_t));
     return 1;
 }

-static int submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data)
+static int submit_arg(void *ctx, void *ptr, struct data_t *data)
 {
     const char *argp = NULL;
     bpf_probe_read_user(&argp, sizeof(argp), ptr);  // nosemgrep: raptor-incorrect-use-of-sizeof
@@ -41,10 +41,7 @@ static int submit_arg(struct pt_regs *ctx, void *ptr, struct data_t *data)
     return 0;
 }

-int syscall__execve(struct pt_regs *ctx,
-    const char __user *filename,
-    const char __user *const __user *__argv,
-    const char __user *const __user *__envp)
+TRACEPOINT_PROBE(syscalls, sys_enter_execve)
 {
     // create data here and pass to submit_arg to save stack space (#555)
     struct data_t data = {};
@@ -60,23 +57,23 @@ int syscall__execve(struct pt_regs *ctx,
     bpf_get_current_comm(&data.comm, sizeof(data.comm));
     data.type = EVENT_EXEC_ARG;

-    __submit_arg(ctx, (void *)filename, &data);
+    __submit_arg(args, (void *)args->filename, &data);

     // skip first arg, as we submitted filename
     #pragma unroll
     for (int i = 1; i < MAXARG; i++) {
-        if (submit_arg(ctx, (void *)&__argv[i], &data) == 0)
+        if (submit_arg(args, (void *)&args->argv[i], &data) == 0)
              goto out;
     }

     // handle truncated argument list
     char ellipsis[] = "...";
-    __submit_arg(ctx, (void *)ellipsis, &data);
+    __submit_arg(args, (void *)ellipsis, &data);
 out:
     return 0;
 }

-int do_ret_sys_execve(struct pt_regs *ctx)
+TRACEPOINT_PROBE(syscalls, sys_exit_execve)
 {
     struct data_t data = {};

@@ -90,7 +87,7 @@ int do_ret_sys_execve(struct pt_regs *ctx)

     bpf_get_current_comm(&data.comm, sizeof(data.comm));
     data.type = EVENT_EXEC_RET;
-    events.perf_submit(ctx, &data, sizeof(data));
+    events.perf_submit(args, &data, sizeof(data));

     return 0;
 }
diff --git a/proton/vpn/daemon/split_tunneling/apps/process_monitor.py b/proton/vpn/daemon/split_tunneling/apps/process_monitor.py
index 080734f..9c8e928 100644
--- a/proton/vpn/daemon/split_tunneling/apps/process_monitor.py
+++ b/proton/vpn/daemon/split_tunneling/apps/process_monitor.py
@@ -148,24 +148,13 @@ class ProcessMonitor:
         if not self._bpf:
             with open(BPF_PROGRAM_PATH, "r", encoding="utf-8") as file:
                 bpf_text = file.read()
+            # All probes use TRACEPOINT_PROBE and are automatically
+            # attached when the BPF object is created.
             self._bpf = BPF(text=bpf_text)

-        # Explicitly attach kprobes/kretprobes,
-        # tracepoints using TRACEPOINT_PROBE are automatically attached when
-        # the BPF object is created
-        execve_fnname = self._bpf.get_syscall_fnname("execve")
-        self._bpf.attach_kprobe(event=execve_fnname, fn_name="syscall__execve")
-        self._bpf.attach_kretprobe(event=execve_fnname, fn_name="do_ret_sys_execve")
-
     def _detach_bpf(self):
-        # Explicitly detach kprobes/kretprobes,
-        # tracepoints using TRACEPOINT_PROBE are automatically detached when
-        # the BPF object is destroyed
-        execve_fnname = self._bpf.get_syscall_fnname("execve")
-        self._bpf.detach_kprobe(event=execve_fnname, fn_name="syscall__execve")
-        self._bpf.detach_kretprobe(event=execve_fnname, fn_name="do_ret_sys_execve")
-
-        # Destroy the BPF object to detach tracepoints
+        # All probes use TRACEPOINT_PROBE and are automatically
+        # detached when the BPF object is destroyed.
         self._bpf = None

     async def _run_process_monitoring(self):

[ptr1337]

The patch is now applied in extra-testing proton-vpn-daemon after having a short talk with the developer :)
Please retest

[brittyazel]

I'm still having problems with split tunneling (Arch Linux). I don't see any error messages in the logs like the previous reporters, but even though I have only a single app set in my "Include mode" list, all of my traffic/DNS is being routed over the VPN.

@ptr1337 I confirmed that the version of proton-vpn-daemon I am running has your patch applied

Looking at the output for proton-vpn-daemon, it mentions split tunneling, but nothing that would indicate it erroring out as far as I can tell.

Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.598699+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:49 | INFO | Setting SplitTunnelingConfig(mode=<SplitTunnelingMode.INCLUDE: 'include'>, app_paths=['/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=qbittorrent --file-forwarding org.qbittorrent.qBittorrent'], ip_ranges=[]) for user 1000
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.599596+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:114 | INFO | Starting socket monitor (with fwmark 2367250617)
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.599759+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:100 | INFO | Starting process monitor
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.662786+00:00 | proton.vpn.daemon.split_tunneling.apps.process_matcher:59 | WARNING | Error getting process path: ZombieProcess: PID still exists but it's a zombie (pid=43825)
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.684856+00:00 | proton.vpn.daemon.split_tunneling.apps.process_matcher:134 | INFO | Existing processes inspected in 85 ms
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.438505+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:63 | INFO | Clearing config for user 1000
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.438618+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:135 | INFO | Stopping process monitor
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.453761+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:145 | INFO | Process monitor stopped
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.453820+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:172 | INFO | Unloading split tunneling ebpf function
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.455371+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:182 | INFO | Socket monitor stopped

[ptr1337]

I'm still having problems with split tunneling (Arch Linux). I don't see any error messages in the logs like the previous reporters, but even though I have only a single app set in my "Include mode" list, all of my traffic/DNS is being routed over the VPN.

@ptr1337 I confirmed that the version of proton-vpn-daemon I am running has your patch applied

Looking at the output for proton-vpn-daemon, it mentions split tunneling, but nothing that would indicate it erroring out as far as I can tell.

Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.598699+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:49 | INFO | Setting SplitTunnelingConfig(mode=<SplitTunnelingMode.INCLUDE: 'include'>, app_paths=['/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=qbittorrent --file-forwarding org.qbittorrent.qBittorrent'], ip_ranges=[]) for user 1000
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.599596+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:114 | INFO | Starting socket monitor (with fwmark 2367250617)
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.599759+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:100 | INFO | Starting process monitor
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.662786+00:00 | proton.vpn.daemon.split_tunneling.apps.process_matcher:59 | WARNING | Error getting process path: ZombieProcess: PID still exists but it's a zombie (pid=43825)
Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.684856+00:00 | proton.vpn.daemon.split_tunneling.apps.process_matcher:134 | INFO | Existing processes inspected in 85 ms
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.438505+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:63 | INFO | Clearing config for user 1000
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.438618+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:135 | INFO | Stopping process monitor
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.453761+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:145 | INFO | Process monitor stopped
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.453820+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:172 | INFO | Unloading split tunneling ebpf function
Feb 16 14:36:33 BrittDesktop python3[46928]: 2026-02-16T22:36:33.455371+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:182 | INFO | Socket monitor stopped

Hey,

Can you test proper native applications? I think this is due flatpak and the process is not properly handled.

Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.662786+00:00 | proton.vpn.daemon.split_tunneling.apps.process_matcher:59 | WARNING | Error getting process path: ZombieProcess: PID still exists but it's a zombie (pid=43825)

The easiest you can try would be putting "Konsole" or any other terminal into include list and then curl the ip address:

curl api.ipify.org

and compare it with the one in browser. Im not sure, how the Flatpak handling is generally done. I would need to look into. im not so much a flatpak user :D

[brittyazel]

Hrm, when I collected that output I was 100% using the native app, so maybe something is being left over from the Flatpak version? I didn't explicitly purge out any configs when I switched from the Flatpak to the native app, so maybe that's my issue.

[ptr1337]

Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.598699+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:49 | INFO | Setting SplitTunnelingConfig(mode=<SplitTunnelingMode.INCLUDE: 'include'>, app_paths=['/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=qbittorrent --file-forwarding org.qbittorrent.qBittorrent'], ip_ranges=[]) for user 1000

It says here to include the qbittorrent from flatpak, if i understand correct.

[brittyazel]

After testing, I removed all trace of ProtonVPN from my system and reinstalled the native Arch Linux package, and got the exact same as before. I think the mention of Flatpak from the messages I posted before are in relation to my QBitTorrent app being a flatpak app. Perhaps there is some sort of incompatibility with ProtonVPN being able to isolate its activity for Flatpak apps.

Nevertheless, it's still forcing system-wide VPN traffic and forcing my DNS system-wide to that of the Proton VPN DNS servers. So something is definitely broken.

[brittyazel]

Feb 16 14:35:47 BrittDesktop python3[46928]: 2026-02-16T22:35:47.598699+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:49 | INFO | Setting SplitTunnelingConfig(mode=<SplitTunnelingMode.INCLUDE: 'include'>, app_paths=['/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=qbittorrent --file-forwarding org.qbittorrent.qBittorrent'], ip_ranges=[]) for user 1000

It says here to include the qbittorrent from flatpak, if i understand correct.

Oh apologies, I thought the app in question you were referring to was the Proton VPN flatpak, not the apps themselves, my bad.

After trying the tunneling on only a native application, it still is forcing my whole system through the VPN tunnel. My whole system registers as a different IP, even though only the one single (native) app was supposed to be tunneling through the VPN.

Feb 17 09:03:08 BrittDesktop python3[8836]: 2026-02-17T17:03:08.143821+00:00 | proton.vpn.daemon.split_tunneling.apps.service:42 | INFO | Process match: Process(uid=1000, pid=17682, ppid=2887, exe='', matched_config_paths={'/usr/bin/gnome-software'}, running=True)
Feb 17 09:03:08 BrittDesktop python3[8836]: 2026-02-17T17:03:08.143948+00:00 | proton.vpn.daemon.split_tunneling.apps.service:42 | INFO | Process match: Process(uid=1000, pid=17683, ppid=2887, exe='', matched_config_paths={'/usr/bin/gnome-software'}, running=True)
Feb 17 09:03:08 BrittDesktop python3[8836]: 2026-02-17T17:03:08.145437+00:00 | proton.vpn.daemon.split_tunneling.apps.service:42 | INFO | Process match: Process(uid=1000, pid=17684, ppid=2887, exe='', matched_config_paths={'/usr/bin/gnome-software'}, running=True)
Feb 17 09:03:08 BrittDesktop python3[8836]: 2026-02-17T17:03:08.145541+00:00 | proton.vpn.daemon.split_tunneling.apps.service:42 | INFO | Process match: Process(uid=1000, pid=17685, ppid=2887, exe='', matched_config_paths={'/usr/bin/gnome-software'}, running=True)
Feb 17 09:03:08 BrittDesktop python3[8836]: 2026-02-17T17:03:08.145629+00:00 | proton.vpn.daemon.split_tunneling.apps.service:42 | INFO | Process match: Process(uid=1000, pid=17686, ppid=2887, exe='', matched_config_paths={'/usr/bin/gnome-software'}, running=True)
Feb 17 09:03:36 BrittDesktop python3[8836]: 2026-02-17T17:03:36.910910+00:00 | proton.vpn.daemon.split_tunneling.split_tunneling:63 | INFO | Clearing config for user 1000
Feb 17 09:03:36 BrittDesktop python3[8836]: 2026-02-17T17:03:36.910988+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:135 | INFO | Stopping process monitor
Feb 17 09:03:36 BrittDesktop python3[8836]: 2026-02-17T17:03:36.926331+00:00 | proton.vpn.daemon.split_tunneling.apps.process_monitor:145 | INFO | Process monitor stopped
Feb 17 09:03:36 BrittDesktop python3[8836]: 2026-02-17T17:03:36.926386+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:172 | INFO | Unloading split tunneling ebpf function
Feb 17 09:03:36 BrittDesktop python3[8836]: 2026-02-17T17:03:36.927919+00:00 | proton.vpn.daemon.split_tunneling.apps.socket_monitor:182 | INFO | Socket monitor stopped

[ptr1337]

So, ive tested as well as another user tested it flatpak too but both were able to get split tunneling properly working. Im not sure how to reproduce the issue.

Did you restart the applications after enabling the VPN/Split tunneling?

@brittyazel

[Chanterelle-Train]

I have the exact same issue as @brittyazel. When enabling split tunneling, all traffic is routed through the vpn. I made sure to restart the relevant apps. I use CachyOS with KDE Plasma and I installed protonvpn with "sudo pacman -S proton-vpn-gtx-app". Sadly my subscription ran out so I am not able to test things anymore.

[ptr1337]

I have the exact same issue as @brittyazel. When enabling split tunneling, all traffic is routed through the vpn. I made sure to restart the relevant apps. I use CachyOS with KDE Plasma and I installed protonvpn with "sudo pacman -S proton-vpn-gtx-app". Sadly my subscription ran out so I am not able to test things anymore.

Which kind of application? When did you test this?

[Chanterelle-Train]

I have the exact same issue as @brittyazel. When enabling split tunneling, all traffic is routed through the vpn. I made sure to restart the relevant apps. I use CachyOS with KDE Plasma and I installed protonvpn with "sudo pacman -S proton-vpn-gtx-app". Sadly my subscription ran out so I am not able to test things anymore.

Which kind of application? When did you test this?

I checked whatismyipaddress.com on firefox before and after connecting to the vpn in split tunneling mode and they were different (my private ip before and 212.104.214.18 after which belongs to protonvpn). It was 4 days ago. I attached my split tunneling settings.

[brittyazel]

Sorry for not commenting on this ticket in a while. @ptr1337 Split tunneling has been working for me for the past few weeks, though there is one quirk. Upon activating a VPN connection, all currently running apps (despite not being a part of the include list) will get routed through the VPN. You have to close any non-included apps and then re-open them for them to stop being routed through the VPN. This is fairly non-intuitive in an "include mode" based context, and the warning message that you need to "close effected apps for the changes to take effect" would lead you to believe that you would only need to close and re-launch the apps in the include-mode list, not 'all' apps.

E.g. if I have a browser window open when I start the VPN, despite the browser not being included in my "include mode" list, the browser traffic will be routed through the VPN until I close the browser fully and re-launch it.

[ptr1337]

Sorry for not commenting on this ticket in a while. @ptr1337 Split tunneling has been working for me for the past few weeks, though there is one quirk. Upon activating a VPN connection, all currently running apps (despite not being a part of the include list) will get routed through the VPN. You have to close any non-included apps and then re-open them for them to stop being routed through the VPN. This is fairly non-intuitive in an "include mode" based context, and the warning message that you need to "close effected apps for the changes to take effect" would lead you to believe that you would only need to close and re-launch the apps in the include-mode list, not 'all' apps.

E.g. if I have a browser window open when I start the VPN, despite the browser not being included in my "include mode" list, the browser traffic will be routed through the VPN until I close the browser fully and re-launch it.

Yeah, the Proton VPN GTK App gioves there a notification. The proton-vpn-cli does not currently -might be a good idea to implement :)