Setting up a Wireguard connection into Microsoft Azure
Overview
This guide shows you how to setup a WireGuard connection to an Azure VM, using Routing Targets, which allows you to directly connect your Endpoint traffic to your Azure network through the Stacuity Portal, without needing to intall or configure any additional software on your endpoint. We will be demonstrating this using an Ubuntu VM, hosted on Azure, but this configuration can be applied to any VM which is publicly available.
Creating the Azure VM
In the Azure Portal, create a new Ubuntu (or other distro) VM with your desired configuration:
Setup SSH access
Specify your disk configuration:
Specify your network configuration:
Review any other settings, and when you are ready create the Virtual Machine.
Installing WireGuard on the Ubuntu VM
The next step is to install and configure WireGuard on the newly created VM. We will be doing this via SSH. Parts of the installation steps are taken from the official guide: https://www.wireguard.com/install/
In the Azure Portal, find the Public IP address of the Ubuntu VM:
SSH into the VM, and install WireGuard:
First, make sure you have the latest packages installed.
sudo apt update
sudo apt upgrade
Then install WireGuard
sudo apt install wireguard
With WireGuard installed, we can create a WireGuard interface called 'wg0'.
sudo ip link add dev wg0 type wireguard
The next step is to generate a private/public keypair for the server.
wg genkey | tee privatekey | wg pubkey > publickey
This command will generate two files, containing your private and public keys, which we will be using below.
With your WireGuard Server keypair created, we now need to share the WireGuard Server public key with the Stacuity Portal, and we are going to share the Stacuity Portal public key (which we are going to create in the next steps), with the WireGuard Server. Let's head over to the Stacuity Portal...
Create a WireGuard Routing Target in the Stacuity Portal
In the Stacuity Portal, go to 'Configuration' -> 'Routing Targets', and add a new Routing Target. Replace the information below, with the values applicable to your WireGuard server.
When the Routing Target has been created, copy the generated Public Key, which we will use in the WireGuard Server.
Create a WireGuard Server interface configuration file
Create a configuration file called 'stacuity.conf' (you can use any filename you want, just make sure you use it when configurating the wireguard interface below), which we will use to configure the WireGuard interface to accept a peer connection from the Stacuity Portal.
[Interface]
PrivateKey = UN0k5p4wPE17Eqf0kfSRabqeiQ217Az7CzKioizpn3s=
ListenPort = 51820
[Peer]
PublicKey = ptbD6j1B7JWEzA3jlLYF14x88mRgNSmlfdZ0Fc1LpXg=
AllowedIPs = 100.64.0.0/10
The next step is to apply the configuration file to the WireGuard Server wg0 interface.
sudo wg setconf wg0 stacuity.conf
With the configuration applied, it is time to bring the interface up.
sudo ip link set up dev wg0
Configure a route on the WireGuard Server
The WireGuard Server needs a route configured, which sends traffic which match the AllowedIP's, down the wg0 interface. In our case, this is 100.64.0.0/10.
sudo ip route add 100.64.0.0/10 dev wg0
Open the WireGuard port on Azure Network
On your Azure Portal, go to the Network Settings of your Azure VM, and add an Inbound Rule on port 51820, to allow external WireGuard connections.
Use the WireGuard Routing Target in your Routing Policy
With the above in place, you can now update the Routing Policy used by your Endpoint(s) (via Endpoint Groups), to send traffic destined for services hosted in your Azure Subnet, over the WireGuard connection.
Head over the the Stacuity Portal, and edit (or create) the Routing Policy used by your Endpoints, from there select the newly created WireGuard Server Routing Target, and set the Destination IP Address Pattern to match your Azure VNET Address space:
When done, click 'Save and Apply Rules'
Testing the connection
From your Endpoint, you should now be able to ping/access your Azure Ubuntu VM (or any other services in the subnet),which in our example is 10.1.0.4/24
Updated about 1 year ago