0

Setting

A small business (too small to justify a Terminal Services Gateway) wants certain users to be able to access their Windows 10 desktops from home.

I have had good luck with Windows Remote Desktop for this purpose, however best practice suggests to not expose the RDP port directly. It is recommended to secure RDP over a VPN, however in the past I have typically setup an SSH tunnel for this purpose, since I was more familiar with that.

I will assume that the client has some computer which can run an SSH server, and will refer to it as SSH_SERVER. In my case, there is usually a Linux or BSD computer already on-premise, either as a file server or acting as the firewall (eg. FreeNAS, pfSense), if not I typically drop in a rebuilt PC specifically to handle this job.

SSH Port-Forwarding Version

In this section I include the details of how I set up the SSH port-forwarding for a client who needs Windows Remote Desktop access.

  1. Setup key-only authentication for SSH on SSH_SERVER and open the firewall to expose this on some non-standard port, <EXT_SSH_PORT>. Note: this is the only external port I ever open, all communication to the network is done via port-forwarding over SSH.
  2. For each client that wants to connect remotely, I generate a user on SSH_SERVER with shell set to /bin/false.
  3. Add SSH restrictions allowing the user to port-forward only for the port and device they want to connect to. For example, I add the following to the /etc/sshd_conf file:
Match User <USERNAME>
  AllowAgentForwarding no
  PermitOpen <USER'S_WINDOWS_DESKTOP_IP>:3389
  ForceCommand echo 'This account is restricted.'

(more in-depth discussion here).

  1. For each device that the user wants to connect with, I generate a key pair which is encrypted with a password which I provide them. I then (a) add the public key to the user's ~/.ssh/authorized_keys file and (b) securely transfer the private key to the user's device.
  2. I create some way of easily setting up the SSH tunnel, either with a simple script which just runs ssh -L 10000:<USER'S_WINDOWS_DESKTOP_IP>:3389 <OFFICE_EXTERNAL_IP> -p <EXT_SSH_PORT> or using helper software (eg. for Mac OS, for Windows).
  3. I add a shortcut for an RDP session to localhost:10000.

This method has worked well enough, but I always felt it was not "professional" enough, and that someday I should convert these SSH tunnels to VPNs.

VPN Limitations

I was exploring this with L2TP/IPSEC (on a UniFi Dream Machine, although I think the limitations here are not specific to the router) and immediately ran into some limitations:

  1. The office network must have a different IP subnet than the client subnet. This would be a minor annoyance, but suppose I could do this. On the other hand, I find it rather unsatisfying that you are essentially just hoping that you will pick a subnet which the client will never happen to be on - what if they are visiting some other company and using their wifi, and you just so happened to pick the same subnet as the IT vendor from there?
  2. Not clear how to restrict communication to a single port for a single PC, per user. I know I can set it up so that VPN users get placed in a separate VLAN and then add firewall rules which limit connections from that VLAN to port 3389 on specific RDP desktops, but that doesn't stop USER_A from trying to connect to USER_B's desktop. If I'm also opening ports other than RDP for some reason, then all VPN users would have access to these ports as well, unless I put each user in their own VLAN, which seems like additional administrative overhead for a feature I basically already have "for free" with SSH.
  3. No clear per-device security. With the SSH approach I mentioned above, if USER_A has their laptop stolen there's no real concern. For one thing, the private key is encrypted, so unless the laptop was stolen while the user was actively connected they should not be able to access the office network. Furthermore, for added security, I can just remove the key associated with the stolen laptop from ~/.ssh/authorized_keys, and all the other devices the client owns (eg. a personal desktop) will continue to work with no additional configuration.

TL;DR: Why would someone prefer to use a VPN over SSH port forwarding?

It seems like the only case where a VPN is preferable is when you want all communication going over the office network and you have some level of awareness/control over the remote network. (Site-to-site VPNs fall under this category.)

Am I missing something here? Do VPNs offer more performance and/or security than SSH port forwarding?

  • 1
    There is no particular reason that "all communication" must go over the VPN. You can instead choose to route only traffic to the office network. – Michael Hampton Aug 31 at 14:24
  • @MichaelHampton Good point, I guess what I meant here is that you want the computer to essentially act as though it is physically plugged into the office network, and therefore you don't need or want significant separation of this remote computer from the rest of the network. In my case, however, these remote computers are normally personal devices, and probably shouldn't be trusted to that extent. They really only need RDP access to their own PC. Even if it is a dedicated work computer, aren't you indirectly exposing the work network to all devices on the user's home LAN when using a VPN? – process91 Aug 31 at 14:28
  • Well, that also is configurable. You are talking about a site-to-site VPN but you wouldn't set up a site to site VPN for a road warrior. – Michael Hampton Aug 31 at 14:34
  • @MichaelHampton Even if it's not site-to-site, it seems like the potential security risks for a VPN are higher than SSH port-forwarding unless you literally have per-user firewall limitations which take the place of what the SSH port-forwarding restrictions do. These appear to be more cumbersome to maintain (i.e. separate VLANs for each user) and it still lacks the per-device key security. – process91 Aug 31 at 14:42
  • Of course. You can and should be firewalling on internal networks and on hosts. – Michael Hampton Aug 31 at 14:45
2

Your proposed SSH solution seems to me to be overly complex for the problem at hand.

Two Suggestions:

  1. Use a VPN in conjunction with a 2FA/MFA solution such as Duo.

  2. If a VPN is problematic then use a different remote access solution, like Teamviewer, AnyDesk, etc. in conjunction with a 2FA/MFA provider such as Duo.

You can create a free Duo account for use with up to 10 users.

| improve this answer | |
  • Maybe this just differs based on experience, I found the SSH setup above extremely straightforward, but then again I was already very familiar with SSH. Based on your answer I checked out Duo, but I can't see how to easily integrate it with the UniFi Dream Machine, and I suppose the only thing this mitigates is the third limitation I mentioned about VPNs. Teamviewer has extremely high fees - for an office where ~ 3 people may be connecting at the same time I would need to pay $200/month?! I tried AnyDesk, but this location has a weak internet signal and RDP was much more responsive. – process91 Sep 1 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.