pfSense VPN: WireGuard, OpenVPN and IPsec
A VPN on pfSense serves two different jobs that are often confused: remote users reaching an office network, and two fixed sites behaving as one network. Remote access cares about easy client setup and quick reconnection on changing networks. Site-to-site cares about stability, predictable addressing, and surviving router reboots without human help. Choosing the protocol before defining the job is how networks end up with three half-configured tunnels and no clear owner for any of them.
Choosing between WireGuard, OpenVPN, and IPsec
WireGuard is lean, modern, and fast, with a small cryptographic surface and stateless design that recovers gracefully from address changes. It suits most new remote-access and point-to-point deployments, though it assigns addresses statically per peer, which means planning keys and address pairs rather than relying on a dynamic pool.
OpenVPN remains the flexible workhorse: it runs over UDP or TCP, passes restrictive networks more easily, supports username and certificate authentication, and issues addresses from a pool. When users sit behind hostile hotel networks or you need server-side policy per user group, OpenVPN is often the pragmatic choice despite its higher overhead. IPsec, the oldest of the three, is the traditional answer for site-to-site links, especially to other vendors' equipment, and its policy-based or VTI-based tunnels interoperate widely.
None of these protocols is inherently "the secure one." All three are strong when configured with modern parameters and weak when configured carelessly, so the decision should follow your authentication model, network conditions, and interoperability needs.
Plan addressing before keys
VPN addressing collisions cause the most frustrating failures. The tunnel network, the pool handed to remote clients, and the subnets behind every peer must all be unique and must not overlap with anything reachable over another interface. Draw the topology: which firewall holds which subnet, which tunnel carries which routes, and what each client should see. A half hour of diagramming prevents the classic mystery where a laptop at a coffee shop cannot reach one department because its home LAN uses the same range.
For site-to-site tunnels, document the phase parameters or peer configuration on both ends, including keepalive settings, allowed subnets, and routing expectations. Keep symmetric notes; most support threads about broken tunnels end with the two sides disagreeing about what was agreed.
Authentication deserves the most attention
Weak authentication turns a strong tunnel into an open door. Prefer certificate-based authentication for site-to-site links, with a dedicated certificate authority and expiring certificates tracked somewhere visible. For remote users, combine certificates or strong secrets with short session policies, and avoid a single shared credential that outlives every employee who ever used it. Where the platform supports it, require multi-factor authentication for remote access, and treat VPN accounts with the same review discipline as administrator accounts.
Key management is operational, not a setup step. When someone leaves the team or a laptop is lost, the corresponding peer, certificate, or user must be revoked the same day, and the tunnel configuration must reflect that change on both ends.
Write rules for tunnel interfaces like any other network
Traffic arriving through a VPN is filtered just like traffic arriving on the LAN, and pfSense exposes separate rule sets for VPN interfaces and for the firewall rules governing what clients may reach. Grant narrow access: an administrator tunnel reaches management hosts, a general staff tunnel reaches office servers, a site-to-site tunnel reaches only the documented subnets. Allow DNS deliberately, because clients that keep their home resolver will resolve internal names incorrectly and quietly misbehave.
Do not forget the return path. Devices on the office LAN may need routes or rules to reply through the gateway rather than the VPN client's original address, and asymmetric flows can appear with multiple WAN links. Test from a real client on a real external network, not only from a device sitting beside the firewall.
Monitor, test, and rehearse recovery
Watch tunnel status, handshake recency, and interface counters, and alert when a site-to-site peer goes silent. Reconnection behavior differs between protocols and networks, so measure how quickly each tunnel recovers after a WAN blip and after a firewall reboot. Keep an export of the VPN configuration with the rest of the system backups, and rehearse a restore on spare hardware at least once a year.
If you are still assembling the gateway itself, review the platform overview before you download pfSense, because VPN features and interface options evolve between releases and official documentation is the authority for the version you install.
Document the whole design
Finish with a one-page record: protocol choices and why, address plan, authentication model, revocation procedure, monitoring points, and the last test date. VPNs are the part of the network people trust with remote access to everything, so the documentation that keeps them explainable is not overhead. It is the difference between a gateway you can operate and one you merely hope is still configured the way someone remembered.