HomeLab Reverse Proxy - Part 1
This will be a series of articles about running a reverse proxy; stay tuned via RSS when more parts will be published.
I run a home lab. A home lab is simply a micro (or mini for some) data center at your house. This generally means a few servers (physical or VMs) running self-hosted services for your own file sync (such as Nextcloud), or a remote gateway (such as Guacamole, or a website for example.
Although a VPN tunnel is useful to access your self-hosted services, some of these services can selectively be exposed to the internet via a reverse proxy. This exposure may bring convenience for you and others, but care must be taken to make sure you do not sacrifice security and privacy while doing so.
A reverse proxy in this case is a single entry point to select few services you decide to expose. Benefits of running a reverse proxy in front of your service(s) can be:
- Automatically requesting/renewing Let's Encrypt certificates
- Caching
- Request-limiting
- Authorized requests (e.g. via client certificates)
- Load balancing
Architecture
In this example, we will expose Nextcloud (running in a VM at home) to allow user phones and PCs to connect without requiring a user to connect via a VPN first.
This of course comes with risks, as your private Nextcloud service is now exposed to the wide Internet; therefore care must be taken to harden the Virtual Machine and/or the container running Nextcloud (and everything else in between and up the stack). From here on out, you’re doing this at your own risk. So take care.
Blue: VPN tunnel and connections; Black: general connectivity; Red: client's request
We have a small PC running pfsense acting as our DNS, DHCP, and OpenVPN server. It is also our network router/gateway and firewall behind our ISP modem (“perimeter firewall”).
We will need to run an OpenVPN Server on our pfsense firewall as it will give us an entry point into our home(lab) network for our remote proxy server to connect to and eventually reach our internal Nextcloud server.
Our nextcloud server is hosted at nextcloud.homelab.example.org and lives on a subnet 192.168.30.0/24 (e.g. 192.168.30.0−192.168.30.255 address space).
We have configured our DHCP server to always give an IP address of 192.168.30.10 and hostname nextcloud to our Nextcloud VM based on its MAC address.
This makes it more convenient to create restrictive (permissive?) firewall rules in the future to further isolate and control traffic.
I decided to pick Microsoft Azure as the hosting provider in this example, but the concepts here can be implemented anywhere else. In Azure-speak, NSG is a Network Security Group, essentially a simple firewall you can place in your Virtual Network to allow or deny traffic based on where it is coming from or going to. You need Virtual Networks and NSGs to create Virtual Machines.
For the Virtual Machine, I‘ll use an ubuntu base image with lowest SKU size (to minimize cost — we aren't doing so much compute or disk I/O here to warrant anything bigger, much less on a shoe-string budget!).
This Virtual Machine will be used to run two things: our tuned OpenVPN client (to connect back to our homelab) and caddy — a simple and lightweight web server. At the time of writing, I am using version 1.0-stable.
Security Considerations
For simplicity, our Nextcloud service will only listen on plain-HTTP port 80. A better implementation would be creating a custom certificate you can trust (we can't use Let's Encrypt here since the service is too deep in our private network). This certificate of course would have to be trusted by caddy in order to proxy traffic.
In our case, we will expose OpenVPN listening port in our pfsense WAN firewall rules. Since Azure gives us a static IP address for our VM, we can allow traffic to that port only from our VM (IP whitelisting). OpenVPN clients (our VM) will further sit in a dedicated subnet with additional firewall interface configured in pfsense (more on that later).
We will only expose port 80 and 443 inbound to our proxy VM, and only open port 22 when necessary. We can whitelist our current public ISP IP address to allow for port 22 connectivity while we provision our VM and then remove the network security rule. Further SSH management of our VM can be performed by connecting via the OpenVPN client's IP address as pfsense sees it.