Roman Bezlepkin’s Website

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.

Importing certificates

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.

pfsense CA import 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.

pfsense importing OpenVPN server certificate 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!

New OpenVPN server - general defaults 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:

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.

OpenVPN Server created 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 to allow VPN traffic 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:

Continue to Part 4 − Virtual Machine setup.