Bug 464253

Summary: Support NAT
Product: [Applications] kdeconnect Reporter: Vladimir Panteleev <kde>
Component: commonAssignee: Albert Vaca Cintora <albertvaka>
Status: REPORTED ---    
Severity: minor CC: andrew.g.r.holmes, bugs.kde.org, jon, postix, uwu
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: All   
See Also: https://bugs.kde.org/show_bug.cgi?id=457100
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Vladimir Panteleev 2023-01-13 21:18:53 UTC 
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.
Comment 1 AJ Jordan 2023-01-31 07:05:52 UTC 
*** Bug 375247 has been marked as a duplicate of this bug. ***
Comment 2 ©TriMoon™ 2023-03-15 10:36:15 UTC 
Broadcast packets don't use source addresses AFAIK...
So you might need to forward/bridge broadcast packets on your gateway also...
Comment 3 Vladimir Panteleev 2023-04-10 15:13:30 UTC 
(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.