Maybe this change affects your setup? https://invent.kde.org/network/kdeconnect-android/-/commit/72881f8b04d280284b31ddd9810ee1c9a0fa8320

If that's the case you should see the new log messages though.

I can confirm this regression is present in v1.35.2 and breaks VPN-based setups (specifically Tailscale).

My Setup:
* Device: Samsung SM-F9460 
* OS: Android 16 
* App Version: KDE Connect v1.35.2 
* Network: Tailscale (100.x.y.z range)
* Method: "Add Device by IP" (Manual entry)

Investigation & Logs:
* Network Verification: I verified connectivity from the phone using Termux. Running nc -z -v <desktop-tailscale-ip> 1716 succeeds immediately, confirming the tunnel is up and ports are reachable.
* The Failure: despite the open network path, the KDE Connect app fails to discover or pair with the device.
* Log Evidence: The internal KDE Connect app logs show the following error when the packet arrives: I LanLinkProvider: Discarding UDP packet from a non-local IP 

Conclusion: It appears v1.35.2 introduced a strict check in LanLinkProvider that discards packets from VPN interfaces (like tun0) because they are not recognized as "local" by the standard connectivity check. This logic seems to override the user's explicit intent when using "Add Device by IP."

Workaround: I have confirmed that downgrading to v1.34.3 immediately resolves the issue and allows the connection over Tailscale to succeed.

(In reply to Albert Vaca Cintora from comment #1)
> Maybe this change affects your setup?
> https://invent.kde.org/network/kdeconnect-android/-/commit/
> 72881f8b04d280284b31ddd9810ee1c9a0fa8320
> 
> If that's the case you should see the new log messages though.

Yep, that's the one. Tailscale uses 100.64.0.0/10 — that's RFC 6598 space, which IANA specifically allocated for CGNAT and similar setups. Java's isSiteLocalAddress() only covers RFC 1918 (10.x, 172.16-31.x, 192.168.x), so the 100.64 range gets rejected.

Thing is, 100.64.0.0/10 is pretty widely used beyond just Tailscale. ZeroTier, Nebula, and a bunch of WireGuard setups sit in that range too. ISPs also stick customers behind CGNAT on these same addresses, so this could bite more people than just VPN users. Might be worth expanding the check to include RFC 6598, or making it something users can configure?

I redact my statement on the other apps, Nebula,  Zerotier, etc. I can only confirm, at this time, that Tailscale is the only one affected, unless others with those apps say otherwise.

FYI This issue is also (kind of) tracked on Tailscale’s GitHub starting at this comment: https://github.com/tailscale/tailscale/issues/14476#issuecomment-3844353335

I'm also affected by this issue, also using Tailscale, also by manually adding the Tailscale IPs / hostnames to the KDE Connect clients via config file / "add devices by IP" on desktop / Android resp..

I agree to Matt’s 2nd suggestion to add a setting for this, I assume, security feature filtering for local IPs only. Esp. because a) KDE Connect (seems to) use a TLS connection with TOFU authenticating both sides and b) there will be (advanced) setups where KDE Connect connections should be routed through some kind of VPN, be it device-to-device / site-to-site / and so on. Enabling this security feature by default IMO is fine because I think this will be sufficient most users. And I see that this increases the security as filtering for local IPs only should decrease the attack surface esp. on phones which may be confronted with connections using public IPs (e.g. via cellular connections).

Just in case, other ideas I had in my mind are, but which seem more complex & less secure when applied to all users:
2) allowing connections from IPs which are explicitly listed in the configs (but then this may require users to list them on both sides; and what about hostnames with multiple records)
3) only allowing connections from already paired devices (may be complex to implement; still allows for increased attack surface; requires "local" pairing first)

I would not just fix this for the 100.64.0.0/10 IP space because:
- There is IPv6 with its public & unique local addresses (ULA, fc00::/7). Site-to-Site VPNs between trusted local networks may use public IPv6s. And on the other side, depending on the context and/or network operator, ULAs might be routed across "untrusted" networks.
- some uncommon networks may use public IPv4 addresses
- maybe some users want/require KDE Connect connections via the internet

Duplicate of https://bugs.kde.org/show_bug.cgi?id=515707

(In reply to Linus Dierheimer from comment #6)
> Duplicate of https://bugs.kde.org/show_bug.cgi?id=515707

https://bugs.kde.org/show_bug.cgi?id=515566, copied the wrong tab....

A possibly relevant merge request was started @ https://invent.kde.org/network/kdeconnect-android/-/merge_requests/621

A possibly relevant merge request was started @ https://invent.kde.org/network/kdeconnect-android/-/merge_requests/621

Thanks for the quick response on MR 621.

One thing I wanted to flag: in the duplicate bug 515566, Linus Dierheimer suspects their dormitory subnet (100.122.0.0/16) falls within the 100.64.0.0/10 range being allowed here. If so, that's a shared multi-tenant network. RFC 6598 explicitly distinguishes this range from RFC 1918 private address space — it was allocated for carrier-grade NAT where multiple subscribers share the same address block.

As zocker.network suggested in comment 5, would it make sense to have this be a user-facing toggle, off by default? That would cover VPN and CGNAT users who need it without broadening the filter for everyone else.

knyipab also raised an interesting point in comment 2 — the current behavior discards packets from addresses the user has explicitly entered via "Add device by IP." There might be a narrower fix there, though I don't know if the code architecture makes that straightforward.

Appreciate the work on this either way.

(In reply to Matt from comment #10)
> One thing I wanted to flag: in the duplicate bug 515566, Linus Dierheimer
> suspects their dormitory subnet (100.122.0.0/16) falls within the
> 100.64.0.0/10 range being allowed here. If so, that's a shared multi-tenant
> network. RFC 6598 explicitly distinguishes this range from RFC 1918 private
> address space — it was allocated for carrier-grade NAT where multiple
> subscribers share the same address block.

In theory yes. Not sure whether it's really used at all by carriers these days, though. I've never seen them used outside of corporate networks and lately Tailscale.

(In reply to Matt from comment #10)
> As zocker.network suggested in comment 5, would it make sense to have this
> be a user-facing toggle, off by default? That would cover VPN and CGNAT
> users who need it without broadening the filter for everyone else.

I feel that this setting will be tedious to explain. "Check this if you're using Tailscale"?
Love the idea, though as it would make the tailnet feel really like local network as before.

(In reply to Matt from comment #10)
> knyipab also raised an interesting point in comment 2 — the current behavior
> discards packets from addresses the user has explicitly entered via "Add
> device by IP." There might be a narrower fix there, though I don't know if
> the code architecture makes that straightforward.

This one is easy to be implemented. The custom device list is easily accessible where this check happens. Downsides:

- Pairing new devices over Tailscale would be tedious. The device simply disappears when you're using tailscale and it's not obvious that adding it manually by IP would work
- Tailscale also has dns resolving inside the tailnet (e.g. desktop.tail123456.ts.net). If we want to support devices added by hostnames in the custom device list, that would make things a bit more tedious

I still believe that we should just treat 100.64.0.0/10 as a local network, given that the real world treats it that way these days. Said that, if maintainers decide on any of the other two suggested ideas, I'm willing to submit a MR implementing them.