Outline VPN Server

• In the Azure Portal, choose Create a resource and search the Marketplace for Outline Server on Ubuntu 24.04 by SecureAnyCloud.
• Select the offer, then select Create.
• On Basics, pick your subscription, resource group and region, set the VM name, and choose size Standard_B2s.
• For Authentication type, choose SSH public key, set the username to azureuser, and supply your public key.
• On Disks, leave the OS disk as Standard SSD or better.
• On Networking, select your virtual network and subnet. Allow SSH (22) for now. Step 3 adds the two Outline ports.
• Select Review + create, then Create.

Run the following to create the network resources, accept the Marketplace terms and create the VM:

az group create --name outline-rg --location eastus
az network vnet create --resource-group outline-rg --name outline-vnet \
  --address-prefix 10.20.0.0/16 --subnet-name outline-subnet --subnet-prefix 10.20.1.0/24
az network nsg create --resource-group outline-rg --name outline-nsg
az vm image terms accept --urn sac1647283583153:outline-vpn-server-ubuntu-24-04:default:latest
az vm create \
  --resource-group outline-rg \
  --name outline-server \
  --image sac1647283583153:outline-vpn-server-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --storage-sku StandardSSD_LRS \
  --admin-username azureuser \
  --generate-ssh-keys \
  --vnet-name outline-vnet --subnet outline-subnet --nsg outline-nsg \
  --public-ip-sku Standard

Outline needs exactly two ports open, and nothing else. 60443/tcp carries the management API that Outline Manager talks to. 60444/tcp and 60444/udp carry client traffic, because Shadowsocks needs both.

Restrict the management port to the addresses you administer from. Client traffic comes from wherever your users are, so the access key port stays open to the internet.

# management API — lock this down to the network you administer from az network nsg rule create --resource-group outline-rg --nsg-name outline-nsg \
  --name allow-outline-management --priority 1010 \
  --access Allow --protocol Tcp --direction Inbound \
  --source-address-prefixes <your-mgmt-cidr> --destination-port-ranges 60443
# access keys — your users connect from anywhere, over TCP and UDP az network nsg rule create --resource-group outline-rg --nsg-name outline-nsg \
  --name allow-outline-keys-tcp --priority 1020 \
  --access Allow --protocol Tcp --direction Inbound \
  --source-address-prefixes '*' --destination-port-ranges 60444 az network nsg rule create --resource-group outline-rg --nsg-name outline-nsg \
  --name allow-outline-keys-udp --priority 1030 \
  --access Allow --protocol Udp --direction Inbound \
  --source-address-prefixes '*' --destination-port-ranges 60444

Connect to the VM over SSH as azureuser:

ssh -i ~/.ssh/id_rsa azureuser@<vm-ip>

The login banner shows the two ports and how to read your connection details. It deliberately does not print the management API path, because that path is a credential.

First boot takes a few seconds, because it generates an RSA-4096 keypair before the service is allowed to start. Check the services and the container:

sudo systemctl is-active docker.service outline-vpn-server.service outline-vpn-server-firstboot.service
sudo docker ps --format 'table {{.Names}}\t{{.Status}}'

Expected output:

active active active NAMES STATUS shadowbox Up 6 seconds

All three are active. outline-vpn-server-firstboot.service stays active after it finishes because it is a oneshot with RemainAfterExit=yes. It is safe to run again: it detects that the machine is already bootstrapped and exits without changing anything.

Now list every socket the machine is listening on. Only SSH and the two Outline ports are reachable from the internet. The bundled Prometheus, Outline's own node metrics and the Shadowsocks metrics endpoint are all bound to loopback, and the Docker API does not listen on any port.

echo 'PUBLIC (reachable from the internet):'
sudo ss -H -lntu | awk '{p=$1;a=$5; if(a ~ /^127\./ || a ~ /^\[::1\]/ || a ~ /%lo/) next; n=split(a,x,":"); printf " %-4s %-20s\n", p, a}' | sort -u
echo 'LOOPBACK ONLY:'
sudo ss -H -lntu | awk '{p=$1;a=$5; if(!(a ~ /^127\./ || a ~ /^\[::1\]/ || a ~ /%lo/)) next; n=split(a,x,":"); if(x[n]>=9090 && x[n]<=9092) printf " %-4s %-20s\n", p, a}' | sort -u

Expected output on a machine with no access keys yet. The access key port opens when you create your first key.

PUBLIC (reachable from the internet): tcp *:60443 tcp 0.0.0.0:22 udp 10.20.1.4%eth0:68 LOOPBACK ONLY: tcp 127.0.0.1:9090 tcp 127.0.0.1:9091 tcp 127.0.0.1:9092

The outline-keys server command asks the management API about itself. Note the version and metricsEnabled fields.

sudo outline-keys server

Expected output:

{ "name": "Outline Server", "serverId": "2557a594-a1fd-4aca-9625-c36a26679063", "metricsEnabled": false, "createdTimestampMs": 1785081463977, "version": "1.12.3", "portForNewAccessKeys": 60444, "hostnameForAccessKeys": "52.147.203.56" }

serverId is unique to your machine and generated on its first boot. metricsEnabled is false, so nothing is reported anywhere unless you opt in. hostnameForAccessKeys is the public address this machine resolved for itself. Every access key you create embeds this address.

The full details, including the management API path and the certificate fingerprint, live in a root-only file:

sudo stat -c '%a %U:%G %n' /root/outline-vpn-server-credentials.txt
sudo sed -E 's@(:60443/)[A-Za-z0-9_-]+@\1API-PATH-REDACTED@g; s@(SHA256=[0-9A-F]{12})[0-9A-F]+@\1...REDACTED@' /root/outline-vpn-server-credentials.txt

Expected output follows. The API path and the fingerprint are redacted because both are secrets. Run sudo cat on the file to see your real values.

600 root:root /root/outline-vpn-server-credentials.txt
# Outline Server (Shadowbox) 1.12.3 - per-VM connection details
# Generated on first boot by outline-vpn-server-firstboot.service. OUTLINE_API_URL=https://52.147.203.56:60443/API-PATH-REDACTED OUTLINE_CERT_SHA256=7BFAF80EEA70...REDACTED OUTLINE_API_PORT=60443 OUTLINE_ACCESS_KEY_PORT=60444 OUTLINE_SERVER_VERSION=1.12.3 OUTLINE_ACCESS_KEYS=0

The container is pinned by digest, and there is no automatic updater. Confirm both:

sudo docker inspect shadowbox --format 'running: {{.Config.Image}}'
sudo docker ps -a --format '{{.Image}} {{.Names}}' | grep -ci watchtower || echo 'watchtower containers: 0'

Expected output:

running: quay.io/outline/shadowbox@sha256:545c6f7c7261bb30ae1dffe24a6fca5f8512f5d17c72cfb9e410e7e655444e62 watchtower containers: 0

This check is worth doing once, because it shows the whole security model. Every per-machine secret is 0600 root:root:

sudo stat -c ' %a %U:%G %n' /root/outline-vpn-server-credentials.txt /etc/outline/outline.env /opt/outline/persisted-state/shadowbox-selfsigned.key

Expected output:

600 root:root /root/outline-vpn-server-credentials.txt 600 root:root /etc/outline/outline.env 600 root:root /opt/outline/persisted-state/shadowbox-selfsigned.key

Now prove that the random path is the credential. Send three wrong requests, then the right one:

PREFIX="$(sudo sed -n 's/^SB_API_PREFIX=//p' /etc/outline/outline.env)" printf ' %-38s HTTP %s\n' 'no path at all' "$(curl -ks -o /dev/null -w '%{http_code}' https://127.0.0.1:60443/)" printf ' %-38s HTTP %s\n' 'a random 128-bit path' "$(curl -ks -o /dev/null -w '%{http_code}' https://127.0.0.1:60443/$(openssl rand -hex 11)/server)" printf ' %-38s HTTP %s\n' 'this path with ONE character changed' "$(curl -ks -o /dev/null -w '%{http_code}' https://127.0.0.1:60443/${PREFIX%?}X/server)" printf ' %-38s HTTP %s\n' 'this machine own path' "$(curl -ks -o /dev/null -w '%{http_code}' https://127.0.0.1:60443/$PREFIX/server)"

Expected output:

no path at all HTTP 404 a random 128-bit path HTTP 404 this path with ONE character changed HTTP 404 this machine own path HTTP 200

A single wrong character returns 404. There is no login page to brute force and no username to guess. This is why you must never share or log the path.

The certificate is the second half of the model. It is self-signed, so Outline Manager does not validate a chain. It pins the fingerprint instead. Confirm that the certificate served on the wire is the one this machine generated:

SERVED="$(printf '' | openssl s_client -connect 127.0.0.1:60443 2>/dev/null | openssl x509 -noout -sha256 -fingerprint | sed 's/^.*=//' | tr -d ':')" RECORDED="$(sudo sed -n 's/^OUTLINE_CERT_SHA256=//p' /root/outline-vpn-server-credentials.txt)" if [ "$SERVED" = "$RECORDED" ]; then echo "fingerprints match: this is this machine's own certificate"; else echo "MISMATCH"; fi
sudo openssl x509 -in /opt/outline/persisted-state/shadowbox-selfsigned.crt -noout -subject

Expected output follows. Your Common Name is your VM's short hostname.

fingerprints match: this is this machine's own certificate subject=CN = outline-server

The Common Name is the machine's short hostname, not its full Azure name. X.509 caps a Common Name at 64 characters, and an Azure FQDN is routinely longer. The FQDN, the private address and the public address therefore travel in a subjectAltName instead.

The image ships with no access keys, so nothing is shared between deployments. List the keys, then create your first one:

sudo outline-keys list
sudo outline-keys add "alice laptop"

Expected output:

[] { "id": "0", "name": "alice laptop", "port": 60444, "accessUrl": "ss://KEY-SECRET-REDACTED@52.147.203.56:60444/?outline=1" }

The accessUrl is the whole credential a client needs. Send it to its owner over a channel you trust, and treat it like a password. Creating the first key also opens the Shadowsocks port:

# the listener appears within a second or two of the key being created for i in $(seq 1 15); do L="$(sudo ss -H -lnt | awk '{n=split($4,a,":"); print a[n]}')" case " $L " in *" 60444 "*) break ;; esac sleep 1 done
sudo ss -H -lntu | awk '$5 ~ /:60444$/ {printf " %-4s %s\n", $1, $5}' | sort -u

Expected output:

tcp *:60444 udp *:60444

Both protocols are listening, as Shadowsocks requires. If you had opened only TCP in Step 3, clients would connect but UDP-based traffic such as DNS and video calling would fail.

Outline Manager takes a single JSON line that contains the API URL and the certificate fingerprint. Print it:

sudo outline-keys config

Expected output follows. Your own values will differ. This is the line to paste.

{"apiUrl":"https://52.147.203.56:60443/API-PATH-REDACTED","certSha256":"7BFAF80EEA70B99FEA0F03C8BF5104CD79AE5A6D2144621DF298B68CB49F482F"}

In Outline Manager, choose Set up Outline anywhere, then paste that line into the box in step 2 of its wizard. Manager connects and verifies the certificate fingerprint. From then on you can manage keys graphically as well as from the command line.

Both interfaces drive the same API, so keys created over SSH appear in Manager, and the other way round.

Install the Outline client for the user's platform from getoutline.org, then paste the accessUrl from Step 8 into it. The client shows the server and a connect toggle. Nothing else needs configuring.

Revoking a key takes effect immediately and affects only that key:

ID="$(sudo outline-keys list | jq -r '.[0].id')"
sudo outline-keys rm "$ID"
sudo outline-keys list

Expected output:

revoked access key 0 []

Revocation is deliberately fail-closed. outline-keys rm checks the API's status code and re-reads the key list to confirm the key is gone, so it never reports success while a key is still live. Revoking an ID that does not exist exits with a non-zero status instead of printing a reassuring message:

if
sudo outline-keys rm 99999 >/dev/null 2>&1; then echo 'reported success (would be a bug)'; else echo 'refused: no such access key'; fi

Expected output:

refused: no such access key

Anything Outline Manager does, you can also do with curl. On the server, read your API URL with sudo outline-keys url. Then, from your own machine, run:

# <vm-ip> is your VM's public address; the path after the port is your API path curl --insecure https://<vm-ip>:60443/YOUR-API-PATH/server curl --insecure -X POST https://<vm-ip>:60443/YOUR-API-PATH/access-keys

--insecure is required because the certificate is self-signed. To verify the certificate instead, copy /opt/outline/persisted-state/shadowbox-selfsigned.crt off the server and pass it with --cacert. Alternatively, compare the fingerprint against OUTLINE_CERT_SHA256 from your credentials file.

Never send the API path over an untrusted channel, because it is the credential.

Access keys embed whatever address the machine resolved for itself at first boot. You may prefer keys that point at a hostname, or your machine may sit behind a load balancer or NAT address that metadata cannot discover. In either case, write the address you want before the machine's first boot, for example through Azure custom data. First boot uses it verbatim:

# runs before the first boot of a NEW machine, e.g. via custom data
sudo install -d -m 0700 /etc/outline echo '<your-domain>' | sudo tee /etc/outline/public-hostname

If the machine has already bootstrapped, change hostnameForAccessKeys through the API instead, and re-issue your keys. Existing keys keep the old address.

The management and access key ports are fixed at 60443 and 60444, so that this guide and your firewall rules can name them. To change them, edit /etc/outline/outline.conf, restart the service, and add matching firewall rules. Remember that the access key port needs both TCP and UDP.

sudo sed -i 's@^OUTLINE_API_PORT=.*@OUTLINE_API_PORT=8443@' /etc/outline/outline.conf
sudo systemctl restart outline-vpn-server.service az network nsg rule create --resource-group outline-rg --nsg-name outline-nsg \
  --name allow-outline-management-8443 --priority 1011 \
  --access Allow --protocol Tcp --direction Inbound \
  --source-address-prefixes <your-mgmt-cidr> --destination-port-ranges 8443

Changing the management port changes your API URL. Re-add the server in Outline Manager afterwards, using the new output of sudo outline-keys config.