Connecting to a headless machine that is connected to a hotspot connected to my main network

Question

Sorry for the mouthful of a title, hopefully this diagram will make some sense of it;

The solution I have right now is to connect my main workstation to the Raspberry Pi network, then connect to the headless machine via local remote desktop (as both my main workstation and headless workstation are connected to the Raspberry Pi) via this local IP, 192.168.42.1 which works fine.

I would like to be able to connect to the headless machine from my main workstation without having to switch to the Raspberry Pi network thus staying connected to my main host network. I would use a program like Teamviewer but I need the remote connection to be done locally for latency reasons. Of course the IP 192.168.42.1 wont work when connected to my home network is there some way of bridging or making this sort of a connection even possible?

Answer 1

This already sounds like a duplicate of so many questions... but here you go anyway:

is there some way of bridging or making this sort of a connection even possible?

Yes, it's literally what a router is there to do.

The main router, labelled "Home Network (Router)", needs a route describing this connection:

• Destination: 192.168.42.0/24 (mask 255.255.255.0)
• Gateway: 192.168.1.65

Add this through the router's "Static Routes" configuration page. I tried to guess the destination network's prefixlen (netmask), adjust if necessary.

If the "router" doesn't offer this function, plan B is to add the route directly on the Main Workstation instead (e.g. using route -p add if it runs Windows). Of course, that way it'll only affect this one computer.

The Raspberry Pi, and/or the Headless Machine, also need a route in the inverse direction. However, in your case that's already covered by an automatic "local subnet" route on the Pi (or in many other cases by the "default gateway" route), so you don't need to do anything special.

The firewall configuration on Raspberry Pi must allow connections from the home network's IP address range. Ideally, it should also avoid performing NAT for packets to this range (that is, a subnet-specific 'ACCEPT' rule above the generic 'MASQUERADE' one), but thanks to conntrack, outbound replies to inbound connections already bypass it anyway.