Deploy your first firewall — Azure

Manual install

This page covers the manual install path — launch a VM yourself and run the bootstrap one-liner. You can also provision it with infrastructure as code (Terraform / native cloud automation). See the launch options.

The engine is a single Linux daemon that filters traffic at line rate using standard Linux network primitives. You’ll deploy it on an Azure Linux VM you control, in your own VNet. Plan on ~5 minutes from “create VM” to “first packet inspected”.

Note

For NAT / inspection topologies the engine has to forward traffic that isn’t addressed to it. Azure NICs block this by default; we’ll turn on IP forwarding on the NIC in step 3.

1. Pick a VM size

• Lab / proof-of-concept — Standard_B2s (2 vCPU, 4 GiB) for <100 Mbps and a handful of flows/sec.
• Production egress / east-west — Standard_F4s_v2 or Standard_F8s_v2. The engine auto-tunes hardening meters to VM size.
• Image — any modern Ubuntu (22.04+ LTS recommended), Debian, RHEL, Rocky, or Alma.

2. Create the VM

1. Portal → Virtual machines → Create.
2. Image / size — from step 1.
3. Authentication — SSH public key. (Password auth disabled — security baseline.)
4. Networking — VNet/subnet you want firewalls deployed in. The engine needs outbound 443 to api.enforza.io; if the VNet has a route to the internet that’s enough.
5. Public IP — assign one for the management interface unless you have private connectivity (Express Route / VPN) covering outbound HTTPS.
6. NSG outbound — allow all (default), or scope to HTTPS to the control plane plus whatever destinations your future policy needs to permit.
7. Identity — enable System-assigned managed identity. Saves a step if you later add an Azure Monitor log-export sink (the sink editor’s setup guide expects this).
8. Review + create. Note the VM name.

3. Enable IP forwarding on the NIC

Azure’s NIC-level enableIPForwarding is the equivalent of AWS’s source/destination check — it lets the NIC accept and emit packets that aren’t its own IP. Without it, an inspection VM can’t forward.

# Look up the NIC name
az vm show -g <resource-group> -n <vm-name> \
  --query 'networkProfile.networkInterfaces[0].id' -o tsv

# Turn on IP forwarding
az network nic update \
  --resource-group <resource-group> \
  --name <nic-name> \
  --ip-forwarding true

Portal equivalent: the VM’s NIC → IP configurations → toggle Enable IP forwarding.

Caution

Multi-NIC inspection VMs: turn it on for every NIC, not just the primary. The flag is per-NIC.

4. (Inspection topology) route subnets through the engine

For VNets where this engine should see other subnets’ traffic: create a User Defined Route (UDR) on those subnets with a 0.0.0.0/0 next-hop of type Virtual appliance pointing at the engine VM’s private IP. Azure delivers the forwarded packets back out the engine’s NIC because IP forwarding is on.

5. Generate a deployment (registration) key

1. In the Enforza console, go to Deployment Keys.
2. Click Mint key, give it a hint (e.g. westeurope-edge-1) — becomes the engine’s display name.
3. Copy the one-time install command shown.

Deployment Keys — the same console surface, regardless of which cloud the engine will run in.

6. Install the engine

1. SSH into the VM.

2. Paste the install command:

   curl -fsSL https://downloads.enforza.io/install.sh \
     | sudo bash -s -- --regkey=YOUR-KEY-HERE

3. ~30–60 seconds. The script detects the distro, installs prereqs, fetches the engine binary, registers, and starts the systemd unit.

7. Verify

1. On the VM: systemctl status enforza-engine — should be active (running).
2. In the console: Firewalls — engine appears with status Online within ~10 s.

Troubleshooting

• “registration key not found” — key consumed by another engine or expired. Mint a fresh one.
• Engine running but offline in console — outbound 443 blocked. Check the VM’s NSG, the subnet’s NSG, and any Azure Firewall in front of it.
• Engine online but traffic not forwarding — IP forwarding still off, or no UDR pointing at the engine’s private IP. Re-check steps 3 and 4.