pfSense WireGuard: 2026 site-to-site + multi-branch mesh guide

Does pfSense support WireGuard?

Yes, on current releases — but the path is different on pfSense Plus versus pfSense Community Edition.

On pfSense Plus 22.05 and later, WireGuard is in the base system as a FreeBSD kernel module. No package install, no opt-in: navigate to VPN → WireGuard immediately after install. This is Netgate's commercial release — free for personal use on Netgate hardware, $129/year for self-install elsewhere.

On pfSense Community Edition (CE) 2.5.2 through 2.7.x, WireGuard is available as the pfSense-pkg-WireGuard package from System → Package Manager → Available Packages. The current package uses the wireguard-go userspace implementation. It works correctly; it's slightly slower than the kernel module that pfSense Plus uses.

Older pfSense CE versions (2.4 and earlier) do not support WireGuard. If your appliance is on an unsupported release, upgrading is the prerequisite to anything in this guide.

pfSense Plus vs CE: what changes for WireGuard

The differences that actually matter when you're configuring or operating WireGuard on pfSense:

The configuration UI is identical between CE and Plus — the same menus, the same fields, the same Status page. The under-the-hood implementation differs in performance but not in operator workflow. If you're learning on pfSense CE in a lab and deploying to pfSense Plus in production, your knowledge transfers cleanly.

Step-by-step setup

The sequence below produces a working WireGuard tunnel. The site-to-site case in the next section is the same sequence performed symmetrically on both appliances.

1. Install the package (pfSense CE only). System → Package Manager → Available Packages → search "WireGuard" → install. On pfSense Plus 22.05+ skip this step.
2. VPN → WireGuard → Tunnels → +. Click the dice icon to generate a keypair. Set Listen Port to 51820. Set Interface Addresses to 10.100.0.2/32 (site-to-site) or 10.100.0.1/24 (road-warrior server).
3. Peers → +. Bind the peer to the tunnel you created. Paste the remote public key. Set Allowed IPs to the remote tunnel /32 plus any LAN subnet behind it. Endpoint and Endpoint Port if the remote has a stable public address.
4. Settings → tick Enable WireGuard → Save → Apply.
5. Firewall → Rules → WAN → Add. Allow inbound UDP, port 51820, source: any, destination: WAN address. This is the rule everyone forgets; without it the handshake never completes.
6. Interfaces → Assignments. The tun_wg0 interface should now be available. Add it, name it (e.g. WG_VPN), enable it. No IP assignment needed; the tunnel address from step 2 covers it.
7. Firewall → Rules → WG_VPN. Add allow rules — source: WG_VPN net, destination: LAN net (or specific hosts). Without rules on this new interface, the firewall defaults to deny-all.
8. VPN → WireGuard → Status. Once the remote side is also configured, the peer row should show a recent handshake timestamp and the byte counters should increment.

Site-to-site between two appliances

For two branches, run the setup symmetrically. Conventional addressing:

If one branch has a dynamic public IP (common in India), the side with the stable IP becomes the listener and the side with the dynamic IP omits the Endpoint field on its peer record — it dials out, the listener accepts. Persistent Keepalive on the dynamic side keeps the NAT entry alive.

WireGuard vs OpenVPN on pfSense — real numbers

The most common upgrade path for pfSense operators is "we have OpenVPN site-to-site; is WireGuard worth switching to?" The throughput case is unambiguous:

Beyond raw throughput, WireGuard's connection state is dramatically simpler: a peer is identified by its public key, the kernel keeps one table entry per peer, and there is no TLS-handshake cost per reconnect. OpenVPN tunnels that flap (cellular failover, ISP outages) re-establish in 200–800 ms; WireGuard tunnels re-establish on the first packet, typically under 50 ms.

The 2021 incident and what changed

If you're researching pfSense WireGuard you'll likely encounter forum threads referencing the March 2021 incident. The short version: Netgate shipped a kernel-level WireGuard implementation into pfSense CE 2.5.0 that hadn't been upstream-reviewed. It crashed under load. After community pushback (and a public response from WireGuard's author Jason Donenfeld), Netgate withdrew the kernel module from pfSense CE 2.5.2 and replaced it with the userspace wireguard-go via a separate package. The kernel module returned, properly engineered, in pfSense Plus 22.05.

The current state in 2026: pfSense Plus WireGuard is in good shape; pfSense CE WireGuard via wireguard-go is also in good shape but slower. Both are stable for production use. The cautious tone in Netgate documentation reflects the 2021 history, not current technical concerns. If your evaluation has been delayed because of that incident, the all-clear has been in effect for several years.

Two appliances becomes ten branches

pfSense WireGuard handles two-site site-to-site cleanly. The shape changes when the operator needs more than that:

• Five sites in full mesh = ten peer relationships. Each peer relationship is configured on both sides, so twenty edits. Add a sixth site, that's ten new edits across all six firewalls. Ten sites = forty-five relationships, ninety edits. Quadratic growth.
• Per-peer policy. WireGuard's Allowed IPs is route+encryption combined. Site-by-site firewall rules govern what each tunnel can reach. With ten branches, that's ten firewalls' worth of policy to keep in sync.
• Key rotation. Best-practice WireGuard hygiene rotates keys annually. With ten branches in a mesh, rotating one key means updating the peer record on every other firewall — manually, through the web UI, on each appliance.
• Branches behind CGNAT. Two pfSense appliances both behind CGNAT cannot directly handshake — they need an intermediary listener. pfSense doesn't ship a relay layer; you'd run one in a cloud VM, with the operational cost of "what happens when the cloud VM is down."
• Cross-site visibility. VPN → WireGuard → Status shows one appliance's view. Ten appliances means ten browser tabs to confirm "everything's green."

When you outgrow native WireGuard

MeshWG layers above pfSense's native WireGuard, not instead of it. The kernel module on Plus or the wireguard-go package on CE keeps doing what it does; MeshWG handles the orchestration:

• Generated configuration. For each pfSense appliance you add, MeshWG produces a paste-ready tunnel + peer set. New branch joins, every existing appliance gets its Allowed IPs regenerated automatically.
• Central policy. Allow / deny between any two devices is configured once. The policy is enforced before traffic reaches the destination — no per-appliance firewall edits required.
• Built-in relay for double-NAT. Two pfSense appliances both behind CGNAT use a MeshWG relay automatically; no extra configuration on your side.
• Unified dashboard. One view of every appliance's last handshake, transferred bytes, and live state.
• Honest pricing. Free for the first two appliances forever; ₹349/appliance/month annual or ₹499/appliance/month monthly, in INR via Razorpay. No per-tunnel surcharge.

The pfSense + MeshWG combination is the typical landing point for operators who started with two Netgate boxes and grew to a dozen branches. You keep the firewall you trust; you add the orchestration layer that scales.

Frequently asked questions