When I’m not at university, I spend approximately 4 months of the year working interstate. Since I’m the self designated network administrator of my share house, it’s important that I’m able to change the network configuration even when I’m not at home. pfSense facilitates a solution to this problem in the form of OpenVPN Support. This tutorial will describe the process of configuring OpenVPN, and is an adaptation of the Netgate Documentation on the process
To start, navigate to VPN > OpenVPN > Wizards and start the Wizard.
Choose the desired authentication settings. For the purposes of this tutorial, we will select “Local User Access”. Other options include LDAP and RADIUS, however these won’t be addressed here.
Choose “Local User Access”, then click “Next”.
Certificate Authority Selection
Select “Add a new CA”
Fill in the following fields as appropriate:
- Descriptive Name: Used as the Common Name (CN) for the Certificate Authority (CA). Don’t use any spaces, punctuation or special characters. I’ve chosen “HomeAccessCA”
- Key Length: Default is OK; higher is better but it will use more CPU. I’ve selected 2048 for this.
- Lifetime: The lifetime of the CA in days. Default is OK; It can be lowered but this will mean you go through this process more frequently. I’ve chosen 3650.
- Country Code, State or Province, City, Organization: Enter information as appropriate.
Select “Add new CA”
Server Certificate Selection
Select “Add new Certificate”
Fill in the following fields as appropriate. This is largely the same as the previous step, with a change in the descriptive name. The values I’ve used are shown below:
Select “Create new Certificate”
General OpenVPN Server Information
- Interface: This is the interface where OpenVPN will listen for incoming connections, typically your WAN.
- Protocol: Your choices here are to select either TCP or UDP. Each has their own benefits, and the choice between them will depend on your specific needs. A brief summary of the practical differences between these protocols will be shown below. For now, select “UDP on IPv4 only”.
- Local Port: Default is 1194. Use the default unless you have reason not to.
- Description: Provide a name for the OpenVPN instance for administrative purposes. I’ve chosen “Home Access VPN”.
TCP vs UDP
- Better Reliability: The TCP packet includes an error correction header, and guarantees delivery of data. The flipside to these benefits is that there is a considerable overhead both in terms of size and speed as packet receipt needs to be acknowledged, retransmitted as appropriate and re-acknowledged etc.
- Bypass Firewalls: When operated on port 443, TCP is almost indisitinguishable from a HTTPS SSL conection, making it very difficult to block, as identifying the connection as VPN and not SSL traffic is itself very difficult.
- Slower Speed: As mentioned previously, these benefits have the overhead of slower speeds and larger packet sizes
- Faster Speed: UDP packets are much smaller than TCP packets and can be transmitted much faster, making this protocol the preferred method for QoS traffic such as VoIP, streaming media, gaming etc.
- Lower Reliability: UDP packets don’t contain the same error correcting headers, which makes it faster at the expense of reliability. A packet may not reach its destination in the form it was sent, and has to be retransmitted. UDP does not guarantee delivery of packets.
As general advice, use UDP unless you have issues or a specific reason to use TCP.
- TLS Authentication: Leave this checked. This mitigates against OpenSSL attacks such as Heartbleed.
- Generate TLS Key: Leave this checked, unless you already have a key you want to use.
- TLS Shared Key: Leave blank unless you already have a key you want to use, in which case paste it here.
- DH Parameters Length: The default is 2048. This is a common selection as of 2016. Larger keys will provide more security, however will take considerably more time to generate and slow the connection down.
- Encryption Algorithm: There are a number of options you can select here. I will address some of the differences between the block ciphers for AES. You’ll have to do your own research for the others!
- CBC (Cipher Block Chaining): Uses previous block ciphertext to XOR with next block plaintext. This creates a dependence between blocks such that if any block has been altered, decryption won’t be possible.
- CFB (Cipher Feedback): Similar to CBC, except each blocks ciphertext is encrypted before the XOR operation with the nextblocks plaintext to generate its ciphertext. Creates a dependence between each block such that decryption isn’t possible if a block is altered.
- OFB (Output Feedback): The input vector of each block is encrypted and then forms the next blocks input vector. Each encrypted input vector is XOR’d with each block plaintext to produce ciphertext. This creates a pseudo-random input vector for each block and preserves dependency between each block. This has the advantage of being able to pre-generate the keystream, however there will be a cycle in the pseudo random input vector. Practically however, this period is likely to be very large.
- GCM (Galois/Counter Mode): Efficient and performant block cipher due to it’s ability to leverage parallel processing.
A more detailed analysis of each of these block ciphers can be found here.
In equivalent systems, GCM has performance improvements of 5-6x over CBC, and so would be my recommendation all else being equal. Having said that, one thing to consider is what algorithms have hardware acceleration support for your hardware. My system uses the Intel Atom E3845, which provides hardware acceleration for RSA, DSA, DH, AES-128-CBC, AES-192-CBC, and AES-256-CBC. Unfortunately no GCM. To quantify the difference that this makes, you can utilise OpenSSL from the command line interface. SSH into your router and give the following commands:
$ openssl speed -evp aes-256-cbc $ openssl speed -evp aes-256-gcm
Then compare the output. My results are below:
As you can see, hardware acceleration makes a reasonably large impact, as AES-256-CBC is approximately 5 times faster than AES-256-GCM; an inversion of what we would expect if all things were equal.
TLDR; Select what’s appropriate for your system, I’ve selected AES-256-CBC
- Auth Digest Algorithm: The default setting here is SHA1, which has been deprecated as of 2016. My understanding is that this field is ignored if you selected a GCM encryption algorithm as the GCM algorithm incorporates integrity checking into the encryption/decryption process, however if you chose a method that is reliant on the auth digest algorithm, ensure that you select at least SHA256. BlueKrypt suggest that this is sufficient for near term protection (up to 2028). I’ve selected SHA512, which BlueKrypt suggest is sufficient for long term protection (through to 2068).
- Hardware Crypto: Select this if you have it! I’ve selected “BSD cryptodev engine”.
- Tunnel Network: This should be a new, unique network that does not exist anywhere in the current network or routing table. I’ve selected 192.168.70.0/24
- Redirect Gateway: Force all client generated traffic through the tunnel. Checking this depends on your use case. If you want to route all of your remote traffic through your home server, check this. This was not particularly important to me as the primary purpose of this is remote access to configure the network, so I left this unchecked.
- Local Network: This is the network that will be accessible from the remote endpoint, expressed as a CIDR range. My LAN is on subnet 30, so I entered 192.168.30.0/24.
- Concurrent Connections: Specify the number of clients allowed to concurrently connect to this server. I left this blank.
- Compression: Select “Omit Preference (Use OpenVPN Default)”
- Type-of-Service: Leave unchecked
- Inter-Client communication: I checked this as I wanted to be able to administer my home servers remotely, but use your best judgement for your purposes.
- Duplicate Connections: Leave this unchecked unless you have good reason to check it.
- Dynamic IP: Checked
- Topology: Select “Subnet — One IP address per client in a common subnet”
- DNS Default Domain: Leave Blank
- DNS Server 1: Set to google DNS 188.8.131.52
Leave the rest blank, or populate as it suits your scenario.
Firewall Rule Configuration
- Firewall Rules: Checked
- OpenVPN Rule: Checked
These will automatically add the necessary rules to the firewall to allow these connections.
Now you’ve finished the wizard. Click “Finish” to complete.
The result of this is that firewall rules have been added for the WAN and OpenVPN interfaces (See these at Firewall > Rules). Verify that you had the following rules added:
Some settings are not presented in the wizard, but are a better fit for some situations than the defaults chosen by the wizard. Navigate to VPN > OpenVPN > Servers and select the “Edit” icon for the server you just created. The biggest one to look for is the “Server Mode” setting. The default setting for this is “Remote Access (SSL/TLS + User Auth)”, however there are a couple of other Remote Access alternatives:
- Remote Access (SSL/TLS + User Auth)
- Requires both certificates *and* username/password
- Each user has a unique client configuration that includes their personal certificate and key
- Most secure as there are multiple factors of authentication (TLS Key and Certificate that the user has, and the username/password they know)
- Remote Access (SSL/TLS)
- Certificates only, no auth
- Each user has a unique client configuration that includes their personal certificate and key
- Useful if clients should not be prompted to enter a username and password
- Less secure as it relies only on something the user has (TLS key and certificate)
- Remote Access (User Auth)
- Authentication only, no certificates
- Useful if the clients should not have individual certificates
- Commonly used for external authentication (RADIUS, LDAP)
- All clients can use the same exported client configuration and/or software package
- Less secure as it relies on a shared TLS key plus only something the user knows (username/password)
I have “Remote Access (SSL/TLS + User Auth)” selected. Confirm that the rest of the settings are accurate, and press “Save”.
Add User Certificates
- Navigate to System > User Manager
- Click “+Add” to add a new user
- Populate the “Username”, “Password”, and “Full Name” fields
- Check the “Click to create a user certificate” check box.
- Enter the username in the “Descriptive name” field
- Select the correct certificate authority, in my case this was “HomeAccessCA”
- Key Length: 2048 bits
- Lifetime 3650
- Click “Save”
This process can also be completed for existing users in a similar fashion.
Install the OpenVPN Client Export Package
- Navigate to System > Packages > Available Packages
- Find “openvpn-client-export” in the list, and install.
Export the configuration
- Navigate to VPN > OpenVPN > Client Export
- Choose the VPN from the “Remote Access Server” Dropdown
- Select the options as appropriate for your needs in the upper sections. The defaults are typically OK
- Find the user in the list at the bottom of the page, and select the appropriate configuration type to export
This will look like this:
I use a MacBook Pro along with Tunnelblick. Tunnelblick prefers the configuration file as a .ovpn file, so I download the “Viscosity Inline Config” option. Depending on your client and it’s configuration requirements, this may change for you.
Assigning Users a Static IP
To assign a user a static IP, navigate to VPN > OpenVPN > Client Specific Overrides and press “Add”
- Select the VPN Server from the Server List
- Enter the username as the “Common Name”
- Enter the desired IP and netmask for “IPv4 Tunnel Network”: I entered 192.168.70.10/24 for my user
- Leave the rest blank and press “Save”
This is useful if you need to add users to an IP access list.
And you’re done! You should now be able to connect to your home network remotely, using a secure VPN.
To disclaim this guide somewhat, I am by no means a security expert and this guide only reflects my own best understanding at the time of writing. Make sure you do your own research to confirm what works best for your situation. Additionally, if you have found something that’s inaccurate in my post, please leave a comment and I’ll update it as soon as I can!
14 thoughts on “How to configure an OpenVPN Remote Access Server in pfSense”
Thank you! This is a very thorough instruction and exactly what I needed. I’m interested in acquiring either a MBT-2220 or a MBT-4220, exclusively for use as a OpenVPN Server.
This is my scenario:
I want to put an MBT-X220 box with pfsense behind a residential Time Warner cable modem. Use port forwarding on cable modem(Technicolor MediaAccess TC8715D) to add port 1194 for incoming OpenVPN client connections to the pfsense box. Since I have a dynamic IP assigned every once in a while, I will have to configure pfsense to use a NO-IP.com account to update it’s current IP to the DDNS Service.
It would seem rather obvious that my intention is to have the connected OpenVPN clients be able to access the local network and I will also have the clients use the Internet freely where the OpenVPN server is set up. But, am I missing something? I’ll be at this location for just one night and I would have to connect the pfsense box and do all the configuration in just a few hours.
List of things to do:
-Pfsense OS setup following the wizard
-Configure port forwarding for port 1194 on the cable modem
-Configure port forwarding, if necessary, to use pfsense’s DDNS client to set up a NO-IP account. I just need to make sure it can go through the cable modem and get the public IP from the modem and not the NAT address on the pfsense’s WAN interface.
-Use your guide to configure OpenVPN
-Test a client from a remote location. Speed and DNS tests, as well as making sure that the clients have access to several Internet services with the cable modem’s public IP.
-Enable remote management on pfsense for maintenance or configuration changes
Since I’m not going to be on site after set up, I’m worried that the MBT-4220 could have the risk of the fan failing eventually, that is the only reason why I would opt for the MBT-2220. But then again, going from dual to quad core for a mere $20 would seem like a no-brainer, but the MBT-2220 would give me the peace of mind knowing that there are no moving parts in the setup that would need maintenance. If I’m not on site and the fan fails, it could be risky since it won’t be set up in a special fire-safe room.
Could you share your thoughts on my intended setup?
Luis, I’m by no means an expert, but from what you’ve described your plan seems sound. I’ve not used pfSense’s DDNS client however, so I’m not sure if there would be any issues to consider there. If I’m interpreting correctly, you want to route all of the clients internet traffic through the VPN tunnel? If that’s the case, your configuration will differ slightly from what I’ve presented in my guide. Notably, you’ll need to check the “Redirect Gateway” checkbox when it comes to Tunnel Settings.
As far as selection of the router goes, I’m not sure fan failure will be a huge consideration. Have you ever had a fan fail on you before? Your choice here seems to depend more on your performance requirements. If the fan is a big consideration, Protectli make a router with the same Intel E3845 CPU as the MBT-4220, in a fanless configuration. It does seem marginally more expensive, though. Hope this helps!
It does help. You’re right on me wanting to direct all traffic on the clients through the tunnel. I’ll check the Redirect Gateway configuration out.
I was reading a document on their site(Protectli), and it seems that core count doesn’t affect OpenVPN throughput using pfSense, encrypted or unencrypted. It seems to me that CPU architecture difference is what allows for faster rates. https://protectli.com/kb/openvpn-performance/
If this holds true, then there would be no real benefit with my intended use case in going from dual to quad core with NetGate, and with their current sale, with the included RAM and 32GB SSD, it does come a bit more affordable.
Although fans haven’t failed on me, depending on the setting they do sometimes accumulate dust from its environment and some eventually get noisy and/or slow. I will be able to give it maintenance maybe once or twice a year.
Thanks for your comments.
hello thank you ,i want ask u if a port forwarding 1194 is important to have remote Access , i have a @ip public static
Hi wahiba, as you can see this is the port forwarded to in the rule generated by the wizard. You shouldn’t need to specify these rules manually though; the wizard will take care of it.
Can you send me a network diagram of what you are accomplishing here? I don’t understand which of the “Tunnel Network” and the “Local Network” is for the LAN and the WAN ports, or if I am thinking about this correctly.
wow absolutely explanation and configguration well done. waiting for complete OPNsense firewall lessons
Should the IP be 192.168.70.10/32 in the Assign Users a Static IP section? I appreciate the explanations for the different choices. I have a remote VPN UDP/1195 and want to add one on TCP/443 in case the other is blocked. Can I follow the same steps and have both available to me? Do all server and client VPNs have to be on different ports? Thanks
I have this up and working well. However there’s one thing I dont understand: I have exported the settings to my (android) phone and a viscosity install on my mac.
When I connect remotely my phone lets me connect to my pfsense box (192.168.1.1) on my home network but the Mac sees the router on the server I am connecting from (generic wifi box), exactly same settings. Weird.
Nic, more detail required. When you say the Mac “sees” the router on the server you’re connecting from, what do you mean? Do you mean the local router does DNS resolution for you? You’re on two networks here, so both networks should now be routable by your Mac. You can confirm this with
ifconfigin the terminal on your Mac. It should show two IP addresses; one in your local network, and another in the
Sorry for the lack of detail. Let’s see if I can be more clear.
First off I want to use the VPN to reach my home network when I’m away.
Pfsense serves that network at 192.xxx.x.1 Freenas is at 192.xxx.x.10 for example. On my phone with the setup/config from the Tutorial I can open a browser and access Pfsense and Freenas remotely.
When I try and do the same thing on the Mac ,192.xxx.x.1 takes me to the router on the home network of the person I am using wifi from to vpn into my network – so it doesn’t seem like I’m tunneling in properly if I’m seeing that (not my) network. Does that make more sense?
Hi Nic, this makes sense. When you join remotely you join the network on a different subnet. This is specified in the ‘Tunnel Network’ field in the ‘Tunnel Settings’ section. If you used the value I specify,
192.168.70.0/24, then you’ll join on the
192.168.70.xsubnet. If you try accessing
192.168.70.1you should see your router. If you didn’t use the
70subnet, you can find what you’re connected to using
ifconfig. The reason you’re seeing the router on the external network is because your device is part of both. Establishing a VPN connection doesn’t remove you from the network you’re connected to – you need it to establish and maintain the connection 🙂
Samuel – ok, I live and learn. Thanks mate!