What is the best way to remotely access my PC from my laptop?

Gamer said:

Who has tried this?

I've done similar.

Gamer said:

Any advice?

You have security issues on your hands with this.

You'll have to open up your home network to the global internet one way or another, and that has problems. People 'port scan' for the ability to connect to remote desktop opportunities, or SSH servers, VPN ports, etc.

If you're wanting to do this, you'll have to consider:

- What can/will you do to prevent unauthorised access?

- Can you afford keeping electronics online 24/7 to facilitate what you're doing?

The way I had it setup was this:

- Raspberry Pi running on my local home network with an OpenSSH server, with fail2ban to block any repeated hacking attempts

- Using my router, setup port forwarding with a non-typical port (22 is typical for SSH) to the Raspberry Pi

- Then used SSH tunnelling to my home computer, my home internet has a dynamic IP address, so I had code running on the Raspberry Pi which was able to either e-mail me with the latest IP address, or upload it to a secure location on a website host I had available

- I would then SSH into the Raspberry Pi, I used Windows in this case, so setting up the tunnel and forwarding with Bitvise is relatively straightforward and I can also easily setup X11Forwarding if needed.

- Use WakeOnLAN from the Raspberry Pi to wake up my home computer, that way it didn't need to be turned on all of the time, but WoL setup for its ethernet in the BIOS and Operating System

- Remote desktop or VNC into my home computer

This meant that:

- My connection between the client and home was encrypted with SSH

- While not ideal (SSH being a TCP connection rather than speedier UDP connection) it worked very well

- I always knew what details to connect to my home PC was because the Pi kept the IP address up to date

- I could turn on and off my home PC at will and save power/energy without having to keep it turned on, but keep the Raspberry Pi turned on for less energy use

The downfalls of remote connection like this, is that it isn't best suited for 'remote gaming' or 'remote media playback'. Using remote desktop software performs static image snapshots, and so if you're wanting to do remote gaming/desktop you might instead want to consider using Steam Link or a similar service (incidentally you can do desktop control/streaming with Steam Link, but you have less Wake on LAN support and similar).

I can see why you'd want to remote desktop like this, legal wise you may have software that you want to access which you only have the license for on the remote system (though some software doesn't like you doing this, but it's usually based on one user rather than how it was accessed) and buying a different computer or cut down portable laptop may not be suitable or comparable.

I have a variation of this ... in my case, I needed to also pay for a VPS because the home machine is behind a double-NAT (i.e. carrier grade NAT + router NAT). If you're behind just one NAT, port forwarding will work, but being behind two is pretty much game-over.

As a result, I have a Pi (or equivalent) maintaining a Wiregard tunnel (UDP ftw) to my VPS which is the "lucky" endpoint with a static IPv4. I can then connect to the VPS from my client and access the network as normal at home (subject to how one writes their iptables firewalls). I do have the SSH tunnel and autossh as a backup.

I've got WOL set-up, so the machine at home often sleeps (so can be woken quickly by WOL). But such a set-up has many hoops ... and takes much work to get working the way you want. Sometimes, you just meet networks that are firewalled and won't allow you to connect to non-standard ports, so it may pay to also use a different VPN server that can also handle that.

Your servers will get probed, brute-forced on the regular. Software bugs can also happen. Keeping everything up-to-date is vital.

- Gough

I have a variation of this ... in my case, I needed to also pay for a VPS because the home machine is behind a double-NAT (i.e. carrier grade NAT + router NAT). If you're behind just one NAT, port forwarding will work, but being behind two is pretty much game-over.

As a result, I have a Pi (or equivalent) maintaining a Wiregard tunnel (UDP ftw) to my VPS which is the "lucky" endpoint with a static IPv4. I can then connect to the VPS from my client and access the network as normal at home (subject to how one writes their iptables firewalls). I do have the SSH tunnel and autossh as a backup.

I've got WOL set-up, so the machine at home often sleeps (so can be woken quickly by WOL). But such a set-up has many hoops ... and takes much work to get working the way you want. Sometimes, you just meet networks that are firewalled and won't allow you to connect to non-standard ports, so it may pay to also use a different VPN server that can also handle that.

Your servers will get probed, brute-forced on the regular. Software bugs can also happen. Keeping everything up-to-date is vital.

- Gough

Gough Lui said:

Sometimes, you just meet networks that are firewalled and won't allow you to connect to non-standard ports, so it may pay to also use a different VPN server that can also handle that.

That can be a benefit of a roll your own solution, sometimes it can help to go against the RFCs and re-use a port that's normally meant for say, http traffic :D

We will know the risks and will mitigate, but 99% of users won't, especially those asking such questions, and will not realize it's opening up access to vulnerabilities right to their PC or Pi etc., or will substitute with older or vulnerable hardware or software (near-decade-old old home routers for instance are not unusual). Even the basic ancient SYN attack is still one of the most popular techniques, and that requires no hacking skills.
As an example of old hardware, the home router I was given from the provider I'm using (BT) is a decade old, they've never offered me a free replacement, I've had to buy my own.

The only time I've ever successfully persuaded a client (in their isolated lab) to ever allow remote access, was by using a particular secure VPN protocol trusted by banks, and even then, only open up the VPN connection when required, which entails a remote server, which was in the cloud, so that it could be explicitly shut down at all other times. This remote server was like a stepping stone to establish the VPN between two machines. Using different port numbers was useful, but on it's own is just extending the time until an attack.

Using this technique, we could reduce the attack footprint, since we could place a firewall rule to only allow traffic from a specific IP address + port combination, reducing the risk from random servers, since the cloud server had a known public IP address (this is easy to configure of course), and that known IP could be definitively shut down at all times apart from when the connection was required, since it's in the cloud. We guaranteed what specific device would connect, because once its public IP address was known, it could be entered into the server in the cloud. This was as good as we could manage, using up-to-date hardware/firmware. 

We were reasonably comfortable with this setup, but only on a limited temporary basis to get through some work and then dismantle/unconfigure it all.

(should also mention, obviously, (might not be obvious to some) the "server in the cloud" should at least be IaaS virtual server, not rented hardware. 

That can be done, although just make sure whatever you're using doesn't balk when some scanner tries a legitimate HTTP request at the port ;). Some VPN solutions are designed to do this to some extent by design (e.g. SoftEther).

Setting up a port-knocking sequence is another way to make it less obvious, but necessitates doing things in a certain order and timing.

- Gough

shabaz said:

We will know the risks and will mitigate, but 99% of users won't, especially those asking such questions

And I'm all for responsible disclosure of information/guidance - it's so necessary these days, especially when easy to use tools such as shodan exist. 

Agree, hopefully any reader can see there's a lot to consider when thinking about such stuff. We might have also scared away any future spammers on this thread anyway : )