Bug 358440

In that case it would be great if you can ask the Fedora packagers to add a script to allow kdeconnect on the firewall when it is installed. Could you contact them?

The Fedora package ships with a FirewallD profile that can be turned on through the GUI client or `firewall-cmd --add-service kde-connect`. However, it’s so unlikely that they will enable more services by default that I wouldn’t even ask. The default policy for Fedora Workstation and KDE spins only include dhcp, mdns, and samba-client. All other services must be added by the users themselves and I’m not aware of any packages that enable themselves (including apache and smtp servers).

Which in short brings me back to the generic solution of: detect when ports are blocked by any kind of firewall and display a warning in the UI used to discover and pair devices.

marking confirmed wishlist

What's the status of this? Is KDE Connect usable in Fedora/Red Hat?

fedora's kdeconnect packaging includes a firewalld definition/profile for ports used (per comment #2), and installs it as

/usr/lib/firewalld/services/kde-connect.xml

It's contents are:
<service>
<short>KDE Connect</short>
<description>
KDE Connect allows intercommunicating with mobile devices to receive messages and notifications.
</description>
<port protocol="tcp" port="1714-1764"/>
<port protocol="udp" port="1714-1764"/>
</service>

This allows users to use firewalld UI's (like firewall-config) to easily allow this communication if they wish (by opting-in to allow it).

It cannot be enabled automatically or by default (by policy)


As this wishlist is stated, I'm not sure kde-connect itself can tell whether it's communications are being blocked by a firewall (like firewalld).


As an aside, I've also lobbied fedora's kde-sig to use 'Fedora Workstation' firewall zone by default (which would allow this out of the box), but that proposal was rejected.

Would it make sense to have the file installed by kde connect instead of it being a patch by the distribution?

*** Bug 398892 has been marked as a duplicate of this bug. ***

Debian came in the past with FirewallD too, but I don't think it does that anymore.
I've been using for years OpenSnitch:
https://github.com/evilsocket/opensnitch
And I would like that KDE Connect is aware of it, understand its replies, but I don't want any default rule for it!
I prefer to be aware of all the requests to pass through the firewall for which I want to decide if I allow them or not, which creates the rules!
I don't trust and like too much firewall which come with a lot of default rules.

On Android I use 2 firewalls, depending if the phone allows administrator (root) permission or not.
If it does, then I use AFWall+:
https://f-droid.org/en/packages/dev.ukanth.ufirewall/
If it doesn't, then I use NetGuard:
https://f-droid.org/en/packages/eu.faircode.netguard/

I prefer the AFWall+ one, which requires administrator (root) permission, because that way I can also use a VPN app of my own to connect to the home router,it has better (easier) filters to show the system or the user apps only and has more granular permissions.

So on the Android side, It would be nice if KDE Connect would be aware of the existence of these 2 firewalls and would interact nicely with them.
At the moment discovery fails, but it's unclear for me if this has anything to do with AFWall+ or the fact that it has only the LAN permission for KDE Connect, for which I opened a bug report:
https://bugs.kde.org/show_bug.cgi?id=512315
As there are multiple bug reports here about discovery problems without MDNS, which I also didn't activate as I didn't know that I could still do that after the changelogs on F-droid about MDNS being removed.

Can you please make KDE Connect on both sides be more aware of firewalls, like checking their existence, checking their rules (if possible) and also make it more verbose so we can see on each step what is actually doing, what other third party processes, applications, functions is calling, on what ports and what are their responses to those calls?
It's pretty hard or even impossible to figure out if the firewalls are the problem, their rules are the problem, on which side the problem is if  KDE Connect on both sides doesn't say anything useful, from which we can get an idea where the problem might be.