Homelab Reverse Proxy - Part 3 - OpenVPN Server Setup
This is a series of articles about running a reverse proxy; stay tuned via RSS when more parts will be published.
In this part, we will be setting up our OpenVPN Server.
In the last part, we created several certificates that will be used by our server. We need to import them into the pfsense certificate manager.
First, let’s export our Certificate Authority public certificate and import it to pfsense. Right-clicking on the Reverse Proxy CA certificate in xca, selecting Export > Clipboard will give us just the public portion of the certificate.
Importing root CA into pfsense certificate management
Next, I’ve imported the OpenVPN server certificate. This time, we need to export public and private keys. Exporting the public key from xca is similar to the root CA (selecting OpenVPN Server Certificate of course); however exporting the private key is performed from the Private Keys tab.
If you try to export the private key from xca, it will ask what format you want the key to be in. Pfsense expects a PEM format, so select PEM private.
Importing OpenVPN server certificate into pfsense certificate store
Now, what about the client certificate? OpenVPN will validate client certificates that are issued by our CA, more on that below.
Creating the OpenVPN server
We can finally create our OpenVPN server!
Most of the general stuff I left at defaults. However just for remote servers, I like to pick another port from the standard OpenVPN 1194 port.
Most of the parameters in the next section are fairly well explanatory and well documented, but I like to keep a few things worthy of note:
Always use TLS Encryption and Authentication
(this parameter becomes available after Saving server configuration, so be sure to re-visit configuration after you save it).
Save the automatically-generated TLS key for later use by our client configuration
(again, this will become available after server is created).
- Select our CA for the peer certificate authority and our imported server certificate as appropriate.
- I explicitly pick AES-256-GCM (256-bit key, 128-bit block) as the default encryption algorithm and either disable NCP Algorithms or add AES-256-GCM and AES-128-GCM there as well. We are not planning on supporting wide range of clients and devices, so this is probably fine here.
- Picking SHA256 or better as your hash algorithm is generally a good idea.
- Enabling hardware crypto engine is a good idea if your CPU has on-die instruction set to support it (AES-NI)
The Tunnel Network section deals with where our servers will be placed on the network. It is generally a good idea to pick a dedicated
subnet for the clients and in fact required if OpenVPN server operates in tun (Layer 3) mode as in my case.
I prefer something like
192.168.45.0/24 as my subnet. I also adjust IPv4 Local network(s) setting to make sure that OpenVPN server can route my packets
to the correct subnet of my homelab on which internal VMs to be exposed are hosted at.
I suggest using a special “DMZ” subnet with strict inbound & outbound firewall rules for VMs hosted there as a fail-safe against certain attacks and system compromise. Generally whenever I setup a reverse proxy system like this, only VMs in a DMZ subnet are exposed.
One thing that I explicitly disable in this case is duplicate connections. Ideally there is only ever one connection per client [certificate] and re-using credentials across VMs is generally a bad practice. One advanced scenario could be running two reverse proxy VMs that act as load balancers, in which case issuing each their own credentials would be a better way.
As for DNS settings, I run pihole at home, which is an excellent DNS service (more on that later). I generally use pihole as the first DNS server with pfsense’ resolver as a back-up or the back-end server. Your reverse proxy VMs need to resolve internal VM host names to IPs on your network, and for DNS Server 1 it’s almost always my pihole server.
Our VPN server is ready to be used
Finally, a firewall rule needs to be created to allow traffic to the VPN Server from anywhere (that is, the Internet) on the WAN interface to port 1196 (the port we picked); later I will be implementing an IP Whitelisting scheme to further restrict traffic to only come from known public IP addresses of reverse proxy VMs that will be created.
pfsense firewall rule allowing Internet traffic to reach our VPN server
In the next parts, I will be creating a virtual machine that will act as the reverse proxy:
- Connect to our homelab using OpenVPN
- Run caddy server to obtain Let’s Encrypt certificates and proxy our service
- Takeaways locking down access and network traffic
Continue to Part 4 − Virtual Machine setup.