Saving an initial configuration without changing anything gives these errors:
Self signed certificate
If you are OK with self-signed certificates, then the first is solved by using this as the Server certificate:
Certificate authority
The second needs an additional step: you have to select or create a certificate authority first at hostname/system_camanager.php?act=new where hostname is the hostname or IP address of your pfSense configuration.
This order is actually explained in [WayBack] OpenVPN – The Open Source VPN: HOWTO and [WayBack] OpenVPN Configuration (pfSense) – ELITS, but I like stronger security.
For the Internal Certificate Authority (CA), use at least these settings:
- “Key length (bits)” at least
2048bits, but I prefer3072bits (to be safe after about 2030) as per- Key size: Asymmetric algorithm key lengths – Wikipedia via
- Let’s Encrypt supports it for local certificates, but are more flexible for their CA as you have to renew at least every 90 days; Support for >4096 bit keys – Feature Requests – Let’s Encrypt Community Support
- “Digest Algorithm” at least
sha256, but I prefersha512as it will be safe for a longer period of time. - “Lifetime” by default is
3650(10 years); can you keep your VM safe for that long? If longer, you can increase the lifetime, but also have to ensure you take large enough values for theKey lengthandDigest Algorithm.
You can view the possible settings in [WayBack] pfsense/system_camanager.php at master · pfsense/pfsense · GitHub.
Straightforward parameters
Use a TLS Key- Enabled
TLS Key- Generated by OpenVPN
TLS Key Usage Mode- TLS Authentication
Peer Certificate Authority- Name of your pfSense device
Peer Certificate Revocation list- N/A: handled in System -> Certification Manager
Use a TLS Key- Enabled
Use a TLS Key- Enabled
ECDH Curve- Use Default (as we do not use Elliptic Curve)
Hardware Crypto- If the
RDRANDinstruction is available, this choice allows to use it. I think OpenVPN (via OpenSSL) on BSD uses this in a similar way as Linux: i.e. not as the only source for randomness. See [WayBack] Torvalds shoots down call to yank ‘backdoored’ Intel RdRand in Linux crypto • The Register - You can check if RDRAND is available in OpenSSL using the
/usr/bin/openssl engine -t -ccommand:
Via: [WayBack] Are cryptographic accelerators supported – pfSense Documentation
- If the
Further encryption hardening
DH Parameter Length- One problem here is that pfSense ships with pre-generated Diffie Helman (DH) parameters:
This means they can potentially be re-used as an attack-vector, so you need to manually re-generate them as per [WayBack] DH Parameters – pfSense Documentation by using
/usr/bin/openssl dhparamIn order to speed that up, you have to either manually add a lot of entropy, or ensure your VM uses the host entropy by installing the
open-vm-toolsand rebooting.This can take quite some time as it depends on
/dev/randomas a pure random number source, which will wait if there is not enough initial entropy available yet (see [WayBack] prng – differences between random and urandom – Stack Overflow).In order to speed that up, you have to either manually add a lot of entropy, or ensure your VM uses the host entropy by installing the
open-vm-toolsand rebooting.On a single-coreIntel(R) Xeon(R) CPU E5-2630L v4 @ 1.80GHz, the timings of these
/usr/bin/openssl dhparam -out /etc/dh-parameters.1024 1024
/usr/bin/openssl dhparam -out /etc/dh-parameters.2048 2048
/usr/bin/openssl dhparam -out /etc/dh-parameters.4096 4096using the [WayBack] FreeBSD Manual Pages: time command are (each measured twice):
- ~4.5 seconds for 1024 bits:
- ~23 seconds for 2048 bits:
- ~150 seconds for 4096 bits:
- You see that even within the same length, the duration varies highly.
- ~4.5 seconds for 1024 bits:
- Given you already burned those CPU cycles, choose the largest one:
4096
- One problem here is that pfSense ships with pre-generated Diffie Helman (DH) parameters:
Encryption Algorithm- This comes down into selecting a algorithm-length-mode combination, so
- There are three parts in the choice
- Algorithm: in my configuration, I could choose between algorithms based on AES, CAMELLIA, CAST5, DES, DESX, IDEA, RC2 and SEED.
- IDEA, DES, RC2, …. are considered insecure (see the above links).
- DESX is considered insecure if you know enough plain-texts.
- Triple-DES (of which DES-EDE3 is is a mode) slow and only used for compatibility with legacy applications, see [WayBack] block cipher – Modes of Triple DES – When to use each? – Cryptography Stack Exchange
- SEED is hardly used outside South Korea.
- AES, CAMELLIA and CAST5 are considered very strong, with Intel and AMD processors having CPU support for AES**, so I prefer
AES.
- Length: AES has these parameters of which I choose the largest ones:
- Key sizes128, 192 or 256 bits[1]
Block sizes128 bits[2]
- Key sizes128, 192 or 256 bits[1]
- Mode: There are so many three-letter-acronym encryption modes that this area is very confusing.
[WayBack] How to choose an AES encryption mode (CBC ECB CTR OCB CFB)? – Stack Overflow helps a lot. [WayBack] php – Is there any difference between aes-128-cbc and aes-128 encryption? – Stack Overflow does not.
From what I have read so far, GCM (Galois/Counter Mode) is the best mode at the time of writing, but by the time you read this, ensure you find a post containing all the TLA in the presented list.
- Algorithm: in my configuration, I could choose between algorithms based on AES, CAMELLIA, CAST5, DES, DESX, IDEA, RC2 and SEED.
- All in all, I end up at
AES-256-GCM(256 bit key, 128 bit block)- Note this is supposed to be the OpenVPN 2.4 default ([WayBack] Authentication Algorithm and Encryption Cipher Algorithm · Issue #276 · kylemanna/docker-openvpn · GitHub), but at 2.4.3 it is
AES-128-GCM.
- Note this is supposed to be the OpenVPN 2.4 default ([WayBack] Authentication Algorithm and Encryption Cipher Algorithm · Issue #276 · kylemanna/docker-openvpn · GitHub), but at 2.4.3 it is
- There are three parts in the choice
- This comes down into selecting a algorithm-length-mode combination, so
Enable NCP(Negotiable Cryptographic Parameters)- I enabled this, because I consider the ones below safe enough. If you just want to go for one algorithm, then disable this.
NCP Algorithms- See the previous one; only list the algorithm-length-mode combinations that you want to allow.. Since I am on AES, prefer GCM, and all key sizes are considered safe, my list is the one on the right:
This is in decreasing order of secureness:AES-256-GCMAES-192-GCMAES-128-GCM
- See the previous one; only list the algorithm-length-mode combinations that you want to allow.. Since I am on AES, prefer GCM, and all key sizes are considered safe, my list is the one on the right:
Auth digest algorithm- Starting from scratch (when you have to configure clients),
SHA512(which I use) orSHA256is fine. Do not useSHA1unless you need backward compatibility with pre 2.4 OpenVPN installations or pre-configured clients. See [WayBack] How safe to change default SHA1 to other encryption algorithm?
- Starting from scratch (when you have to configure clients),
Certificate depth- For now it is 1 (as it is self-signed)
- In the future I will experiment with proper (hopefully Let’s Encrypt) signed certificates. I am not yet sure if that might need a larger depth.
Other settings
All networks are in CIDR notation, like 192.168.3.0/24.
IPv4 Tunnel network- Choose from Private network: Private IPv4 address spaces – Wikipedia.
I usually pick172.x.y.0networks as they are far less used than192.168.x.0and10.x.y.0networks. Note that some networks starting with172are in public use, so limit yourself to172.16.0.0 – 172.31.255.255.
- Choose from Private network: Private IPv4 address spaces – Wikipedia.
IPv6 Tunnel network- I still need to implement IPv6 in full, so that is empty for now.
IPv4 Local networks- These are my local networks. Still need to test how well routing works, but given the default gateway knows about them too, I do not suspect problems.
IPv4 Remote networks- Empty as I do not use site-to-site VPN yet.
IPv4 Remote networks- I still need to implement IPv6 in full, so that is empty for now.
Concurrent connections- Still need to measure performance, so empty for now.
Compression- I kept the default “Omit Preference (Use OpenVPN Default)”.
- I might choose
compression lz4orcompression lz4-v2in the future.
Push compression- Kept to unchecked: I dislike other VPN connections to push settings to me, so I do not want to push settings to others.
Type-of-Service- Kept to unchecked, although I might opt for checked later on: need to do some testing first.
Inter-client communication- Kept to unchecked: I do not want clients to talk to each other in this particular network, though I might for some specific OpenVPN setup
Duplicate Connection- Kept to unchecked
Dynamic IP- I have enabled this as I expect clients to switch IP addresses because of switching between networks
- [WayBack]
Topology: choosesubnet(usenet30only for old 2.0.9 client compatibility on Windows; usep2pif you only have non-Windows clients)
Advanced client options- All defaults, as currently I do not run an internal DNS, but those will probably change in the future:
- DNS Default Domain
- DNS Server enable
- DNS Server 1..4
- Force DNS Cache Update
- All defaults, as currently I do not run an internal DNS, but those will probably change in the future:
Custom options- None, but I will need to do some deeper reading on the possibilities here
UDP Fast I/O- Disabled as experimental
Send/Receive Buffer- Default, although I might increase this if speed is too slow.
Gateway creation- I choose the default
Both
- I choose the default
Verbosity level- Default
Enabling AES
Even if the underlying Intel/AMD processor supports AES, it is not enabled by default in pfSense as per web UI home page:
Intel(R) Xeon(R) CPU E5-2630L v4 @ 1.80GHz
AES-NI CPU Crypto: Yes (inactive)
I was quite surprised, but then remembered that enabling RDRAND in the OpenVPN settings was also non-default and dug a bit deeper into ….
There I found you have to go to the System menu, choose Advanced, then the Miscellaneous tab:
From there, browse down (or search for Hardware) to “Cryptographic & Thermal Hardware”, then enable the CPU based accelleration:
After pressing the Save button at the bottom, you are done:
AES-NI CPU Crypto: Yes (active)
I got this via [WayBack] AES-IN Inactive?, which also mentions this:
- AES-NI loads aesni.ko
- BSD Crypto loads cryptodev.ko
- AES-NI and BSD Crypto loads both
Note that AES – as of FreeBSD-10 – AES-NI and other hardware implementations are only indirectly incorporated into /dev/random. The Linux kernel already did this in an indirect way. I think that is a good idea as when multiple entropy sources are merged together, it makes it much harder to influence to total entropy. FreeBSD implemented this using the Yarrow algorithm – Wikipedia and now has moved to a successor, the Fortuna (PRNG) – Wikipedia.
More background information:
- AES instruction set: Supporting x86 CPUs – Wikipedia
- RdRand: Reception – Wikipedia.
- [WayBack] 201308DevSummit/Security/DevRandom – FreeBSD Wiki
padlock ACE support
Note there is a message about ACE support on the console and in the boot log that is related to AES:
padlock0: No ACE support.
aesni0: <AES-CBC, AES-XTS, AES-GCM, AES-ICM> on motherboard
The cause is that in the past, VIA PadLock Advanced Cryptography Engine (ACE) in the mid 2000s introduced encryption acceleration (see [WayBack] VIA PadLock support for Linux) a few years before AES-NI, so ACE is incompatible with AES-NI. AES-NI is now much more widespread than ACE, even the wikipedia VIA page padlock information has been removed.
An odd thing: unlike AES-NI which needs to be specifically enabled, VIA Padlock is always enabled, see
OpenVPN Client Export Package
Ensure you install the (optional, but highly recommended) [WayBack] OpenVPN Client Export Package:
Allows a pre-configured OpenVPN Windows Client or Mac OS X’s Viscosity configuration bundle to be exported directly from pfSense.
These config files work with Tunnelblick as well, which is a great free and open source OpenVPN tool on Mac OS X / MacOS:
- [WayBack] Tunnelblick | Free open source OpenVPN VPN client server software for Mac OS X and macOS
- [WayBack] GitHub – Tunnelblick/Tunnelblick: The official Tunnelbick website is at https://tunnelblick.net; the official Tunnelblick GitHub repository is at https://github.com/Tunnelblick
Creating and exporting users
I have yet to cover these two; for now read [WayBack] How to setup OpenVPN on pFSense? | IT Blog and [WayBack] OpenVPN Remote Access Server – pfSense Documentation.
Further reading
I like this overview a lot:
- [WayBack] How to setup OpenVPN on pFSense? | IT Blog
- [WayBack] How to setup OpenVPN (pFSense version) on client PC | IT Blog
–jeroen
