6

Previously I had my home workstation PC directly exposed to the internet simply by setting it as the DMZ PC in my router's settings, and I could access any services I was running on it: SSH, Web Server, Remote Desktop, etc. I had DynDNS configured and I also own a domain, with a subdomain DNS entry pointing to my router's external IP, so I could remotely access it, any port, from anywhere on the world using a fixed name, be it either home.mydomain.com or myuser.dyndns.com. Life was good.

Now I moved and my new ISP sets me behind a CGNAT, ie, my router's "external" address is in the 100.64.0.0/10 range, so it cannot be reached from the outside anymore (and DynDNS is also dead, but that's irrelevant). ISP does not provide IPv6, unfortunately, and switching ISPs is not an option in my area.

That said, my company recently subscribed a VPS plan for my team, running Ubuntu 18.04, and I have full control over it. I can SSH to it, install any software, configure it to my liking. Currently it only runs SSH on a non-standard port and a small API service on a custom port, all other ports (including 80) are available. I've already set home.mydomain.com as a CNAME DNS entry pointing to it.

So, what's the best strategy to use this new asset to finally have my home workstation PC exposed to the internet as it was before?

While googling for CGNAT circumvention I've read a lot about SSH Reverse Tunnels/Proxying, SOCKS, VPN Servers, but I'm still not sure what is the best tool and setup to achieve the goal in this scenario.

My requirements:

  • Open source, free software only: sure, I have total control over the VPS, but I'd like to keep the extra software fingerprint to a minimum. I'm fine apt install'ing anything from official repositories, and maybe a github repo. On my workstation, also running Ubuntu, I can install more obscure stuff.

  • Self-hosted solutions: Anything that usually requires an external service (paid or not), such as Serveo, LocalTunnel, OpenVPN, etc, I'd like to install its server version on the VPS. I don't want my traffic routed to yet another company I must trust.

  • No client install (preferably): I'd like to access my workstation from anywhere, be it my laptop, a friend's PC, college, work, using regular browsers, SSH clients, Remote Desktop (RDP or VNC) clients, etc, software that are usually already installed or generally available.

  • No punching individual port holes (preferably): It should be as if my workstation is home.mydomain.com, directly exposed to the internet. It's fine if I have to "remap" ports, using a rule such as remote port = local port + 10000 (so web server would be accessible at port 10080), but otherwise I'd like it to be as close to a DMZ as possible.

The closest I got is ssh [-R xx:localhost:yy]... home.mydomain.com on the workstation, using a series of predefined ports, and setting GatewayPorts yes on the VPS /etc/ssh/sshd_config. It's good, but I feel there might be a better solution. It would be awesome if the solution was based on the domain used to access the VPS. For example, only forward (all) requests if accessed via home.mydomain.com, and act normally if reached via vps.mycompany.com

MestreLion
  • 3,045
  • 4
  • 29
  • 23

4 Answers4

4

In my opinion, SSH tunnels are not suitable for this purpose. Of course, it works, but you have to run as many tunnels as ports you want to forward.

VPN is probably the best option to achieve that. You configure the VPN server on the VPS, you connect your home server(s) as VPN client(s), and when you are not home, you connect your laptop or remote computer to this VPN, as a client, and you will be able to reach your home server(s) as if you were in the same local network, you do not even have to assign them a "public IP".

If you want to assign a public IP to one of your home server(s), you will have to configure a second public IP on the VPS (so it stays available from its primary IP), and then, setup 1:1 NAT with the VPS's firewall (iptables). And this home server will be configured to use the VPN as a gateway, so outgoing packets go through the VPS's secondary IP instead of your home ISP's IP.

If you have many home servers, you can do 1:1 NAT if you can get more than 2 IPs assigned to the VPS. Else, you will have to use port forwarding if you want a single IP to be used with different home servers.

Dylan
  • 206
  • 1
  • 3
2

This probably won't help you, but I think it's good to highlight PCP (Port Control Protocol) as fitting this use case. Your ISP would have to support this (I don't know how prevalent ISP support of PCP is, being a pessimist, I'd guess not very...)

PCP is basically one of the latest in the family of UPnP, NAT-PMP type protocols. PCP has MAP and PEER functions that let your client request a port-forward at the ISP level (at their CGNAT). If anyone knows of an ISP doing this (or better yet has actually used it in the real world) I'd love to hear about it.

https://www.rfc-editor.org/rfc/rfc6887

https://en.wikipedia.org/wiki/Port_Control_Protocol

Using PCP (Port Control Protocol) in practice?

Community
  • 1
Brandon Applegate
  • 21
1

Request a static IPv6 prefix from your ISP. Get IPv6 for all your Internet access.

Configure IPv6 tunnelbroker, VPN, or other transition methods for when you only have legacy IPv4 access.

John Mahowald
  • 212
1

Bumped into this problem and although late to the party thought this would help someone.

A simple way to accomplish this is reverse tunneling as follows:

On Client(Machine with no public ip): ssh -R 7680:localhost:7677 root@remotemachine (Do not exit this prompt)

7680 WILL OPEN ON REMOTE MACHINE 7677 IS ALREADY OPEN ON LOCAL/CLIENT MACHINE

On Remote Machine: ssh localhost -p 7680

and you will connect to client.

The problem is the connection will die when you exit the ssh session on Client.

So use autossh which can background:

autossh -M 20000 -f -N -R 7680:localhost:7677 -C root@remotemachine

Now you can exit the shell and the connection will not drop

sardar iftikhar
  • 11