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
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 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
The new interface
wg0 will only be used for resources on its network.
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;
- A single place to register new peers, a mesh network would require wireguard updates on all the machines in the network.
- A public IP for roaming peers to communicate with, this allows access to the other machines on the network from anywhere.
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.
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.
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).