OpenVPN Remote Access Server in pfSense - Setup Guide

OpenVPN is the most widely deployed solution for providing remote employee access to corporate networks through pfSense. The protocol operates in userspace, leverages SSL/TLS for encryption, and can function over TCP 443, enabling connections even from networks with restrictive outbound filtering policies. In pfSense, an OpenVPN remote access server can be configured in two ways: through the built-in wizard for rapid deployment or manually with full control over every parameter.

This guide covers both approaches, from preparing the certificate infrastructure through to diagnosing common connectivity issues. The material is intended for network engineers with pfSense administration experience and a working understanding of SSL/TLS fundamentals.

Certificate Preparation

OpenVPN in SSL/TLS mode requires a public key infrastructure (PKI): a Certificate Authority (CA), a server certificate, and individual certificates for each user. All certificate operations are performed through the pfSense web interface.

Creating a Certificate Authority (CA)

The Certificate Authority is created under System > Certificates > Authorities.

1. Click Add to create a new CA.
2. Fill in the parameters:

3. Click Save.

Creating the Server Certificate

The server certificate is created under System > Certificates > Certificates.

1. Click Add/Sign.
2. Fill in the parameters:

3. Click Save.

Creating User Certificates

Each VPN user requires an individual certificate. Creation is performed under System > User Manager.

1. Open an existing user or create a new one.
2. In the User Certificates section, click Add.
3. Set Method to Create an internal Certificate.
4. Set Certificate authority to OpenVPN-CA.
5. Set Certificate Type to User Certificate.
6. Click Save.

Warning:

Each user should receive an individual certificate. Sharing a single certificate across multiple users eliminates the ability to revoke access for a specific employee without affecting the rest.

Wizard-Based Setup

The OpenVPN Wizard is the fastest method for deploying a remote access server. It automatically creates the CA, server certificate, server instance, and basic firewall rules.

The wizard is launched from VPN > OpenVPN > Wizards.

Fig. 1. OpenVPN Wizard start page in pfSense

Step 1 - Authentication Type

The wizard offers a choice of authentication backend:

• Local User Access - authentication against the pfSense local database. Suitable for small organizations (up to 20 users).
• LDAP - authentication against Active Directory or OpenLDAP. Recommended when an existing directory service is available.
• RADIUS - authentication via a RADIUS server (FreeRADIUS, NPS). Provides the greatest flexibility, including OTP support.

Step 2 - Certificates

When Local User Access is selected, the wizard offers to create the CA and server certificate. If a CA already exists, the previously created one may be used.

Step 3 - Server Parameters

The wizard prompts for the main OpenVPN server parameters:

Step 4 - Firewall Rules

The wizard offers to automatically create:

• Firewall Rule - a rule on the WAN interface allowing inbound connections on port 1194/UDP.
• OpenVPN Rule - a rule on the virtual OpenVPN interface permitting traffic from the VPN subnet to the local network.

It is recommended to let the wizard create both rules and adjust them afterward as needed.

Warning:

The wizard does not create rules permitting traffic between VPN clients (client-to-client). If inter-client communication is required, manual configuration is necessary.

Manual Server Configuration

Manual configuration is performed under VPN > OpenVPN > Servers. Click Add to create a new server instance.

Fig. 2. OpenVPN server parameters in pfSense

General Information

Cryptographic Settings

Tunnel Settings

Client Settings

Advanced Configuration

The Custom options field accepts OpenVPN directives not exposed in the interface:

push "dhcp-option DOMAIN-SEARCH corp.example.com";
push "dhcp-option DOMAIN-SEARCH dev.example.com";
auth-gen-token 0 external-auth;
reneg-sec 3600;

Firewall Rules

Two sets of firewall rules are required for the OpenVPN remote access server to function correctly.

WAN Interface Rules

Permit inbound connections to the OpenVPN server:

When multiple WAN interfaces are in use (Multi-WAN), a rule must be created on each interface through which VPN connections are permitted. For more on firewall rules, see pfSense Firewall Rules .

OpenVPN Interface Rules

After the server is created, pfSense exposes a virtual OpenVPN interface. By default, no allow rules exist on this interface - all traffic from the VPN tunnel will be blocked.

Minimum rule for LAN access:

Warning:

A Source: Any / Destination: Any rule on the OpenVPN interface grants VPN clients unrestricted access to all resources, including pfSense management. Access should be restricted to specific subnets and ports in accordance with the principle of least privilege.

Split Tunnel vs Full Tunnel

The tunneling mode determines which client traffic traverses the VPN.

Split Tunnel

In Split Tunnel mode, only traffic destined for corporate subnets specified in the IPv4 Local Network(s) field passes through the VPN. All other traffic (internet, public resources) exits through the client’s local gateway.

Advantages:

• Reduced load on the VPN channel and the corporate internet gateway.
• Preserved access to local resources (printers, IoT devices).
• Lower latency when accessing public services.

Full Tunnel

In Full Tunnel mode, all client traffic, including internet traffic, is routed through the VPN. To activate, enable the Redirect IPv4 Gateway flag in the server settings.

Advantages:

• All traffic passes through the corporate filtering and inspection infrastructure.
• Clients are protected from attacks on untrusted networks (public Wi-Fi).
• Uniform application of security policies.

DNS servers must also be configured via push options to prevent DNS query leaks:

push "dhcp-option DNS 10.1.0.1";
push "block-outside-dns";

The block-outside-dns directive works only on Windows clients and prevents use of DNS servers obtained from the local network.

Combined Approach

For individual users, the mode can be overridden through Client Specific Overrides. For example, information security staff may use Full Tunnel while other employees use Split Tunnel.

Client Specific Overrides

The Client Specific Overrides mechanism allows individual parameters to be set for specific VPN clients. Configuration is performed under VPN > OpenVPN > Client Specific Overrides.

Assigning a Fixed IP Address

To bind a permanent IP address to a specific user:

1. Create an entry in Client Specific Overrides.
2. In the Common Name field, enter the CN from the user’s certificate (typically matches the username).
3. In the Advanced field, enter:

ifconfig-push 10.8.0.100 255.255.255.0;

Granting Access to Additional Subnets

To route traffic from a subnet behind the client (for example, when working from a home office with a local network):

iroute 192.168.100.0 255.255.255.0;
push "route 192.168.100.0 255.255.255.0";

Warning:

The iroute directive operates only within OpenVPN and must be accompanied by a corresponding route at the server level (IPv4 Remote Network(s) field or push "route ..."), as well as a firewall rule permitting traffic to the specified subnet.

Overriding DNS and Gateway

For a specific user, DNS servers and the tunneling mode may be overridden:

push "dhcp-option DNS 10.1.0.53";
push "redirect-gateway def1";
push "block-outside-dns";

Multi-Factor Authentication

Basic certificate-plus-password authentication provides two factors: possession (certificate) and knowledge (password). For additional hardening, time-based one-time passwords (TOTP) are recommended.

TOTP via FreeRADIUS

1. Install the FreeRADIUS package via System > Package Manager.
2. Configure the RADIUS server on the localhost interface (127.0.0.1), port 1812.
3. Create users with OTP profiles - each user receives a secret for TOTP generation (compatible with Google Authenticator, Microsoft Authenticator).
4. In the OpenVPN server settings, set Backend for authentication to RADIUS and specify the FreeRADIUS parameters.

During authentication, the user enters the password in the format <password><TOTP-code> (concatenation of the primary password and the six-digit code).

LDAP with Two-Factor Authentication

When using LDAP (Active Directory), two-factor authentication is implemented through:

• Duo Security - a package available in pfSense that provides push notifications.
• RADIUS proxy - LDAP authentication routed through a RADIUS server supporting TOTP (for example, privacyIDEA or LinOTP).

DCO - Data Channel Offload

Data Channel Offload (DCO) is a mechanism that moves OpenVPN data processing from userspace into the operating system kernel. This eliminates the overhead of context switching between the kernel and the OpenVPN process, significantly increasing throughput.

DCO Characteristics

DCO Limitations

DCO is incompatible with the following configurations:

• tap mode (tun only).
• Compression - must be disabled.
• Unauthenticated ciphers (CBC without HMAC).
• The --fragment option.
• Peer-to-Peer (Shared Key) mode.

To enable DCO, set the Data Channel Offload flag in the server parameters. If the configuration is incompatible, pfSense will display a warning.

Warning:

Enabling DCO on an existing server will disconnect all current sessions. Clients must support DCO (OpenVPN 2.6+). Plan the transition for a maintenance window.

Troubleshooting

Client Cannot Connect

1. Verify the WAN firewall rule - ensure port 1194/UDP is open. Verification: Diagnostics > Packet Capture on the WAN interface, filtering by port 1194.
2. Check OpenVPN logs - Status > System Logs > OpenVPN. Key messages:
   • TLS Error: TLS handshake failed - certificate issue or TLS key mismatch.
   • AUTH_FAILED - incorrect credentials or a locked account.
   • Connection reset, restarting - routing or NAT problem.
3. Verify time synchronization - a discrepancy exceeding 5 minutes between server and client will cause certificate validation to fail.
4. Check the CRL (Certificate Revocation List) - if a CRL is configured, verify that the client certificate has not been revoked.

TLS Handshake Failed

Most common causes:

• TLS key mismatch - the key on server and client must be identical. Regenerate the client configuration using the openvpn-client-export package.
• Expired CA or server certificate - check validity dates under System > Certificates.
• Encryption algorithm mismatch - verify the client supports at least one algorithm listed in Data Encryption Algorithms.
• MTU issues - TLS packet fragmentation. Add to Custom options: fragment 1400; mssfix 1400.

Connected but No Resource Access

1. Check the OpenVPN interface rules - ensure traffic from the VPN subnet is permitted.
2. Verify routes - on the client, run route print (Windows) or ip route (Linux) and confirm routes to corporate subnets are present.
3. Check the Local Network(s) field - if a subnet is not listed, the route will not be pushed to the client.
4. Verify return routing - devices on the corporate network must have a route to the VPN subnet (10.8.0.0/24) via pfSense. If pfSense is the default gateway, the route exists automatically.

DNS Query Leaks

In Full Tunnel mode, clients may continue using local DNS servers:

1. Verify that DNS Server 1-4 are populated in the server settings.
2. Add push "block-outside-dns" to Custom options (Windows only).
3. On macOS and Linux, DNS leaks are prevented through resolv.conf update scripts included in the client configuration.

Fig. 3. Status > OpenVPN page - active connections and statistics

Related Sections

• OpenVPN Site-to-Site Tunnel - connecting sites via OpenVPN in Peer-to-Peer mode
• Client Configuration Export - generating ready-made configuration files and installers using the openvpn-client-export package
• IPsec Mobile Clients - an alternative remote access method using the built-in IPsec client
• pfSense Firewall Rules - creating and managing rules for VPN traffic control