Consider the situation where two clients are on a network with hairpin NAT (e.g. they are on the same Wireguard network, with the gateway set up to enable IP forwarding). In this case, packets are NAT-ed by the gateway. When this is done, the source port is replaced by a randomly allocated port on the gateway. When kdeconnectd receives the initial packet, it disregards the packet's source port and always attempts to reply to port 1716. This causes the packet to not be routed by the gateway back to the original server, causing the devices to not see each other. Ideally, kdeconnectd should pay attention to the port number of received packets, and reply to this number. Hopefully, combined with adding devices by IP in the mobile client, that should allow kdeconnect to work on such network configurations.
*** Bug 375247 has been marked as a duplicate of this bug. ***
Broadcast packets don't use source addresses AFAIK... So you might need to forward/bridge broadcast packets on your gateway also...
(In reply to ©TriMoon™ from comment #2) > Broadcast packets don't use source addresses AFAIK... The mobile client (on Android at least) supports adding devices by IP, in which case it does not use broadcast packets.