How to Set Up an OpenVPN Server on pfSense

Short version of how to set up OpenVPN server on pfSense: run the wizard at VPN > OpenVPN > Wizards, let it build the certificate authority and server certificate, give it a tunnel network that does not collide with anything you own, accept the two firewall rules it offers to create, then install the Client Export package so you never hand-write a client config. The wizard’s defaults, UDP on port 1194 with AES-256-GCM, are the right starting point; the work is in the four or five decisions the wizard cannot make for you. Those decisions are what this guide covers. (If you have not committed to OpenVPN yet, read the OpenVPN vs WireGuard comparison first; for road-warrior access to a homelab, WireGuard is often the simpler answer.)

Decisions to make before you touch the wizard

Authentication backend. pfSense supports four OpenVPN authentication structures: certificates only, user auth only, both combined, and shared key. Pick SSL/TLS + User Auth for remote access. Netgate’s docs call the combination the most secure option because it stacks factors: a stolen laptop still needs the password, a phished password still needs the certificate. Users can live in the local database, LDAP, or RADIUS; local users are fine up to a handful of people.

Do not pick shared key for anything new. It was deprecated in OpenVPN 2.6, which shipped with pfSense CE 2.7.0, and existing shared-key tunnels now throw warnings in the logs and GUI. If you need a two-node point-to-point tunnel, SSL/TLS with a /30 tunnel network behaves the same way without the deprecated crypto.

Tunnel network. This is the subnet VPN clients get addressed from, and it must be unique across every network your clients might connect from. Netgate’s remote access example uses 10.3.201.0/24, with the server taking the first host address as the tunnel gateway. The principle matters more than the number: never use 192.168.1.0/24 or 192.168.0.0/24, because the coffee-shop router your user sits behind is using one of them, and overlapping routes mean traffic silently goes nowhere.

Reachability. Clients need to reach your WAN address on UDP 1194. Behind CGNAT, inbound connections are dead on arrival and you should stop here and rethink (a cheap VPS as a WireGuard rendezvous is the usual escape hatch). On a dynamic residential IP, set up dynamic DNS first and put the hostname, not the IP, in the exported client configs.

Running the wizard

Navigate to VPN > OpenVPN, select the Wizards tab, and choose your authentication backend (Local User Access for the local database). The wizard then walks through three stages:

1. Certificate authority and server certificate. Create a new CA; the Netgate walkthrough uses a 3650-day lifetime, which saves you a CA rollover for ten years. Then create the server certificate signed by that CA. Everything lands in System > Certificates, where you will later mint per-user certs.

2. Server settings. The defaults are sensible: UDP on IPv4 only, port 1194, and a data-cipher list of AES-256-GCM, AES-128-GCM, and CHACHA20-POLY1305. UDP is the correct transport; OpenVPN over TCP stacks two reliability layers and behaves badly on lossy links, which is why the protocol defaults to UDP in the first place. Enter your tunnel network, and in Local Network enter the LAN subnets clients should reach (for example 192.168.20.0/24). Leave Redirect Gateway unchecked for split tunnel (only LAN-bound traffic uses the VPN) or check it to push all client traffic through your WAN; full tunnel is the right call on untrusted Wi-Fi, at the cost of your upload bandwidth. Push your internal DNS server here too, or hostname resolution for internal services will not work over the tunnel.

3. Firewall rules. The wizard offers to create two rules: one on WAN permitting UDP 1194 in from any source, and one on the OpenVPN tab permitting traffic from connected clients. Accept both to get a working tunnel, but note that the OpenVPN-tab rule is an any/any permit. Once you have verified connectivity, tighten it: source = the tunnel network, destination = the specific LAN subnets and ports you actually intend to expose. VPN clients on hostile networks do not deserve implicit any/any into your management VLAN.

After the wizard: clients and cleanup

Install the Client Export package. Under System > Packages, install OpenVPN Client Export; it appears as a new Client Export tab under VPN > OpenVPN. Netgate describes it as the easiest way to configure a client on most platforms, and that is accurate: it emits inline .ovpn configs for Windows, macOS, Linux, Android, and OpenVPN Connect on iOS, plus full Windows installers with the config bundled and Viscosity bundles. Before anything appears in the export list, create each user in System > User Manager with the Click to create a user certificate box checked. One certificate per person per device, so a lost phone means revoking one cert, not reissuing everyone’s.

Consider DCO if you are on pfSense Plus. OpenVPN Data Channel Offload moves data-channel encryption into the kernel, cutting the userspace context-switching that has historically capped OpenVPN throughput. It requires pfSense Plus 22.05 or later, works only on UDP with TLS-based tunnels using AES-GCM or ChaCha20-Poly1305, is incompatible with compression (which you should not be using anyway), and is a per-tunnel checkbox that is off by default.

Two more habits worth keeping: leave the WAN rule’s port at 1194 rather than playing port-roulette, since obscurity buys nothing against a scanner, and patch the firewall when OpenVPN advisories land. A VPN daemon is by definition an internet-exposed service; a news aggregator like techsentinel.news is a low-effort way to catch VPN and edge-device disclosures the day they drop.

Things to test before you call it done

Test from a genuinely external network (phone hotspot, not your own LAN, because hairpin NAT will lie to you):

• Import the exported config, connect, and confirm the client appears under Status > OpenVPN with a tunnel address.
• ping 10.3.201.1 (your tunnel gateway) proves the tunnel itself.
• ping 192.168.20.10 (a real LAN host) proves routing and the OpenVPN firewall rule.
• dig @192.168.20.1 nas.home.arpa proves pushed DNS actually arrived.
• If the connection never establishes, capture on WAN with Diagnostics > Packet Capture filtered to UDP 1194. Packets arriving with no reply means a firewall rule problem; no packets at all means an upstream NAT or CGNAT problem. Wireshark has dissected OpenVPN natively since 1.10.0 (display filter openvpn) if you pull the capture apart offline.
• For full tunnel, verify a public IP-check site reports your home WAN address, not the client’s local egress.

If all six pass, the server is done. The remaining work is discipline: one cert per device, revoke on loss, and tighten that OpenVPN-tab rule from any/any to exactly what remote users need. If you later find OpenVPN’s throughput limiting on low-power hardware, the WireGuard setup guide is the next thing to read.

Related across the network

• Zero Trust Access and Tunnels Instead of VPN Ingress — cloudflarezerotrust.org
• Cloudflare Tunnel Setup: Your First Tunnel Step by Step — cloudflarezerotrust.org