If you don’t already know, I run a web hosting business. In the fall last year, I moved into a full colo rack. In the colo, I run a mix of my own stuff plus my business (after all, I have the space, I might as well use it!). But one thing kept cropping up – how do I securely access equipment from my (home) office when customers need help and the front door is locked up and they can’t remember what fake rock they put their key under?
Wireguard to the rescue
I love Wireguard. No, really. I do. It’s my favorite VPN utility. Mostly because it’s simple and it just works. I can’t tell you how many times I’ve fought IPSec tunnels and they take a toll on the firewall’s CPU.
At home, I run pfSense and I also run pfSense in my colo space. The firewall I installed in my colo space is really just for this – remote access to the private network. Now, back in March I said that you don’t want to use Wireguard on pfSense. Granted, a lot has changed since then. First, Wireguard was completely ripped out of the core OS. It’s now offered as a separate package. I give this package my blessing.
Here’s what we’re going to be building:
Essentially what we’re building is a site-to-site VPN. Traffic from my office goes across the Wireguard VPN and then to the private side of the data center.
Creating the tunnel
On the pfSense firewall in the data center, go to VPN > Wireguard. Create a new tunnel.
Give it a good description. Set your listen port or use the default. Generate your keys. Copy your public key to a temporary location (like a notepad). Set your interface addresses. One of these will be the tunnel address. This address should NOT be in use anywhere else! Assign this a /32. The second address should be the address at your remote site with the appropriate subnet mask. Save your tunnel.
Add your peer(s)
Wireguard works by having peers exchanging cryptographic information. This is what makes it secure. Go to VPN > Wireguard > Tunnels > find the tunnel you created and add a peer.
Fill in the options –
On the “server” side:
Description: Home office
Dynamic endpoint: Checked (this is useful if you have a dynamic IP)
Keep alive: 10
Public key: Paste your PUBLIC KEY from your other firewall
Allowed IPs: The Wireguard Tunnel IP of the other side, and the network of the other side.
On your home office side:
Description: Data center
Endpoint: IP or hostname of data center firewall
Port: the port that you set
Keep alive: 10
Public key: Paste your PUBLIC KEY from your other firewall
Allowed IPs: The Wireguard Tunnel IP of the other side, and the network of the other side.
Assign the interface
Go to Interfaces > Assignments and assign the tun_wg0 interface. Go to Interfaces > your WG interface (probably OPT1). Set the IP configuration as static. Add your IPv4 for the tunnel. For example, 10.255.255.1/30. Click save.
Firewall rules
You’ll need to create a rule to allow traffic to Wireguard. This should be where you have a static IP (preferably). This side will be the “server”. Go to Firewall > Rules > WAN. Create a new rule with the following:
Action: Pass
Protocol: UDP
Source: Any (unless you have specific IPs that should be connecting – but if you have a dynamic IP, leave as any)
Destination: WAN address
Destination Port Range: 51820 (or the port you selected if you didn’t use the default)
Description: Pass 51820/udp Wireguard
Click save and apply.
Go to Firewall > Rules > OPT1 (or whatever you named your WG interface). Create a new rule:
Action: Pass
Protocol: Any
Source: Any
Destination: Any
Description: Pass VPN traffic from peers
Click save and apply.
Routing
In order to send Wireguard traffic out, we need a gateway for it. Go to System > Routing > Gateways. Click Add.
Interface: tun_wg0
Address family: IPv4
Name: WG_SITE
Gateway: 10.255.255.2 (this is the IP on the OTHER side)
Now we need to add a route so traffic knows how to pass. Go to System > Routing > Static Routes. Click Add.
Destination network: 10.200.0.0/24 (the private network on the other side)
Gateway: WG_SITE
Click Save and Apply.
NAT
Why you might need NAT: typically you won’t need NAT. However, in my situation, I mentioned that my colo has a private network. The servers all primarily communicate on their public interfaces. These interfaces have the default gateway. The private network lacks a default gateway. This means that the private network can only communicate on the same subnet. Well, that’s a problem. I’m coming from 10.204.x.x so I can’t SSH to a server on 10.90.x.x if it doesn’t have a default gateway. The solution here is NAT. I translate my 10.204.x.x address as the IP address of the firewall in my colo – 10.90.x.x. Now I can SSH to a server because the firewall and server are on the same L2 network.
On your data center side, go to Firewall > NAT > Outbound. Make sure NAT mode is hybrid. Create a new manual rule.
Interface: LAN
Address family: IPv4
Protocol: Any
Source: Network & set the network to your WIREGUARD tunnel network.
Destination: Any
Translation address: Interface address.
Click on save and apply.
