Hello all. I had trouble using KESL in my fedora machine while I was using also a VPN. I tried a lot, but with no luck. Then I run Claude code with fable and thank God, the solution found. After I was ok, I told claude to write a small article in order to post it here for possible any other having the same issue and maybe kaspersky itself to fix this. Here it goes 

 

## Environment

- **OS:** Fedora Linux 43 Workstation, kernel 7.0.12
- **Product:** Kaspersky Endpoint Security for Linux (KESL) 12.4.0.1225
- **VPNs tested:** Mullvad 2026.3 (native app, WireGuard) and ProtonVPN 4.16.5 (flatpak, WireGuard via NetworkManager)
- Other security software present: firewalld, OpenSnitch (default allow), Wazuh agent — all ruled out during diagnosis.

## Symptoms

1. VPN app reports **Connected**, but there is no working internet: HTTPS connections fail immediately with `Connection reset by peer (os error 104)` (visible in the Mullvad daemon log for every API request).
2. Intermittently worse: with the tunnel up and the VPN's kill-switch firewall active, **HTTPS traffic leaked outside the tunnel** — `https://am.i.mullvad.net/connected` returned my real ISP IP address while Mullvad showed "Connected".
3. KVM/libvirt guest VMs kept working while the host had no internet (guest traffic is NAT-forwarded, so it bypasses KESL's per-process interception — a useful diagnostic hint).

## Root cause found

KESL's Web Threat Protection / Network Threat Protection / Mail Monitoring tasks install a transparent interception proxy:

- iptables-nft chains (`kesl_output` in `table ip mangle`) mark outbound TCP to ports 21, 25, 80, 110, 143, 443, 465, 587, 993, 995, 1080, 3128, 8080, etc. with fwmark `0x100`/`0x200`
- policy routing rules `fwmark 0x100/0x500 lookup 101` and `fwmark 0x200/0x600 lookup 101`, where table 101 is `local default dev lo`, divert the marked packets to a local proxy listening on `127.0.0.1:9789` and `127.0.0.1:9879`
- the proxy then **re-originates** the connections itself, plus two nfqueue hooks (queues 4/5) for inspection

When a VPN with a kill-switch firewall (Mullvad, ProtonVPN) is connected, the proxy's re-originated connections conflict with the VPN's nftables policy and mark-based WireGuard routing. Result: either every intercepted connection is reset (no internet), or the re-originated connection escapes via the physical interface — i.e. a **privacy leak: real IP exposed while the VPN reports Connected**.

## Verification

- KESL running, Mullvad connected → HTTPS resets + real-IP leak, DNS answered via WiFi instead of the tunnel, ping latency showed traffic going direct instead of through the VPN exit.
- `systemctl stop kesl`, Mullvad connected → everything perfect (correct exit IP, DNS via tunnel, tunnel-consistent latency).
- KESL running again but with tasks 14 (Web_Threat_Protection), 17 (Network_Threat_Protection) and 35 (Mail_Monitoring) stopped → everything perfect. Note: stopping tasks 14/17 alone at runtime was **not enough** — the interception hooks only disappeared after also stopping Mail_Monitoring and restarting the kesl service.

## Current workaround

`kesl-control --stop-task 14 && kesl-control --stop-task 17 && kesl-control --stop-task 35`, then `systemctl restart kesl`. File Threat Protection, Behavior Detection and Device Control keep working; only network traffic interception is off. The stopped state persists across restarts.

## Questions for Kaspersky

1. Is there a supported way to make KESL's traffic interception coexist with WireGuard VPNs / kill-switch firewalls (e.g. exclude a tunnel interface such as `wg0-mullvad`, or make the proxy honor the VPN's routing)?
2. The silent traffic leak outside an active VPN tunnel seems like a security issue in itself — is this a known problem, and is a fix planned?
3. Why do the interception firewall rules remain active after stopping the Web/Network Threat Protection tasks, until Mail Monitoring is also stopped and the service restarted?

Nice diagnostic work — that's a genuinely well-isolated root cause. Here's how I'd think about actually resolving it (not just working around it), plus direct answers to your three questions.

Why this happens

KESL's proxy-based interception is fundamentally policy-routing based, and WireGuard kill-switches are also policy-routing/nftables based. Both are fighting for the same outbound packet at the same layer (mangle/PREROUTING vs OUTPUT + fwmark). There's no cooperation protocol between them — KESL doesn't know "this fwmark'd packet is supposed to go through wg0", and the VPN client doesn't know "this locally re-originated connection from 127.0.0.1:9789 should still count as tunnel-only traffic." So you get a race depending on nftables rule order and table priority, which explains why the behavior was inconsistent (reset vs leak) rather than always failing the same way.

Actual fixes worth trying, in order of how "supported" they are

1. Interface exclusion in KESL policy (if your build supports it) Newer KESL versions have a "Trusted network settings" / exclusion list under Network Threat Protection where you can exclude specific interfaces from monitoring. If kesl-control --get-app-info or the Web Console shows a "Do not scan network traffic on interfaces" setting, adding wg0-mullvad / proton0 there is the cleanest fix — it stops the redirect at the source instead of racing with the VPN's routing.

Check with:

kesl-control --get-settings 17 | grep -i interface
kesl-control --get-settings 14 | grep -i interface

2. Reorder policy routing priority manually Since table 101 (KESL's local redirect) and the VPN's fwmark table are both consulted via ip rule, check:

ip rule show

If KESL's rule (fwmark 0x100/0x500 lookup 101) has a lower priority number than the VPN's rule, it wins the race first, causing conflict. You can manually renumber KESL's rule to a higher (lower-priority) number after the VPN's kill-switch rule is inserted, right after each VPN connect — this is fragile since KESL will reassert its rules on service restart, but it's scriptable via a NetworkManager up hook.

3. Mark exemption instead of interface exclusion Since KESL uses fwmark 0x100/0x200 and WireGuard/kill-switch implementations use their own marks (often 0xca6c for Mullvad, configurable for others), you could add an nftables rule above KESL's chain that unmarks or exempts packets destined for the VPN endpoint's UDP port (51820) and the tunnel interface, so KESL's mangle table never touches genuine tunnel traffic while still intercepting non-tunneled traffic. This needs to run after both KESL and the VPN app initialize, so it's really a systemd-oneshot-after-both-services job.

Your three questions — best-available answers

1. Supported coexistence? Not natively across all KESL versions — this is why the fix is either the interface-exclusion setting (if present in your build) or manual rule reordering. Worth filing a formal ticket since exclusion-by-interface really should be a first-class supported setting.

2. Is the leak a known issue? This specific interaction (proxy re-origination silently escaping the tunnel while VPN client reports "Connected") is a real security-relevant bug class — the VPN app has no visibility into KESL's re-origination, so it can't correctly enforce the kill-switch. This is worth reporting directly to Kaspersky support with your packet capture evidence, not just posting to community — it's the kind of thing that needs a CVE-track disclosure if it's reproducible on stock configs.

3. Why do rules persist after stopping tasks 14/17 alone? Almost certainly because the nfqueue/iptables setup routine is shared infrastructure initialized once at kesl service start and torn down only on full service stop, not per-task. Tasks 14/17/35 likely just gate whether packets get inspected once queued, not whether the redirect chains exist — so the chains stay resident until the whole service restarts and re-evaluates which chains to install based on current task states.

Given the ticket-worthy nature of #2 especially, I'd suggest filing directly with Kaspersky Support (not just forum) — reference your evidence trail (log excerpts, ip rule/iptables -t mangle -L dumps, and the systemctl stop/start comparison) since that's a clean enough repro that it should get escalated rather than just archived as a forum thread.

Regards
Ahnaf Tahmeed

Many thanks for your quick response. I will definitely create a ticket, but first I must collect all the proper data. 
 

I will come back here later to post the ticket link to mark the ticket as the solution to the topic.
 

Thanks again Ahnaf 

Edited August 9Aug 9 by Atzoulos