Gufw

KDE Connect settings

Asked by Ronald Poulin

I use KDE Connect. I followed the recommendations in the KDE Connect Community Wiki:

"If you are behind a firewall, make sure to open the port range 1714-1764 for both TCP and UDP. Otherwise, make sure your network is not blocking UDP broadcast packets."

I have allowed both protocols in the port range recommended for all addresses (leaving the IP address fields blank). Still, no joy! I believe that KDE Connect makes a UDP Broadcast from the phone to the PC (vice-versa). I would like to add this rule using GUFW because if I drop the firewall, allow the devices to connect and then re-enable the firewall, everything is good!

How would I do that from the GUI?

If it isn't possible through the GUI, how would I add this rule manually and in what chain? The current target is RETURN in the ufw-not-local chain, the second to last or so entry in the INPUT table. I belive this new entry should go into the user-input/user-output chains.

I am still a newbie to some extent. Your help would be appreciated.

Question information

Language:
English Edit question
Status:
Solved
For:
Gufw Edit question
Assignee:
No assignee Edit question
Solved by:
costales
Solved:
Last query:
Last reply:
Revision history for this message
Ronald Poulin (rrpoulin) said : 		#1

After resetting my profile and adding two rules, this is what my Filter table looks like (portions)

Chain ufw-user-input (1 references)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:1714 dpt:1764
2 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:1714 dpt:1764

Chain ufw-user-output (1 references)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:1714 dpt:1764
2 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:1714 dpt:1764

This probably deals with brute force:

Chain ufw-not-local (1 references)
num target prot opt source destination
1 RETURN all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
2 RETURN all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
3 RETURN all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
4 ufw-logging-deny all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10
5 DROP all -- 0.0.0.0/0 0.0.0.0/0

I think I need to accept broadcast/multicast packets coming from the local network, 192.168.1.*

Revision history for this message
Best costales (costales) said : 		#2

First, don't use iptables & G/ufw.

Second, in the Report tab you have what ports are in the PC listening in
that moment, you should see them ;)

Revision history for this message
Ronald Poulin (rrpoulin) said : 		#3

Thank you for the advice. What happens is tha the device discovery happens over UDP Multicast/Broadcast. Once the device has been discovered, the connections are established on on ports 1714 through 1754. Currently, I have a connection over port 1714.

As you can see, Gufw has added ruses in the user section of the Filter table to accept packets on these ports. The problem I have is the device discovery part of the protocol used by KDE connect. According to the default profile values I printed out, the Multicast/Broadcast packets are being dropped by the last rule in the input chain. The threat avoided in the default values seems to be against a brute force attack using the packet type MULTICAST/BROADCAST, thus the limit it has set.

I would like to know if the graphical user interface has a trick to add a packet type rule and if it does, what is it. A second portion of that same question is how to mask the value of the local network. The option I have is either GUFW, UFW or straight iptables keeping in mind the syntax used in GUFW to maitain the integrity of the tables.

The ideal solution would be to have an app_profile file for KDE Connect but I do not understand all of the syntax used in those files and if there is a capability in them that would allow the insertion of the correct set of rules for KDE Connect which seems to require a set of open ports and UDP MULTICAST/Broadcast..

Revision history for this message
Ronald Poulin (rrpoulin) said : 		#4

I will figure it out. Thank you

Revision history for this message
Ronald Poulin (rrpoulin) said : 		#5

Thanks costales, that solved my question.