Notes about working with wireguard

A few of us have had discussions about wireguard and whether or not it fits into IPFire. Unfortunately, I don’t have the time to be able to add wireguard as a package but hopefully my experience running wireguard behind a firewall will help.

Wireguard is simultaneously incredibly simple and confusing. Here are some key points that I think may help understand the VPN.

The connection between wg0 interfaces is the analog to a piece of ethernet cable between two nics. They both had their own IP address in the same subnet. The difference is that each nic it’s own private key associated with the interface.

Sample minimum definition for a wg0 interface

[ Interface]
Address =
PrivateKey = yea right…
ListenPort = 51820

A link between two wg0 nodes is simple to set up. In the configuration file supplied with most wireguard packages there is a section labeled [Peer]. In that section you want to add parameters from the other side of the VPN. See below
The AllowedIPs value is the IP address of wg0 on the other side as specified in the [Interface]… Address section. You’ll notice that the “Address” specification is a /24 but the “AllowedIPs” is a /32. This is not discussed in the documentation but I suspect it is associating the public key with a single IP address to make key based routing work.

PublicKey = from other side
# allow the peer address
AllowedIPs =

You’re allowed multiple “AllowedIPs” to define address ranges available on the other side of the VPN.

# allow the remote net
AllowedIPs =

there is an ability to specify the endpoint you are connecting to. This is usually used for the road warrior client so can easily find the other side. Not sure if there’s any advantage to having on both sides except in the scenario described below.

# endpoint not needed if server
#Endpoint =

This is an interesting option. It makes wireguard chatty. It sends out keep alive messages to the other side to make sure somebody is there.

PersistentKeepalive = 10

This is useful in two circumstances I can think of. First is a cellular environment where you need to keep tickling the LTE connection to keep it alive. Second is when you can’t modify the firewall for a net to net connection.

It’s an old UDP trick which works great with wireguard. Most firewalls can’t do connection tracking on UDP so if two sides “talk” at each other by UDP, the firewall usually leaves the connection open briefly for return UDP packets. If it does, then you can sneak wireguard packets through the firewall.

I have demonstrated this concept with a Cisco firewall and IPFire. It may not work all the time but it’s surprisingly useful.

Once the basic VPN is up and running (wg show is your friend), you should be at the ping from one wg interface to the other but you won’t be able to ping anything in the remote lan from the wireguard gateway. TCP dump will show you why.

However, you can ping from lan to lan if you add a route on each side to send packets for the far lan through the wireguard gateway.

There is another trick that I haven’t fully sussed out yet you may be a will to use masquerading on the wireguard gateway so that a packet from the far side looks like it’s coming from the gateway. The only advantage to this is that you don’t have to put route information everywhere. The big downside is you don’t know where the packets coming from for real.

Anyway that’s a quick brain dump. Next step is to try and move the wireguard gateway into a virtual machine running on IPFire. However if somebody wants to build an IPFire package, I’ll be glad to help.