Easy pfSense OpenVPN Deployment: Stop Botching Remote Access

7 min. read

The Ticket: The Remote Access Nightmare

A Client bought a new laptop at BestBuy, hopped on an airport Starbucks Wi-Fi, and now can't hit the internal file share. The Tier 1 tech tried building an IPsec tunnel from scratch but accidentally broke routing for the entire site. We need a standardized, split-tunnel OpenVPN deployment that works consistently, doesn't lock out the local LAN, and resolves internal DNS names without creating a routing nightmare.

Pre-Flight Check

• Permissions: Full admin access to the pfSense WebGUI.
• Tools: The openvpn-client-export package.
• Impact: Low - Creating the server daemon does not interrupt existing network traffic, but applying firewall rules will briefly flush the state table.

The Solution

1. Install Required Packages

• Navigate to System > Package Manager > Available Packages.
• Search for and install: openvpn-client-export. (Without this, distributing configs is a miserable manual process).

2. Run the OpenVPN Setup Wizard

• Navigate to VPN > OpenVPN > Wizards.
• Type of Server: Select Local User Access. Click Next.
• Step A (CA): Name it [ClientName]-VPN-CA. Keep Key Length at 2048 bit. Click Add New CA.
• Step B (Server Certificate): Create a new Server Certificate. Do NOT use the default WebGUI certificate.
• Step C (Server Setup): Interface: WAN. Protocol: UDP on IPv4 (Always use UDP for performance). Local Port: 1194.
• Step D (Cryptographic Settings): Check "Authenticate-only" and "Generate TLS Key". Data Encryption: AES-256-GCM. Fallback Digest: SHA256.
• Step E (Tunnel Settings): * IPv4 Tunnel Network: Enter a unique Virtual IP subnet (e.g., 10.10.100.0/24). This must be distinct from the LAN.
  • IPv4 Local Network: Enter the LAN subnet to allow access (e.g., 192.168.1.0/24).
  • Redirect IPv4 Gateway: Leave unchecked for Split Tunnel.
• Step F (Client Settings/DNS): * DNS Default Domain: company.local
  • DNS Server 1: Internal Domain Controller IP (e.g., 10.10.10.5).
• Step G (Firewall Rules): Check both boxes to automatically generate the WAN and OpenVPN firewall rules. Click Finish.

3. Create the VPN User

• Navigate to System > User Manager > Add.
• Create credentials. Check Click to create a user certificate.
• Certificate Authority: Select the CA you just made. Click Save.

4. Export the Client Config

• Navigate to VPN > OpenVPN > Client Export.
• Scroll to the bottom, find your user, and download the Current Windows Installer.

The "Why" (Root Cause)

When junior techs try to build VPNs manually instead of using the wizard, they inevitably screw up the NAT mappings or the routing table. OpenVPN requires a completely distinct Virtual IP (VIP) subnet for the tunnel (e.g., 10.10.100.0/24). If you overlap this with the physical LAN, the FreeBSD kernel's routing table panics because it has two identical subnets with different default gateways.

The wizard automatically injects the push "route 192.168.1.0 255.255.255.0" directive into the server configuration file. This tells the remote Windows client to actively update its local routing table upon connection. Without this pushed route, the remote PC sends traffic destined for the internal file server straight out to its local coffee shop gateway, blackholing the packets. Similarly, if you fail to push the internal DNS server via DHCP options, Windows will try to resolve fileserver.company.local using Comcast's public DNS, which will immediately fail.

Under the Hood (Technical Deep Dive)

Let's talk about the Public Key Infrastructure (PKI) and cryptography happening beneath the GUI. OpenVPN relies on mutual TLS authentication. When you create the CA in the wizard, pfSense generates a self-signed X.509 certificate. The biggest mistake techs make is lazily reusing the pfSense Web Configurator certificate for the OpenVPN server. If you do this, the openvpn-client-export package will silently fail and throw a "Could not locate CA reference" error. Why? Because the WebGUI certificate lacks the required TLS Web Server Authentication Extended Key Usage (EKU) flags in its metadata. The OpenVPN daemon actively rejects it.

Next, look at the cryptographic data channel. The guide specifies AES-256-GCM. Why GCM and not the older CBC (Cipher Block Chaining)? Galois/Counter Mode (GCM) is an authenticated encryption algorithm. It integrates symmetric encryption with a Message Authentication Code (MAC) in a single pass. This means the openvpn daemon doesn't have to waste CPU cycles running a separate HMAC calculation (like SHA256) on every single packet to verify data integrity. GCM inherently resists padding oracle attacks and directly utilizes the AES-NI hardware instruction set found in modern Intel and AMD processors. This drastically reduces the CPU interrupt overhead on your Netgate appliance, maximizing tunnel throughput.

Finally, the firewall rule automation. The wizard automatically injects two critical rules into /tmp/rules.debug. The first is an inbound WAN pass rule on UDP 1194 to allow the initial encrypted TLS handshake. The second is an OpenVPN tab allow-any rule. When the OpenVPN daemon spins up, it creates a virtual tun0 interface. When decrypted traffic exits this virtual interface into the firewall state engine, pf processes it exactly like physical LAN traffic. Without that generated rule, pf drops the decrypted packets by default.

RMM & Automation Tips

Never send a user an .ovpn file and expect them to figure it out. Scale this deployment using your RMM.

• Silent Installs: Download the raw .exe installer from the Client Export tab. Upload it to your RMM repository and execute it silently via PowerShell using the /S flag: Start-Process -FilePath "C:\temp\OpenVPN-Client-Setup.exe" -ArgumentList "/S" -Wait.
• Config Rotation: If a user is compromised, you must revoke their certificate. To deploy the new configuration without the user needing local admin rights, use an RMM script to pull the new .ovpn file from your documentation tool's API, dump it directly into C:\Program Files\OpenVPN\config\, and execute Restart-Service OpenVPNService.

Troubleshooting & Edge Cases

• Edge Case 1: The TLS Handshake Endless Loop: The client connects, but the log loops infinitely on TLS Error: TLS key negotiation failed to occur. This means the client is knocking on the door, but the server isn't answering. It is almost always an incorrect WAN IP in the config (if the client has a dynamic IP that changed), or the WAN firewall rule for UDP 1194 is disabled.
• Edge Case 2: Pinging by IP works, but Hostnames fail: Your split tunnel is working, but the client OS is ignoring the pushed DNS servers. Under the OpenVPN Server Advanced settings, inject push "dhcp-option DOMAIN company.local". This forces Windows to append the correct DNS suffix to flat hostnames.

Wanna set up Multi-WAN on the pfSense next? Then follow our guide on it!