There are many tools, devices and programs that by default run a http server and expose a user interface on port 80. Even my coffee machine has a web ui that it provides on port 80.

Now, it's easy to make these existing webservers available through the internet by simply doing port-forwarding on the internet facing NAT.

I want to do this, but I want to password protect access to them in a simple, generic and secure way.

On simple way would be to just NOT expose them and access them only through a VPN connection. Currently I'm doing this - but I want to be able to access the services without a vpn tunnel from anywhere in the web.

So, let's say I have three http services in my Lan that I locally can access on


Now I want to be able to access them over the internet by going to


But for all of them, I want that they are ONLY accessible after some form of user-password authentication.

I don't need individual users/passwords for the different servers. Can be all the same.

What's an easy but yet secure way to expose all these three services to the internet, without having to tamper with the http servers on these devices themselves? (by secure I mean that without knowing the password it won't create a trivial security hole. I don't worry about man-in-the-middle attacks or so).

Tools I have available to solve this:

  • Adding an additional server running any linux distro/services to the local network
  • Set portforwarding on my NAT
  • 3
    Add a reverse proxy in front of it which requires authentication. Can be done with nginx, apache, ... . Google is your friend for details, but see for example here. Mar 25, 2020 at 10:18

2 Answers 2


The common way to solve such problems is to put these systems behind some reverse proxy (i.e. nginx, Apache, ...) and require authentication for this reverse proxy. In this case only the proxy which requires authentication can be accessed directly from the outside but the systems behind the proxy can only be access through the proxy with authentication. This allows also the mapping of the path you want as long as application behind the proxy does not enforce absolute path.

A different approach is to have some external service which is used to connect the user with the internal server and which requires authentication. In this case some internal connector will connect to the external access proxy and will forward any traffic from the access proxy to the internal server. The access proxy or the internal connector will do the authentication of the user:

 internal-server <--> internal connector --> external access proxy <-- user

One advantage of this approach is that no explicit port forwarding needs to be done. This approach is for example done by ngrok or access proxies by Cloudflare, ZScaler, Akamai...


As a first approach, I would suggest an ssh connection with validation (password or certificate) to get you into your home network. SSH port forwarding will then get you to your CoffeeMachine or whatever. You could also setup a VPN server, but fundamentally that's the same as ssh.

Make sure you have Fail2Ban running on your SSH machine to avoid getting pounded by the World + Dog.

Since this is a home connection and not a business connection, odds are that at some point your ISP will begin blocking your SSH server port as contrary to their terms of service. If this happens you can:

  • Play move the port number games with your ISP.
  • Reverse Proxy though a VPS . Amazon low data rate VPS’s can be had for free.
  • Pay for a commercial grade connection with your ISP.
  • @schroeder - ssh port forwarding to HTTP is common practice. Mar 26, 2020 at 23:14
  • Ah, that should be made clearer. It currently reads that the full circuit is ssh. You are suggesting creating an ssh tunnel.
    – schroeder
    Mar 26, 2020 at 23:16
  • @schroeder - I see that not only did you delete your original comment indicating you did not understand, you also deleted my response to it. No one knows everything and everyone makes mistakes. Don't abuse your power. Mar 26, 2020 at 23:55
  • What abuse? I now understand and that comment thread is no longer relevant.
    – schroeder
    Mar 27, 2020 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .