3 minute read

A long time ago I set up a VPN server on my pfSense network gateway. Then I switched away from pfSense, and then Covid happened, and during a number of years I simply didn’t have a pressing need to access my home network when not there.

Now I’m planning for a trip through a large part of Europe, and while I’m generally pretty happy with the stability of my environment at home, I realize that if something happened so my mail server went down I’d hate not having the ability to reboot its VM or troubleshoot the issue: Several days without email may be a bad thing.

Back in the pfSense days, the current technology was to run IKEv2 over IPSEC, and that was good enough, but since then, we’ve had some development, and WireGuard is the “new” hot thing.

To be honest I basically just followed the OpnSense documentation for a Wireguard Road Warrior setup, but I had issues getting the client to work properly on my Fedora laptop: I insisted on trying to set it up via the GUI, and I couldn’t figure out what I was doing wrong.

Fedora setup

The WireGuard VPN configuration interface is built-in to the network settings in Gnome, but it doesn’t work unless you install the WireGuard tools:

sudo dnf install wireguard-tools

When setting up the VPN interface, make sure Make available to other users is checked in the Details tab.

Use the WireGuard tools to generate your private and public keys for the laptop:

wg genkey | tee privatekey | wg pubkey > publickey

Then use your private key in the laptop’s WireGuard settings, and use the public key when defining the peer configuration in OpnSense.

In Fedora, in the WireGuard configuration tab, ensure Add peer routesis checked.

As the peer in the laptop configuration, add the endpoint configured in OpnSense, and the public key from the OpnSense instance configuration.

For the Allowed IP addresses in the laptop’s Peers configuration, use, ::/0 to ensure all Internet traffic is routed through the VPN when connected.

WireGuard does not allow assigning client addresses over DHCP. Instead define specific “allowed IPs” for each client in the OpnSense Peers configuration, and then use these IP addresses for your IPv4 and IPv6 configuration tabs on the Fedora laptop.

As a final note for this part, I didn’t manage to get OpnSense to tell my clients about the configured DNS addresses, so I added those manually to the IPv4 and IPv6 tabs in Fedora.

If you don’t want to mess with the GUI, it’s perfectly alright to just write your client configuration into a file and import it using the nmcli command. I called my config file /etc/wireguard/wg0.conf, and it looks something like this:

PrivateKey = <redacted>
Address =, 2001::11/128
DNS =, 2001::1

PublicKey = <redacted>
AllowedIPs =, ::/0
Endpoint = mydomain.com:54321
PersistentKeepalive = 30

Importing the configuration into the Netwok Manager is done with this command:

nmcli con import type wireguard file /etc/wireguard/wg0.conf

macOS setup

On the Mac, I installed the WireGuard app from the App Store as recommended on their installation instructions page. In my case I created an empty tunnel (which also generates a new key pair) and hand-hacked the settings as per the example above, just using new values for the keys and the client IP address, but the WireGuard app also supports importing a config file directly: The end result is the same.


It took me some time to understand how WireGuard works. To be honest it would’ve been easier if I had started out with a configuration file immediately rather than trying to do it the fancy way through the GUI, but then again I wanted to see that workflow too. I guess the Fedora dev team could help a beginner out by offering a more streamlined workflow: it would be nice if the correct checkboxes were pre-filled and if the GUI provided more explanations when hovering over the various fields, but overall: It definitely is possible to configure WireGuard on Fedora without ever touching the Terminal.

Verifying that the tunnel worked was simply a matter of pairing with my cell phone and turning the tunnel on, and then verifying that my IP address was my home address, and that I could both connect to various privately accessible interfaces in my home network and to regular public services I utilize.