Securely accessing colo private network – from the office!

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?

??
Before you go on… this blog is going to walk you through setting up a unique site-to-site where the other side has a more complicated setup than your home network. This is not a “remote” access VPN to secure your internet traffic, either. However, with some modification, this can be used as a site-to-site VPN. I’ll point out the change to make for a true site-to-site.

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

??
If your goal is to have a site-to-site, you’re done (don’t forget to replicate what you did on the opposite side (and swap IPs and keys where appropriate) and can skip this section! If you’re just curious or have a situation where you might need this, continue on.

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.

Leave a Comment

Your email address will not be published. Required fields are marked *