A working pfSense OpenVPN setup starts with one choice, the server mode: Remote Access (SSL/TLS + User Auth) for phones and laptops, Peer to Peer (SSL/TLS) to join two firewalls, and a client instance on an assigned interface to send one VLAN out through a VPN provider. All three should run UDP, AEAD ciphers, a TLS key and a non-overlapping tunnel network.
Everything here works on CE and Plus except Data Channel Offload (DCO), which is Plus-only. For a click-by-click wizard run, see the OpenVPN server wizard walkthrough.
Which OpenVPN mode should you pick on pfSense?
Pick Remote Access (SSL/TLS + User Auth) for road-warrior clients and Peer to Peer (SSL/TLS) for firewall-to-firewall links. Netgate’s server mode documentation calls certificate-plus-password the most secure option, and it is what the wizard builds. Never create a Shared Key tunnel: OpenVPN has deprecated it.
| Server mode | Use it for | Tunnel network | Verdict |
|---|---|---|---|
| Remote Access (SSL/TLS + User Auth) | Laptops, phones | /24 | Default |
| Remote Access (SSL/TLS) | Headless devices | /24 | Fine; revoke per cert |
| Remote Access (User Auth) | One shared profile | /24 | Weakest option |
| Peer to Peer (SSL/TLS) | Site-to-site | /24 hub, /30 single peer | Site-to-site default |
| Peer to Peer (Shared Key) | Nothing new | /30 | Deprecated |
The OpenVPN overview states that “Shared key mode will be removed from future versions of OpenVPN.” An SSL/TLS peer-to-peer instance on a /30 does the same job. Leave Device Mode on tun; tap drags LAN broadcast traffic across the tunnel.
Which settings matter on every instance?
Five fields decide whether a tunnel is hardened and routable: protocol, TLS key, data ciphers, tunnel network and compression. Get those right and nearly everything else can stay at the GUI default, whatever the mode.
- Protocol: UDP, port 1194. The OpenVPN 2.6 reference manual is direct: “For the best protection against DoS attacks in server mode, use —proto udp and either —tls-auth or —tls-crypt.”
- TLS key. Keep Use a TLS Key checked. TLS Authentication signs control-channel packets, which the manual calls an “HMAC firewall”: unsigned packets are dropped without a reply. TLS Encryption and Authentication also encrypts the control channel, hiding the certificate.
- Data ciphers. Netgate’s cryptographic settings default to AES-256-GCM, AES-128-GCM and CHACHA20-POLY1305 with negotiation enabled. Leave it that way, keep the SHA256 auth digest, and use a 2048-bit DH group from the pre-generated RFC 7919 set (Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS).
- Tunnel network. It “must be an unused, non-overlapping subnet,” per the tunnel settings docs. A /30 means one peer and no pushed routes; anything larger enables client/server mode with pushed Local Network routes. Avoid
192.168.0.0/24and192.168.1.0/24, which the hotel router is probably using. Set Topology to Subnet. - Compression. Choose “Refuse any non-stub compression (Most secure).” Encrypted data does not compress, and compression breaks DCO.
Leave Inter-Client Communication and Duplicate Connections unchecked; one certificate per device makes a lost phone one revocation.
How do you set up OpenVPN remote access?
Run VPN > OpenVPN > Wizards with Local User Access to get a Remote Access (SSL/TLS + User Auth) server on WAN, UDP 1194. Then create users with certificates, install the Client Export package, and replace the wizard’s any/any OpenVPN rule with scoped rules.
Netgate’s remote access example uses a 3650-day CA, a 200-day server certificate, tunnel 10.3.201.0/24, local network 10.3.0.0/24 and DNS server 10.3.0.5. Add users under System > User Manager with create a user certificate checked. In Client Export, set Host Name Resolution to your Dynamic DNS hostname if the WAN address changes. For full tunnel, check Redirect IPv4 Gateway; automatic outbound NAT already covers the tunnel network, manual NAT needs a rule.
Firewall rules, in apply order:
| # | Tab | Proto | Source | Destination | Port | Action |
|---|---|---|---|---|---|---|
| 1 | WAN | UDP | any | WAN address | 1194 | Pass |
| 2 | OpenVPN | ICMP | 10.3.201.0/24 | This Firewall (self) | echo | Pass |
| 3 | OpenVPN | TCP/UDP | 10.3.201.0/24 | 10.3.0.5 | 53 | Pass |
| 4 | OpenVPN | TCP | 10.3.201.0/24 | 10.3.0.20 (NAS) | 443, 445 | Pass |
| 5 | OpenVPN | any | 10.3.201.0/24 | RFC1918 alias | any | Block |
| 6 | OpenVPN | any | 10.3.201.0/24 | This Firewall (self) | any | Block |
| 7 | OpenVPN | any | 10.3.201.0/24 | any | any | Pass (full tunnel only) |
The wizard’s any/any rule shadows rules 2 through 7 until you delete it. An assigned ovpns interface tab is evaluated after the OpenVPN tab, per Netgate’s interface assignment docs, so a broad OpenVPN-tab rule shadows it too. Same deny-by-default logic as an inter-VLAN rule set.
How do you set up site-to-site OpenVPN between two pfSense firewalls?
Run a Peer to Peer (SSL/TLS) server at the site with the static IP and best upstream, a client instance at each branch, and one Client Specific Override per client. The override’s IPv4 Remote Network field writes the iroute; without it, the tunnel comes up and LAN-to-LAN traffic goes nowhere.
Netgate’s site-to-site example uses this layout:
Site A (server) WAN 198.51.100.3 LAN 10.3.0.0/24
Site B (client) WAN 203.0.113.5 LAN 10.5.0.0/24
Site C (client) WAN 198.51.100.7 LAN 10.7.0.0/24
Tunnel network 10.3.101.0/24, UDP 1194
On Site A:
- Create CA
S2SCA, server certificateserverAwith Certificate Type Server Certificate (easy to miss), and user certificatesclientBandclientC. - Create the server: Peer to Peer (SSL/TLS),
tun, UDP, WAN. Local Network(s)10.3.0.0/24, 10.5.0.0/24, 10.7.0.0/24; Remote Network(s)10.5.0.0/24, 10.7.0.0/24; Inactive0. If remote access already owns 1194, use 1195. - Add overrides: Common Name
clientBgets10.5.0.0/24,clientCgets10.7.0.0/24. - Copy the TLS key; export the CA certificate plus each client certificate and key. Never export the CA key or server key.
- WAN rule: UDP 1194 to WAN address, source an alias of the branch WAN IPs.
On each branch, import the CA and client certificate, then create a client instance pointing at 198.51.100.3:1194 with automatic TLS key generation unchecked and the server’s key pasted in. Routes arrive from the server.
How do you run pfSense as an OpenVPN client to a VPN provider?
Create a client instance from the provider’s CA, TLS key and credentials, assign its ovpnc interface, NAT one subnet out of it, and policy-route that subnet with a firewall rule. Everything else keeps using WAN.
- System > Routing: set the default gateway to your WAN gateway explicitly, not Automatic, as the assignment docs advise.
- VPN > OpenVPN > Clients: enter the provider’s settings and check Don’t pull routes, so the client “ignores routes pushed from the server,” including a default-gateway redirect.
- Interfaces > Assignments: add
ovpnc1, enable it, then re-save the client instance to restart it. - Firewall > NAT > Outbound: switch to Hybrid and add a rule on the VPN interface for source
192.168.40.0/24, translation Interface Address. - Firewall > Rules on VLAN 40: pass
192.168.40.0/24to any with the VPN gateway set, a gateway-less block rule directly below, and local-destination rules (DNS, printers) above.
Then check Do not create rules when gateway is down under System > Advanced > Miscellaneous. By default, per the Miscellaneous settings docs, a down gateway “is omitted from the rule” and traffic leaks out WAN; with the box checked, the block rule is your kill switch. The same gateway logic drives multi-WAN failover.
Should you enable OpenVPN DCO?
Only on pfSense Plus 22.05 or later, and only for tunnels inside its limits; CE does not have it. Netgate’s DCO documentation restricts it to UDP, TLS-based modes and AES-256-GCM, AES-128-GCM or ChaCha20-Poly1305, with no compression. It is a per-instance checkbox the wizard does not offer.
The routing limit bites hardest: DCO “is not yet able to utilize internal routing in OpenVPN (iroute),” so the multi-site hub above breaks with it, as do /30 peer-to-peer tunnels. Remote access and one-client-per-server site-to-site work. Weigh pfSense Plus vs CE if edition decides it, or OpenVPN DCO against WireGuard if throughput does.
Why does a pfSense OpenVPN tunnel connect but pass no traffic?
Usually one of three faults: no pass rule on the OpenVPN tab, a missing route or iroute, or an overlapping subnet. Netgate’s troubleshooting guide starts at Status > OpenVPN, then the OpenVPN and Firewall tabs under Status > System Logs.
- No connection log entries at all: wrong client config, or WAN is blocking UDP 1194. If an ISP router sits in front, see the port forwarding troubleshooting guide.
- Routes not pushed: the tunnel network is a /30. Check Diagnostics > Routes.
- Some LAN hosts answer, others do not: those hosts lack a gateway pointing at pfSense, carry a wrong mask, or run a host firewall.
- Two clients share an address: they share a certificate.
Test from an external network such as a phone hotspot:
ping -c 4 10.3.201.1 # tunnel gateway (rule 2)
dig @10.3.0.5 nas.home.arpa # pushed DNS (rule 3)
mtr -rwc 20 -T -P 443 10.3.0.20 # TCP path to the NAS (rule 4)
iperf3 -c 10.3.0.20 -t 30 -R # throughput; temporary TCP 5201 rule
Delete the temporary 5201 rule once the numbers are recorded. If nothing connects, capture UDP 1194 on WAN under Diagnostics > Packet Capture: packets without replies mean a rule problem; no packets mean upstream NAT or CGNAT.
FAQ
what port does openvpn use on pfsense
OpenVPN on pfSense uses UDP port 1194 by default, which the wizard fills in and opens with a WAN pass rule. Each additional server instance on the same interface needs its own port, such as UDP 1195 for a site-to-site tunnel. Moving to an unusual port adds no real security; the TLS key does that work.
is openvpn free on pfsense ce
Yes. OpenVPN is built into both pfSense CE and pfSense Plus at no extra cost, including the wizard, the certificate manager and the Client Export package. The notable Plus-only OpenVPN feature is Data Channel Offload, which moves data-channel processing into the kernel and requires pfSense Plus 22.05 or later.
do i need a static ip for openvpn on pfsense
No. A dynamic WAN address works if you configure Dynamic DNS on pfSense first and select that hostname under Host Name Resolution in the Client Export package, so every exported profile points at the name rather than the address. What does not work is CGNAT, because inbound UDP 1194 never reaches your WAN.
should i use tcp or udp for openvpn on pfsense
Use UDP. It avoids stacking TCP retransmission inside another TCP connection, the OpenVPN manual recommends it for DoS resistance, and DCO supports nothing else. Add a separate TCP server instance only if some users sit behind networks that block outbound UDP, and treat that instance as a fallback rather than the default.
Related across the network
- OPNsense WireGuard Setup Problems: Handshake, NAT, MTU — opnsenserouter.com
- OPNsense WireGuard Site to Site Tunnel: Routing Setup — opnsenserouter.com