Should I use client certificates?

For the best security you should use client certificates. The main drawback, particularly for enterprise deployments is distributing the certificates as they have to be generated on the firewall and then passed to the client device. As the certificates are owned by the user, not by the device, it is not enough to configure the VPN on a device and then allow any user to log in with their credentials to access the VPN, the certificate will need to be added for each user account wishing to access the VPN from a given device. pfSense has tools to make this deployment a bit easier but the level of administrative overhead will still be the main consideration in deciding whether to use client certificates. For this guide I will describe the steps required to set up OpenVPN with client certificates but will mention when a step needs to be modified or omitted if you choose not to use them.

Configure OpenVPN Server

Create a Certificate Authority

As OpenVPN is based around OpenSSL, it requires at least the server to have a certificate. If you are planning to use client certificates you will need a CA to issue them. From the pfSense dashboard, go to System > Cert. Manager > CAs and click Add to create a new CA. Enter a descriptive name to help you identify what the CA is called and a common name which will appear on the certificates. The rest of the settings can be adjusted if required but the defaults should provide a reasonable balance between security and performance for most use cases. By default the CA lifetime is set to 3650 days (10 years) which is reasonable for a CA but can be adjusted if desired. If you wish you can also include location and organisation data but this is entirely optional.

Once you save, you should see your OpenVPN Client Access CA in your list of Certificate Authorities, you can now use this CA to sign the certificate we will use for our OpenVPN server. From the Cert. Manager screen, go to Certificates and click Add/Sign. You will now need to provide a descriptive name for your certificate, provide a common name for the certificate and change the Certificate Type to Server Certificate. All other values are optional. The common name should be the public (WAN) IP address of your firewall or, if you have a DNS record pointing at that IP, you can use that as well. This name must match up with the host identifier that clients will use to connect in otherwise you will get warnings about certificate errors. If you would like the certificate to work for multiple domain names or for either the domain name or IP address, you can add other Alternative names at the bottom of the page. If the user accesses the VPN via any of the specified names they will be treated as equivalent to using the common name.

Install Client Export package

pfSense provides a package called openvpn-client-export which creates preconfigured OpenVPN profiles for you to download containing all the VPN settings and the user certificate if one is used. For Windows users it also allows you to download an OpenVPN client installer which will automatically install the OpenVPN client application and configure it with the VPN settings. This step is optional as you could configure the client settings manually but in most cases, doing it will simplify deployment.

From the pfSense dashboard go to System > Package Manager > Available Packages and search for the openvpn-client-export package. Click the Install button to install it.

Configure the VPN server

Go to VPN > OpenVPN > Servers and click Add. On this page we will set all the settings for the server side of the OpenVPN connection. The page is broken down in to several sections and the following subheadings describe the options in each section.

General Information

The only required change in this section is to change the Server Mode to one of the Remote Access options. I will use Remote Access SSL/TLS + User Auth but if you do not plan to use client certificates you can just stick with User Auth. The settings on this page will be the same whichever option you choose. The other setting you may wish to change is the listening port. By default OpenVPN listens on port 1194 in either UDP or TCP mode. You can change the port if you wish, either based on personal preference or if you are on a network which blocks VPN traffic or outbound ports. In these cases you may wish to use a port which is almost never blocked such as 53/UDP (DNS), 123/UDP (NTP) or 443/TCP (HTTPS) as these ports are almost never blocked. That said, you should use UDP if you can due to an issue called TCP Meltdown which can occur when tunnelling a TCP connection over another TCP connection. The issue occurs when one TCP connection detects an issue in the connection and compensates either by resending a packet or re-routing. As this then introduces an unexpected delay in the traffic it can then cause the other TCP connection to detect an issue and also attempt to retransmit packets which is then detected as a fault by the underlying connection and so on. This significantly reduces the performance of the tunnel and should be used as a last resort in situations where no UDP ports can be used. Finally, you should set a descriptive name so you can identify the VPN tunnel later. This is particularly useful if you have multiple tunnels configured.

Cryptographic Settings

Most of these settings can be left as default for a typical setup. The only one which needs to be changed is the Server Certificate. Use the one we configured previously. Additionally you may wish to not use a TLS key. The TLS key is a shared key used to authenticate control packets, meaning unauthenticated packets can be immediately dropped. If you are using the client export package you have no reason to disable this but if you want to configure the clients manually this may become an additional administrative complication that you might not want. Finally, if your hardware supports it, enable hardware crypto acceleration to speed up the VPN and reduce load on your CPU

Tunnel Settings

Here we define the network configuration for the traffic inside the tunnel. Our only required settings are the IPv4 Tunnel network and IPv4 Local Network(s). The IPv6 tunnel network and IPv6 Local Network(s) are also required if we want to send IPv6 traffic across the tunnel but these are not covered here. The tunnel network is the network that the members of the tunnel will use. The first usable address in the range will be used by the server and any other addresses will be available to be handed out to clients. The tunnel network will need to be in a private address range and it must be a range that is not used by other networks that the firewall has access to as this would cause routing conflicts. It is also advisable to not use a common range such as 192.168.0.0 as this is likely to cause conflicts on the client side if you are connecting in from networks which may use this range. We will use the range 172.16.45.0/24 in this example.

The IPv4 Local Networks are networks that pfSense has access to which you would like to make available to devices on the VPN. In most cases this will be your LAN but if you have multiple interfaces configured on your pfSense you may want to expose some or all of these over the VPN tunnel. You can use commas to separate multiple local networks.

You may also want to optionally use the gateway redirection settings to force all traffic to go through the VPN, not just the traffic destined for your LAN. This may be useful when you are using untrusted public WiFi to ensure all your traffic goes through your home or office internet connection.

Client settings

Most client settings can be left at their default values for most configurations. If you are running your own DNS internally, whether on pfSense itself or on another DNS server on your network, you will probably want to push this DNS server to your clients so they can access internal resources using domain names instead of IP addresses. For Windows networks you may also want to enable the settings to block DNS leakage, force update the DNS cache and enable NetBIOS over the VPN if it is required.

Once all settings are entered, hit Save and you should see your new VPN server in the list of available OpenVPN servers.

Add firewall rules

To finalise the server setup we need to create two firewall rules. Firstly, we need to allow traffic on port 1194/UDP to access the WAN interface of the firewall, then we need to allow traffic connecting over the VPN to access our LAN network.

Go to Firewall > Rules > WAN and add a rule with the following settings:

If you elected not to run your VPN server on port 1194 you will need to set the port range to “other” and manually enter the port number unless you are using another well known port such as DNS (53) in which case you can just select that option.

Next, go to the OpenVPN tab and create a rule. For the purposes of this exercise we will allow all traffic passing through the VPN to be forwarded but if you wanted to selectively allow traffic (e.g. can access web services on server2, files on server5 and DNS on server10 but can’t access anything else) you can of course create a more restrictive rule set here.

Adding a user

Our OpenVPN server is now fully set up but at present cannot be used as no users have been granted access to it. To do this we will need to create a user. Go to System > User Manager and add a user. You will need to configure a username and password as per the picture below. The other settings can be left as default although if you are only planning to grant the user temporary access you may want to set the account to expire automatically when access is due to be revoked.

Once the user is created, if you are using user certificates to authenticate you will need to create a certificate for the user. In the user list, select pen icon next to the user you have created to edit it. Scroll down to the User Certificates section and click “Add”. Set the Common Name to match the username and leave all other settings as default. Repeat these steps for any other users you need to add.

Configure Client Settings

The easiest way to configure client settings is to use the openvpn-client-export package we installed earlier. Go to VPN > OpenVPN > Client Export. At the bottom of this there is a section called OpenVPN Clients. In this section you will see a list of available users whose configuration we can export.

In the Export column we see various options for configuration export. For most devices, the inline configurations will be used. These are text files containing the server settings, certificates and private keys which will be needed to configure the VPN. These can be loaded in to an OpenVPN client and will appear as an available connection. For Windows PCs which do not have OpenVPN already installed, you can use the Windows Installer options to download an executable installer which will install the OpenVPN software and preconfigure it for use by that user.

Windows setup

For Windows 7, 8 or 10 and their corresponding server versions you will want to use the 2.4.8 branch of OpenVPN client. For Windows XP or Vista (shown as win6 in this interface) you will need the older 2.3.18 branch (also, upgrade your PC). Download the installer you want and transfer it to the target PC. Download the correct installer and copy it to your target PC. The installer behaves like any standard Windows installer, just run it, click the “install” button and follow the prompts.

Once installed, open the OpenVPN GUI App from the start menu and log in with the username and password you configured. The first time you run this you will need to allow OpenVPN through the firewall which will require admin rights but these should not be needed for subsequent connections.

Once the handshake is complete the VPN should be connected. You can verify this by moving to a different network, either public WiFi or a mobile hotspot and opening your firewall’s LAN IP address in a web browser. If everything is working you will see the pfSense login page.

The post Remotely connect to your network using OpenVPN and pfSense appeared first on David's Homelab.

So why WireGuard? Yes, I know that it is still in beta and hasn’t had any significant security auditing but it provides several advantages for this type of setup. Firstly, it is a lot simpler to configure than OpenVPN or IPSec as it doesn’t require any PKI and uses shared keys in a way which will be familiar to OpenSSH users. WireGuard also doesn’t need to recreate the tunnel whenever the connection is lost so you can roam between different networks without having to restart the connection. This is particularly handy on mobile phones where you might want to route some traffic such as DNS (pi-hole) over a VPN so you have ad-blocking regardless of the network you are connected to.

While I like WireGuard for personal devices or for site-to-site VPNs I won’t pretend it’s perfect for everything. WireGuard doesn’t support DHCP or allow username and password logins for the VPN, it has to be configured on a per-device basis and therefore might not be the ideal choice for corporate remote access VPNs. Additionally its newness and lack of security auditing make it a poor choice if you need it to protect highly sensitive information.

Setup

Preparing your network environment

If you do not have too many network services already set up which would be impacted by an IP address change and your network uses a common subnet such as 192.168.0.0/24, 192.168.1.0/24 it is worth adjusting your DHCP settings on your LAN to use a more uncommon subnet. This is because when you connect in from a public network your endpoint’s local IP will probably be in one of these ranges, leading to an address conflict. i.e. if your PC tries to access 192.168.1.20, your PC may route this down the tunnel or try to access that host on its local network (e.g. coffee shop WiFi). While it is possible to work around this using static routes it is a pain so, if possible, try to use an uncommon subnet on your home LAN.

Preparing your WireGuard endpoint

I will be demonstrating the setup using a CentOS 7 server and Ubuntu 18.04 client but the majority of steps can be adapted for any other Linux distribution with a little effort so if you plan to use a different distribution or even Windows or macOS for your server many of the instructions should be applicable.

From your fresh CentOS 7 install, run yum -y update to install any available updates

Install WireGuard from Copr by running the following commands as root:

curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo
yum install epel-release
yum install wireguard-dkms wireguard-tools

If installing on another distribution, instructions for installing on basically anything can be found on WireGuard’s website.

Configuring your server

We will be configuring our tunnel using the wg-quick script which comes as part of the wireguard-tools package. This tool reads a config file from the /etc/wireguard directory by default so this is where we will place our config file. Make the directory and change the permissions so it can only be accessed by the root user:

mkdir /etc/wireguard
chmod 700 /etc/wireguard
cd /etc/wireguard

We now need to generate our private and public keys for the server. These act similarly to SSH keys in that the private key will only be stored on the server and the public key will be copied to the peer configuration for all of the clients. The public key from the client will in turn be copied to the peer configuration on the server. To generate a keypair run the following command as root:

wg genkey | tee private.key | wg pubkey > public.key

This will give us two files called private.key and public.key containing the respective keys which can be added to the config files.

We now create a config file for the tunnel. When the tunnel is active the interface name will be taken from the name of the config file so wg0.conf will result in an interface called wg0. Name the file however you like according to your preferred interface name but note that the name must end with .conf for wg-quick to detect it. Open the config file in your preferred text editor and enter the following basic configuration. I have added comments above each line to explain what it does:

[Interface]
# This is the virtual IP address, with the subnet mask we will use for the VPN. Note that this must not be on our LAN subnet and should be an uncommon subnet to avoid address conflicts
Address = 10.125.37.1/24
# The PostUp instructions are commands to be run when the VPN tunnel is activated, in this case we configure forwarding of traffic across the tunnel and enable NAT on eth0 (if you are using a different interface change this value)
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# PostDown instructions are instructions to be run when the tunnel is deactivated. In this case we simply delete the firewall rules we created when the connection is brought up.
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# This is the port the server will listen on, use any unused port for this as there is not an official one
ListenPort = 51845
# Copy the private key you saved to /etc/wireguard/private.key
PrivateKey = [your private key]

As our server will be acting as a router, we will need to enable IPv4 forwarding by running the following command:

sysctl net.ipv4.ip_forward=1

To make this change persistent across reboots we also need to add the following line to /etc/sysctl.conf

net.ipv4.ip_forward=1

Finally, open port our chosen port in the firewall:

firewall-cmd --permanent --add-port=51845/udp
firewall-cmd --reload

We can now test our configuration by running the following commands:

wg-quick up wg0
wg show

If all is well, wg show should output something like this:

[root@wg wireguard]# wg show
interface: wg0
  public key: ljDbmpp6GLMigE19i4gRqzypnQ29ptZT91N0Lyt3pBg=
  private key: (hidden)
  listening port: 51820

We can now take the interface down by running wg-quick down wg0 and begin configuring our first client

Configuring a client

Much like the server, we begin by installing the WireGuard packages. For Ubuntu this is done by running:

sudo add-apt-repository ppa:wireguard/wireguard
sudo apt-get update
sudo apt-get install wireguard

We will also need to install resolvconf as it is not installed by default on Ubuntu

sudo apt install resolvconf

Like on the server we create our /etc/wireguard directory, lock down the permissions and create our public and private keys:

mkdir /etc/wireguard
chmod 700 /etc/wireguard
cd /etc/wireguard/
wg genkey | tee private.key | wg pubkey > public.key

Again, we make our wg0.conf file using the following template:

[Interface]
# Use an address on the same subnet as our server
Address = 10.125.37.20/24
# Set a port to listen on. This can match the listen port on the server but it doesn't have to
ListenPort = 51845
# The private key you just generated
PrivateKey = [key from private.key]
# If you want to use a specific DNS server for this connection specify it here, multiple servers can be specified by separating them with commas
DNS = 10.100.4.20

Again, we can bring the interface up using wg-quick and check if wg-show produces output to check our configuration.

Making the hosts talk to each other

We now have WireGuard interfaces on each host that are ready to accept connections so it is time to tell them about each other. For this we need to inform each endpoint the other’s public key and IP address by adding a [Peer] section to wg0.conf on each host.

For the server our wg0.conf file should now look like:

[Interface]
Address = 10.125.37.1/24  # This is the virtual IP address, with the subnet mask we will use for the VPN
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = [server private key]
[Peer] # client 1 ## it is advisable to make a comment by each peer to say what it refers to as the list of peers quickly becomes confusing once several have been added
PublicKey = [client public key]
AllowedIPs = 10.125.37.20/32

One important point to note here is that the subnet in the peer file refers to all the IP addresses which can be routed via that peer so if the peer only has a single IP address it must be entered as a /32 regardless of what subnet the peer believes itself to be on. If you wanted to configure a site to site VPN you would specify a range here and enable IP forwarding on both ends of the tunnel.

We now edit the wg0.conf file on the client to tell it about the server:

[Interface]
Address = 10.125.37.20/24
ListenPort = 51845
PrivateKey = [client private key]
DNS = 10.100.4.20
[Peer] # server
Endpoint = wireguard.mydomain.com:51845
PublicKey = [server public key]
AllowedIPs = 0.0.0.0/0

As the client will be initiating the connection we must set an endpoint. This can just be an IP address but as you most likely have a dynamic IP address on your home network your best option is to set up dynamic DNS and use the hostname as your endpoint. If your endpoint is behind a NAT (it probably is), make sure to set up port forwarding on your gateway to send connections on port 51845 to your WireGuard server.

Additionally, you will notice that the AllowedIPs for the client is not a single host. This is because we want to route multiple IPs via our tunnel. In this case we will be routing all traffic through the tunnel but you can specify only certain networks by entering a comma separated list (e.g. 192.168.20.0/24,10.100.4.0/24,10.125.37.20/24). If you only want certain networks to be routed via the tunnel make sure that the network your tunnel endpoints are part of is part of the list otherwise it won’t work. In this case this is 10.125.37.20/24.

Testing the connection

If all has gone to plan our connection should now be correctly configured, we can now bring the interface up at both ends by running the following command on the server and then on the client:

sudo wg-quick up wg0

If we now run wg show on the client or the server we should see something like the following:

interface: wg0
  public key: WMZmhRHmrIQSJ+szXnuhtnH9twSA+6YJe7ADluXyq3E=
  private key: (hidden)
  listening port: 51845
  fwmark: 0xca6c
peer: ljDbmpp6GLMigE19i4gRqzypnQ29ptZT91N0Lyt3pBg=
  endpoint: wireguard.mydomain.com:51845
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 888 B sent

If we now ping our server we should get responses and see the transfer statistics in wg show increasing. We should also be able to access network resources on the LAN side via our tunnel. Assuming all has gone to plan, you now have a VPN which can protect your data when connecting from untrusted networks and allow you to access resources on your home network.

Running WireGuard as a service

wg-quick comes with a built in systemd service, you can easily configure WireGuard to start on boot by running:

systemctl enable wg-quick@wg0.service

If you have called your interface something other than wg0 adjust your service name accordingly

The post Access your home network from anywhere with WireGuard VPN appeared first on David's Homelab.