WireGuard has been removed from the base system in releases after pfSense Plus 21.02-p1 and pfSense CE 2.5.0, when it was removed from FreeBSD.
If upgrading from a version that has WireGuard active, the upgrade will abort until all WireGuard tunnels are removed. For more details, see the Release Notes
WireGuard is available as an experimental add-on package on pfSense Plus 21.05, pfSense CE 2.5.2, and later versions. The settings for the WireGuard add-on package are not compatible with the older base system configuration.
The WireGuard package is still under active development. Follow the development progress on the developer’s YouTube channel
WireGuard can work with both static and dynamic routing, depending on the environment.
WireGuard routing can be handled manually to reach remote LAN segments in addition to the tunnel network itself. To setup static routes:
Before assigning the interface, make sure default gateway for the firewall is
not set to Automatic or the firewall may end up using the
interface as the default gateway, which is unlikely to be the desired
WireGuard can work with dynamic routing, but there are some special considerations to take into account.
This has only been tested with FRR.
The primary requirement to use dynamic routing with WireGuard is that there can only be one peer per WireGuard tunnel. When more than one peer is connected to a single WireGuard tunnel, WireGuard requires Allowed IPs to decide where to send specific networks. In that case, having to define these networks manually negates the purpose of dynamic routing. Using a single peer allows WireGuard to send any traffic it needs across the interface, including arbitrary networks.
BGP works without any special configuration. Define the neighbor using the WireGuard interface address of the peer.
OSPF works, but needs special settings because it cannot utilize multicast traffic to find neighbors.
In the OSPF settings of FRR:
Set the WireGuard interface Network Type to Non-Broadcast mode
Add a manual entry on the Neighbors tab using the WireGuard interface address of the peer
Other routing protocols have not been tested. If a routing protocol relies on broadcast or multicast traffic, it is unlikely to work.
When allowing inbound connections from arbitrary remote networks, use rules only on assigned WireGuard interface tabs only to ensure proper return routing.
Assigned WireGuard interfaces get their own individual rule tabs and will only
match traffic on that specific tunnel interface. Rules on assigned WireGuard
interface tabs also get
reply-to which ensures that traffic entering a
specific assigned WireGuard interface exits back out the same interface. Without
that, return traffic will follow the default gateway.