KDEconnect on 2 different networks: totally impossible?

[Duncan]

A. F. Cano posted on Sun, 03 Dec 2017 21:31:25 -0500 as excerpted:

> Hello,
> 
> I've been trying to get KDEconnect to work across a router and it
> appears to be impossible.  My internal network, where the linux KDE
> is, is at 192.168.x.0, the android phone with KDEconnect is at
> 192.168.y.0.  Traceroute reaches the phone so it's not a routing
> problem.  I have found this:
> 
> https://www.addictivetips.com/ubuntu-linux-tips/install-kde-connect-on-
linux/
> 
> and it says (in the Configuring KDE Connect section):
> 
> Note: pairing WILL NOT WORK if your Android device isn’t on the same
> network as your PC. Be sure that wifi is working before connecting.
> 
> I have not been able to find any instructions on configuring either the
> android app or the linux end.  At the android app, if I "Add devices by
> IP": 192.168.x.a it still finds "No devices".  Running kdeconnect-cli -l
> on the linux machine returns "0 devices found".
> 
> The default route is set properly on the phone.  The route to
> 192.168.y.0 is set properly through the router at the internal network.
> 
> Is there some configuration file somewhere that I could change so that
> KDEconnect works across the router? Or is this impossible?  For security
> reasons I don't want wifi on the internal network.

I don't use kdeconnect so can't say much about it specifically, but I do 
know that at the network level, there's a big technical difference 
between working on the same subnet, and not.

Basically, if you're on the same subnet, a device is directly addressable 
at a level below IP/internet-protocol level (I'm familiar with Ethernet, 
where it's the Ethernet MAC address that's used, I believe wifi uses MAC 
addresses too, ARP/address-resolution-protocol is used at this lower 
layer), and the connection is actually handled at that lower level, while 
if you're not on the same IP-layer subnet, even if you're on the same 
physical subnet, then the connection must be handled at the IP layer, 
routed via the gateway, which does effectively takes the lower-level 
connection on one subnet and readdresses it to send on to another hop 
(which may be another router or the destination device).

So if the connection mechanism works at the lower level, very possibly 
deliberately, due to the security benefit of restrictions to the same IP 
subnet, then it won't understand IP and won't know how to route via the 
IP gateway, thus making the connection technically impossible at the 
native level.

Of course there are tunneling mechanisms that can be used to make it 
work, but that's likely adding complexity while lowering the security 
you've deliberately setup by using different networks, and I've no
experience with that either, so couldn't help you there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman