IPFire 2.29 on Azure User Guide
Overview
This guide covers deploying IPFire 2.29 (Core Update 203) on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.
IPFire is a free, open source (GPL 2.0) hardened firewall and router distribution built from the ground up on a Linux From Scratch base. It is not a general purpose server OS: it uses its own SysV style init, openssh, the Pakfire package manager and a red (WAN) / green (LAN) network zone model, and it is managed from a web interface on port 444 or over SSH. This image is the official IPFire x86 64 flash build, adapted by cloudimg to run as a first class Azure virtual machine.
IPFire already ships first class Azure support: on boot it detects Azure, brings the network up by DHCP, reads the SSH key you supply at deploy time from the Azure Instance Metadata Service, forces key only SSH, and opens its firewall for SSH and the web interface. Because IPFire runs no Azure guest agent, cloudimg adds one small first boot service that reports provisioning success to the Azure fabric so the VM comes up cleanly (and mirrors your key to root for full shell access).
What's included:
- IPFire 2.29 Core Update 203, the current stable release, official x86 64 build
- Agentless Azure integration: your SSH key is injected at first boot from the Instance Metadata Service, with no baked in credential
- The RED (WAN) interface is configured automatically from Azure metadata so the VM gets its address and default route
- Firewall open only for SSH (22) and the IPFire web interface (444); everything else on the RED zone is rejected by default
- IPFire WebGUI on HTTPS port 444 (self signed)
- Per machine identity: openssh regenerates its SSH host keys on first boot, and the hostname is taken from Azure
- Gen1 Hyper V (BIOS) virtual machine
- 24/7 cloudimg support
Platform: Microsoft Azure (Gen1 Hyper V / BIOS)
Default user: root (key only; no password) — plus your Azure admin user, which opens the IPFire text setup menu
Security posture
This image ships with no known credential. There is no default password and no baked in SSH key:
- The
rootaccount is locked (root:*in/etc/shadow) and password authentication is disabled in sshd (PasswordAuthentication no,PermitRootLogin prohibit-password), so every login is by key. - The only key that works is the public key you supply when you create the virtual machine. IPFire has no Azure agent, so its native cloud setup reads that key from the Instance Metadata Service (and cloudimg's first boot service mirrors it to
root). No two machines you launch ever share a secret. - No SSH host keys are baked into the image. openssh generates its own on first boot, so two machines built from this image never share a host identity.
- The firewall rejects all inbound traffic on the RED (Azure) zone except SSH (22) and the WebGUI (444). Your Azure Network Security Group is the outer boundary and should be scoped to your management address.
Prerequisites
Before deploying this image, ensure you have:
- An active Microsoft Azure subscription
- Access to the Azure Portal or Azure CLI
- An SSH key pair for VM access
- Familiarity with Azure VM management
Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger.
Step 1: Deploy the Virtual Machine
Deploy from the Azure Marketplace listing, supplying your own SSH public key. The key is injected at first boot from the Instance Metadata Service.
az vm create \
--resource-group my-rg \
--name my-ipfire \
--image <cloudimg-ipfire-marketplace-image> \
--size Standard_B2s \
--admin-username azureadmin \
--ssh-key-values ~/.ssh/id_rsa.pub \
--security-type Standard \
--public-ip-sku Standard
Scope the Network Security Group so that inbound 22 (and 444 if you want the WebGUI) is reachable only from your management address.
Step 2: Connect over SSH
Connect as root with the private key that matches the public key you supplied — this gives you a full shell:
ssh -i ~/.ssh/id_rsa root@<vm-public-ip>
There is no password prompt: password authentication is disabled, so only your key works. Your Azure admin user (the --admin-username you passed) can also log in with the same key and is dropped straight into IPFire's text setup menu (run-setup).
Step 3: Verify the image on the VM
Once connected, confirm the release and that Azure integration ran:
cat /etc/system-release
/etc/rc.d/init.d/cloud-init status
Confirm your SSH key is installed and that there is no baked credential:
cat /root/.ssh/authorized_keys
grep '^root:' /etc/shadow # root:* — account locked, no password
grep -E '^PasswordAuthentication|^PermitRootLogin' /etc/ssh/sshd_config
Step 4: Verify networking and the firewall
On Azure the WAN interface is red0, configured automatically from Azure metadata. The firewall opens only SSH and the WebGUI on the RED zone:
cat /var/ipfire/ethernet/settings | grep RED
ip -4 addr show red0 | grep inet
ss -tln | grep -E ':22|:444'
grep -E 'SSH|444' /var/ipfire/firewall/input
Step 5: The IPFire WebGUI
The IPFire web administration interface listens on HTTPS port 444 with a self signed certificate. If your Network Security Group allows inbound 444 from your address, browse to:
https://<vm-public-ip>:444/
The WebGUI uses a separate admin account. Set its password from an SSH session before you rely on the web login:
setpassword admin
(SSH remains key only; the WebGUI admin password is independent of the root SSH login.)
Step 6: Updating the image
IPFire does not ship an unattended update daemon, and this is by design for a firewall appliance. Updates are applied with the Pakfire package manager, either from the command line or the Pakfire page in the WebGUI:
pakfire update # refresh the package/core-update lists
pakfire upgrade # apply the latest IPFire Core Update
IPFire Core Updates are the project's release cadence and include kernel and security fixes; apply them on a schedule that suits your risk posture, and subscribe to IPFire security advisories.
Step 7: (Optional) Growing the disk
The image ships with IPFire's stock ~2.5 GB root filesystem. If you need more space, grow the Azure OS disk in the portal, then expand the last partition and filesystem in guest:
parted /dev/sda -- resizepart 3 100%
resize2fs /dev/sda3
Support
This image is supported 24/7 by cloudimg. For assistance, contact support through the Azure Marketplace listing.