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
One of the main considerations when choosing a WireGuard implementation layout is whether to use one tunnel with many peers, or one tunnel per peer.
Routing to WireGuard Peers¶
WireGuard uses what it calls “Cryptokey Routing” to map traffic inside WireGuard to a specific peer which is then encrypted using the public key for that peer. In practice, this means that when multiple peers are defined on a WireGuard instance, it must have all networks which will be routed to each peer defined on the peer. This can make managing networks and routes cumbersome.
When there is only one peer on a wireguard interface, it can instead assume that
the one peer is the correct destination for all traffic which crosses the
interface (e.g. Allowed IPs set to
::/0). And in that case,
a routing protocol such as BGP or OSPF can manage the operating system routing to
the neighbor instead of static routes.
WireGuard does not have a concept of “Client” and “Server” per se, but depending on the configuration the firewall can behave in a manner similar to a “Client” (initiates locally, remote never initiates) or “server” (never initates, remotes always initiate).
Technically every WireGuard tunnel is a peer to peer connection, but there are three main ways a WireGuard tunnel can be configured depending on whether or not a peer endpoint is known or defined:
Site-to-Site (peer endpoint filled in on both sides)
Remote Access “Server” (endpoint only filled in on remote peers)
Remote Access “Client” (endpoint only filled in locally, not on the “server” peer)
Any of those roles can technically be configured no matter how the peer endpoint settings are defined, but not defining an endpoint on one side or the other limits the capacity in which a peer can operate.
Typically, a tunnel is defined with a known peer IP address or hostname for the endpoint, which could take advantage of Dynamic DNS for dynamic peers. This is the most secure method as it locks the tunnel down to specific known peers, but that is not always practical.
In the case of remote access style setups, the peer endpoint address is typically unknown and can change at any time. In this case, the peer endpoint can be left blank and WireGuard will accept connections from any remote address, validating the key instead.
WireGuard supports roaming automatically, and can detect when a peer has changed IP addresses. WireGuard will recognize that authenticated data is coming from a new address and update itself accordingly.