[Bug]: External app links are blocked/slow opening when windscribe is open

[matdave]

Preflight checks

• I have searched existing issues and this bug has not already been reported.
• I am running the latest version of the app available for my platform.
• I understand that incomplete reports may be closed without investigation.

Describe the bug

I think this might be somewhat related to #252

I am running an up-to-date PopOS, and noticed that when I use the desktop app, I cannot open links form external apps.

I have created a video demonstrating the behavior.

2026-08-19-18.47.31.640058963.mp4

Operating system

Other Linux distribution

OS details

Linux pobuntu 7.0.11-76070011-generic #202606011647178421509724.04~4974880 SMP PREEMPT_DYNAMIC Thu J x86_64 x86_64 x86_64 GNU/Linux

App version

2.23.11

Steps to reproduce

1. Run the windscribe
2. Attempt opening a link with xdg-open
3. Wait for it to either fail or open

Expected behavior

Links open normally

Actual behavior

Links either open very slowly or not at all.

Debug log or username

Sent with user matdave, but do not see anything relevant between when link click starts or link eventually opens

Is this a regression?

Not sure

Screenshots

Video included above

Additional context

No response

[matdave]

I'm investigating a little further, and I believe this is a conflict with running tailscale and windscribe at the same time. Still looking...

[matdave]

Follow-up with the root cause, based on live debugging on my machine
(Pop!_OS 24.04, kernel 7.0.11, Windscribe 2.23.11, systemd-resolved,
Tailscale running with MagicDNS).

TL;DR: While connected, the client's routing policy sends ALL unmarked
traffic into the WireGuard tunnel (utun420) — including Tailscale DNS
(100.100.100.100, CGNAT), which is only reachable via the tailnet. DNS
lookups that systemd-resolved routes to that server then hang for
30–120 s, and apps that resolve the machine's own hostname at startup
(such as Firefox) block synchronously. On systems where xdg-open does
not go through the desktop portal (e.g. COSMIC currently), it executes
the browser synchronously, so external links appear slow/blocked.

Evidence:

1. xdg-open https://duckduckgo.com — no return after 120 s while
   the app is connected. gio open https://duckduckgo.com returns in
   27 ms, so the portal path is fine.

2. firefox -new-tab about:blank — hangs ≥30 s on its own. The hang
   is inside the firefox CLI startup, before any network fetch.

3. strace of the firefox CLI shows it makes a synchronous
   io.systemd.Resolve.ResolveHostname varlink call for the machine's
   own hostname ("pobuntu") and blocks waiting for the reply:

   sendto({"method":"io.systemd.Resolve.ResolveHostname",
   "parameters":{"name":"pobuntu","family":2,"flags":0}})
   ppoll(fd=21, tv_sec=119) <- never answered

4. resolvectl query pobuntu — times out (>45 s).
   resolvectl query duckduckgo.com — 67 ms.
   So ordinary DNS is fine; only lookups that end up on the tailnet
   search domain (e.g. any unqualified name) hang.

5. While the app is connected:

   $ ip rule
   5209: from all fwmark 0xca6c lookup 51820
   5270: from all lookup 52

   $ ip route show table 51820
   default dev utun420 scope link <- WireGuard tunnel

   $ ip route get 100.100.100.100 <- Tailscale MagicDNS
   100.100.100.100 dev utun420 table 51820 src 100.102.217.126

   Tailscale's routes (including 100.100.100.100/32) live only in
   table 52, but the client's rule for table 51820 (catch-all default
   via utun420) matches all unmarked traffic first, so packets to
   100.100.100.100 enter the tunnel and vanish. tailscaled is healthy
   and never sees them (ping = 100% loss, UDP retries + TCP SYN-SENT
   observed, all unanswered).

6. With the app off, ip route get 100.100.100.100 returns
   dev tailscale0 and everything is instant.

Root cause: the rule/default-route selection shouldn't swallow CGNAT
before table 52 is consulted. Adding a static exclusion for
100.64.0.0/10 (e.g. dev tailscale0 in the same table) or ordering the
rule after the CGNAT routes fixes it.

Suggested fix: while connected, ip route get 100.100.100.100 should
return a tailscale0 path, not utun420.

Workarounds until then:
restore the MagicDNS route in the client's table
sudo ip route add 100.100.100.100 dev tailscale0 table 51820