Routinator on Ubuntu 24.04 on Azure User Guide

Overview

Routinator is open source RPKI Relying Party software from NLnet Labs. Resource Public Key Infrastructure (RPKI) lets the holder of an IP prefix publish a signed statement, a Route Origin Authorisation (ROA), declaring which Autonomous System is allowed to originate that prefix in BGP. Routinator fetches the RPKI data from the five Regional Internet Registry trust anchors (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC), cryptographically validates the ROAs, and serves the resulting Validated ROA Payloads (VRPs) to your routers over the RTR protocol so they can mark BGP routes as valid, invalid or not found and drop or de prefer the invalid ones. It is a single self contained Rust binary with no external database, and it also exposes a read only status web interface, Prometheus metrics, and a JSON and CSV data API.

The cloudimg image installs Routinator 0.15.2 from the official NLnet Labs package repository, running under systemd as the routinator service, then locks it down for a marketplace appliance. Routinator's HTTP interface is bound to loopback 127.0.0.1:8323 so it is never exposed directly, and an nginx reverse proxy on port 80 adds a per-VM HTTP Basic Auth gate in front of it. The RTR server listens on port 3323 for your routers. Since Routinator 0.12.0 the RIR trust anchors are built into the binary, so the appliance validates fresh from the RIRs on first boot with no manual initialisation step. Backed by 24/7 cloudimg support.

What is included:

• Routinator 0.15.2 installed from the NLnet Labs apt repository and running as the routinator systemd service
• The read only status web interface on :80, fronted by nginx with Routinator's own HTTP listener bound to loopback 127.0.0.1:8323
• Per-VM HTTP Basic Auth (user admin) protecting the web interface, with a unique password generated on first boot
• The RTR server on 0.0.0.0:3323 serving Validated ROA Payloads to your routers
• The five RIR trust anchors built into Routinator, validated fresh from the RIRs on first boot, so no stale cache ships in the image
• A minimal /etc/routinator/routinator.conf you can extend with local exceptions (SLURM), extra TALs or a refresh interval
• routinator.service plus nginx.service as systemd units, enabled and active
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point; Routinator is light on CPU and RAM but keeps an on disk RPKI cache of roughly one to two GiB. NSG inbound: allow 22/tcp from your management network, 80/tcp for the web interface, and 3323/tcp from your router networks for RTR. NSG outbound: Routinator needs 443/tcp (RRDP over HTTPS, its primary transport) and 873/tcp (rsync, a fallback for the few publication points not served over RRDP) to reach the RIR and CA publication points. Routinator serves plain HTTP on port 80; for production, terminate TLS in front of it with your own domain and restrict access to trusted IP ranges (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Routinator by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). After deployment, add an inbound NSG rule for 3323/tcp from your router networks. Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name routinator \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name routinator --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name routinator --port 3323 --priority 1020

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services and listeners

Routinator and nginx are enabled and active out of the box. Routinator's HTTP interface is bound to loopback 127.0.0.1:8323 (nginx is the only public gate), while the RTR server listens on 0.0.0.0:3323 for your routers.

systemctl is-active routinator.service nginx.service
routinator --version
ss -tlnH | awk '{print $4}' | grep -E ':(8323|3323|80)$' | sort -u

Step 5 - Confirm the first RPKI validation completed

On first boot Routinator fetches and validates the RPKI data from all five RIRs, which takes a few minutes. When it finishes, the routinator_vrps_final metric reports the number of Validated ROA Payloads and the status API records the last update. A non-empty VRP count means Routinator is doing its job.

curl -s http://127.0.0.1:8323/metrics | grep '^routinator_vrps_final'
curl -s http://127.0.0.1:8323/api/v1/status | jq '{lastUpdateStart, lastUpdateDone, lastUpdateDuration, serial}'

Step 6 - Retrieve the per-VM web UI password

The web interface is protected by nginx HTTP Basic Auth (user admin) with a unique password generated on first boot and stored on the VM.

sudo cat /root/routinator-credentials.txt

The file records ROUTINATOR_URL, ROUTINATOR_USERNAME and ROUTINATOR_PASSWORD. Open http://<vm-public-ip>/ in your browser and sign in as admin with that password to reach the status interface.

Step 7 - Explore the status web interface

The Prefix Check page validates a prefix and origin AS against the current RPKI data and shows the data freshness for each RIR trust anchor.

The Metrics page breaks the validation down per RIR: valid and invalid ROAs, total and final VRPs, publication points, manifests, CRLs and certificates.

The Repositories page lists every RPKI publication point Routinator fetched from, with the VRP counts contributed by each.

The Connections page shows the RRDP and rsync fetches Routinator made, with per-source duration, HTTP status and serial.

Step 8 - Verify the Basic Auth gate

nginx is the appliance's authentication gate. The unauthenticated /healthz endpoint returns 200 for load balancer probes, while the web interface returns 401 until you supply the per-VM password.

PASS=$(sudo grep '^ROUTINATOR_PASSWORD=' /root/routinator-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'healthz (no auth) : %{http_code}\n' http://127.0.0.1/healthz
curl -s -o /dev/null -w 'ui (no auth)      : %{http_code}\n' http://127.0.0.1/ui/
curl -s -o /dev/null -w 'ui (per-VM pass)  : %{http_code}\n' -u "admin:$PASS" http://127.0.0.1/ui/
curl -s -u "admin:$PASS" http://127.0.0.1/api/v1/status | jq '{version, serial, lastUpdateDone}'

Step 9 - Connect your routers to the RTR endpoint

Routinator serves the Validated ROA Payloads to routers over the RTR protocol (RFC 6810 and 8210) on port 3323. Point your routers at <vm-public-ip>:3323 and restrict that port to your router networks with the NSG. You can preview the exact data your routers will receive over the CSV endpoint on the box.

ss -tlnH | awk '{print $4}' | grep ':3323$'
grep -E 'http-listen|rtr-listen|repository-dir' /etc/routinator/routinator.conf
curl -s http://127.0.0.1:8323/csv | awk 'NR<=6'

On a Juniper or Cisco router you configure Routinator as an RPKI validator (an rpki / validation-session pointing at <vm-public-ip> port 3323), then apply origin-validation policy to your BGP sessions. See the Routinator documentation for per vendor router configuration.

RPKI trust anchors and the ARIN Relying Party Agreement

By deploying and operating Routinator you are acting as an RPKI relying party: you consume the trust anchors published by the five RIRs and validate the RPKI objects beneath them. Since Routinator 0.12.0 the trust anchor locators for all five RIRs, including ARIN, are built into the binary and loaded automatically, so no separate initialisation or ARIN Relying Party Agreement acceptance command is required to start validating. ARIN's trust anchor and RPKI data remain subject to ARIN's Relying Party Agreement, and the other RIRs publish their own terms; as the operator you are the relying party under those terms. If your policy requires excluding a particular RIR's trust anchor you can do so with the --no-rir-tals and --tal options; see the Routinator initialisation documentation.

Maintenance

• Re-validation runs automatically every 10 minutes; Routinator keeps its RPKI cache under /var/lib/routinator/rpki-cache and updates it incrementally.
• Local exceptions (SLURM) let you add or filter VRPs for your own network; add a slurm file reference to /etc/routinator/routinator.conf and reload with sudo systemctl reload routinator.
• Change the web UI password by rewriting the nginx Basic Auth file: printf '%s' 'new-password' | sudo htpasswd -iB /etc/nginx/.routinator.htpasswd admin, then sudo systemctl reload nginx.
• Add TLS by placing your certificate in front of nginx and serving the web interface over 443 with your own domain; keep the RTR port restricted to your router networks.
• Outbound access to 443/tcp (RRDP) and 873/tcp (rsync) must stay open, or validation will stall and VRP counts will fall behind.
• Updates: apply OS security updates with sudo apt-get update && sudo apt-get upgrade, which also picks up new Routinator releases from the NLnet Labs repository.

Support

This image is maintained by cloudimg with 24/7 support. For help, contact support@cloudimg.co.uk.