wireguard: private network, roaming

This diagram shows my wireguard setup. Wireguard creates a virtual private network (VPN) that routes just traffic for the 10.1.1.0/24 subnet (IPs 10.1.1.0 to 10.1.1.255).

VPN is a misunderstood word. A VPN is a virtual private network, but it’s commonly used to refer to technologies that provide privacy and security on a public wifi, or allows you to hide your traffic from your ISP.

How it works

A VPN is a virtual private network. Here I use wireguard as a VPN with a new network interface added to each device (wg0). The wg0 network interface provides access to the 10.1.1.0/24 range if IPs. This virtual network is private, because only authorised members can access it.

If this were a VPN in the traditional (privacy) sense, then the wg0 network interface would provide access to 0.0.0.0/0 interface (or; everything). Currently, it only routes request for IPs in the 10.1.1.0/24 range.

The new interface wg0 will only be used for resources on its network.

Network topology

I’ve written before about network topologies, and I will steal some of the same diagrams here.

I’ve previously described a star network. This private network using wireguard makes use of the same topology.

At the center of the “star” is a VPS (a cloud server). This allows for a single public IP for any of the wireguard peers to communicate with. Using a single server at the center of the network is less reliable, as all peers lose connection if the server goes down, but provides lots of benefits;

1. A single place to register new peers, a mesh network would require wireguard updates on all the machines in the network.
2. A public IP for roaming peers to communicate with, this allows access to the other machines on the network from anywhere.

NAT

If any two peers want to communicate with each other, the network packets flow through the cloud server. To allow this to function, it needs two params;

Allow packets to be forwarded to another machine on the network if that machine matches the packets destination IP.

1
2

# /etc/sysctl.conf
net.ipv4.ip_forward = 1

Add a nat masquerade. As the vps cloud server is now operating as a “router” of sorts, it needs to enable NAT. NAT, or network address translation, allows the cloud server “router” to pass on requests as if they are from the cloud server, and not from one of the peers. Without this setting, if the desktop machine requested a site hosted on the raspberry pi, the pi would try and respond directly to the desktop. This would be unsoliccited traffic, and would be rejected by the desktop.

Enabling NAT masquerading on the cloud router, allows the server to hide the requested from the server handling the request, and ensures that traffic is routed correctly.

1
2
3
4

[Interface]
// trimmed...
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o en0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o en0 -j MASQUERADE

(change en0 to your internet connected interface)

What I use it for

I have a number of internal sites, that have security / login credentials on them, but the added layer of security provided by wireguard is a big reassurance. I know the default level of protection of all of my apps is wireguard, and if they implement their own login auth after that, so be it.

I can also skip auth on my internal sites, as I know that only trusted peers will be able to access them (via wireguard).