Running a Certificate-Based OpenVPN Server on pfSense: Configuration, Firewall Rules, and Export Pitfalls

If you need remote access into a network behind pfSense, the most supportable answer is a UDP OpenVPN server on the WAN interface, certificate authentication from the built-in certificate manager, narrowly scoped firewall rules on the auto-created OpenVPN interface, and the Client Export package for distributing profiles. This is all native functionality — no third-party VPN concentrator required — but the order in which you build it, and a few subnet and rule decisions, determine whether it works cleanly or produces the classic "connected but can't reach anything" ticket.

The steps below assume a current pfSense CE or Plus release. Menu labels differ slightly between versions, so treat screen names as approximate and confirm against your installed release.

Certificates first, server second

OpenVPN on pfSense authenticates clients with TLS certificates, so the PKI must exist before the server wizard can do anything useful. Under System > Cert. Manager you need three things: a certificate authority (create an internal CA dedicated to the VPN rather than reusing something else), a server certificate issued by that CA, and one user certificate per remote user, also issued by that CA.

Two operational points matter here. First, back up the CA and its private key somewhere off the firewall — if the CA is lost, every issued client certificate becomes unverifiable and you reissue everything. Second, decide now how you will revoke certificates. Create a certificate revocation list (CRL) under the CA entry and attach it to the OpenVPN server later; without a CRL, deleting a user does not actually cut off their access.

The server configuration that avoids most problems

Under VPN > OpenVPN > Servers, add a server (the wizard walks through the same fields). The settings that carry real consequences:

• Interface and port: WAN, UDP, port 1194 (or another approved port). UDP is the right default. TCP/443 is tempting because it slips through restrictive guest networks, but running a reliable transport inside a reliable transport causes retransmission stacking and visibly worse throughput under packet loss. Offer TCP only as a secondary server instance if you genuinely need it.
• TLS authentication: enable the TLS key (auth or crypt mode). This adds a static HMAC signature check so unauthenticated packets are dropped before TLS negotiation, reducing exposure of the TLS stack itself.
• Tunnel network: an IPv4 subnet that exists nowhere else in your routing table — for example 10.99.8.0/24 when your LAN is 192.168.10.0/24. Overlapping the tunnel subnet with a LAN or with a client's home network is the single most common cause of intermittent, half-working access that gets misdiagnosed as a firewall problem.
• Local networks: list only the LAN subnets clients should route through the tunnel, e.g. 192.168.10.0/24. These are pushed to clients as routes. Leave redirect-gateway off unless you intentionally want all client Internet traffic hairpinned through the firewall.
• Server hostname: clients reach whatever address the export profile contains. If the WAN IP is dynamic, set up a dynamic DNS hostname first and use it consistently.

Saving the server does two things automatically: pfSense begins listening on the WAN address (with an auto-generated hidden WAN rule permitting the chosen port), and a dedicated OpenVPN interface tab appears under Firewall > Rules for traffic coming out of the tunnel.

Firewall rules: the part people skip

A working tunnel is not authorization. Traffic from connected clients is evaluated against the rules on the OpenVPN interface tab, and the default posture depends on what you put there. A convenient but weak pattern is a single pass-all rule; it makes the first test easy and then tends to become permanent.

A defensible baseline looks like this, in order:

Build the pass-all rule first if you want, prove connectivity, then replace it with scoped rules and re-test. The explicit final block with logging is useful: denied attempts show up in the firewall log, which makes later "why can't I reach X" questions answerable in seconds.

Exporting client profiles without breaking them

Install openvpn-client-export from System > Package Manager. It adds a Client Export tab under VPN > OpenVPN that generates per-user .ovpn files or bundled installers with the CA, user certificate, and server settings embedded.

Export failures are almost always consistency failures: the profile embeds whatever the server currently says. If you change the port, protocol, or hostname after exporting, previously distributed profiles silently point at the wrong endpoint. Re-export and redistribute after any server change. Also confirm the export's "Host Name Resolution" field matches the address clients can actually reach — exporting the firewall's LAN-side hostname is a classic mistake.

Verifying the whole path

Test from a genuinely external network (a phone hotspot works):

1. Import the profile, connect, and confirm the client receives an address in the tunnel subnet (e.g. 10.99.8.2).
2. Check Status > OpenVPN for the authenticated peer and the OpenVPN logs for a completed TLS handshake with no repeating auth or TLS errors.
3. Reach one permitted LAN service, then attempt one destination your rules deny. Both results should match the rule table — the denied attempt should appear in the firewall log.
4. Review the WAN rules and the OpenVPN interface rules one final time to confirm the listener rule and client rules reflect the design, not leftover test rules.

Limits and mistakes worth planning around

Certificate lifecycle is ongoing work: user offboarding means revoking the cert against the CRL and re-exporting nothing — revocation takes effect server-side. Throughput is bounded by the firewall's CPU since OpenVPN is single-threaded per instance; on low-power hardware expect tens of megabits, not gigabit. And keep the pfSense configuration backup current (the built-in AutoConfigBackup or manual exports) — the CA, CRL, server config, and rules are all in that one file, and it is your entire recovery plan.