Arbiter Edge appliance

The Edge ships in three formats. All three install the same Debian 13 appliance with the same code; pick whichever matches your hypervisor or bare-metal host.

• OVA (~620 MB) for VirtualBox, VMware Workstation, ESXi and Proxmox. Double-click import in the GUI hypervisors; qm importovf on Proxmox. Recommended for most customers.
• qcow2 (~1.2 GB) for KVM / libvirt. Native disk format for kvm; imports cleanly with virt-install --import. Recommended for headless KVM hosts.
• .deb (~50 KB) for an existing bare-metal Debian 13 host you already own and run. No hypervisor involved; you provide the OS, the .deb provides the Edge stack. The first-boot wizard does not run in this path, because the host is already configured.

For two-appliance deployments, the Primary and Secondary do not have to use the same format. Common pattern: OVA on the customer's VMware cluster, qcow2 on a KVM-only fallback host.

Resource baseline per appliance: 2 vCPU, 1 GB RAM, 8 GB disk. This serves ~250k endpoints at steady state and ~50k under heavy roaming peaks; you do not need to size up for normal enterprise loads.

Open the tenant portal at app.arbiter.ie, go to Edge / RadSec, and use one of the two download paths depending on where you need the file to land:

• Browser download ( Download OVA button): click and your browser opens its native Save As dialog. The image streams direct from Arbiter Core; the ~620 MB OVA arrives in a couple of minutes on a typical link. Best for VirtualBox / VMware Workstation operators who will import on the same workstation.
• Terminal download ( Terminal download button): click and a modal shows a one-time curl command. Paste it on a headless host (KVM hypervisor, ESXi datastore mount, Proxmox node) and the image streams straight there. The URL is valid for 15 minutes and single-use; if you need to re-download, mint a fresh token. Both OVA and qcow2 are available via this path; switch the tab in the modal.

The curl command looks like:

curl -fLOJ \
  'https://app.arbiter.ie/api/connect/edge-download/qcow2?tenant_id=<your-id>&token=<one-shot>'

The terminal token is one-shot, expires in 15 minutes and ties the download to your operator identity in the audit log. It is safe to paste into a chat for an on-call peer to run, but treat it like a password while it is live: a token in flight can be used by anyone on that host until it is consumed or expires.

Each hypervisor has its own import flow. The appliance inside is identical regardless of how you got there.

VirtualBox (workstation / desktop)

File → Import Appliance → select the OVA file → Import. Default settings are fine (2 vCPU, 1 GB RAM come pre-baked). Set the network adapter to Bridged Adapter attached to your LAN NIC so the appliance gets a real LAN IP.

VMware Workstation / Fusion

File → Open → select the OVA → name it, accept the OVF licence, Import. Then VM → Settings → Network Adapter → set to Bridged (replicate physical network connection state).

ESXi

Datastore Browser → upload the OVA. Right-click a host → Deploy OVF Template → select the uploaded file. Pick a datastore, pick the LAN port group as the network, finish.

Proxmox VE

# On the Proxmox host, after copying the OVA via scp or its web UI:
qm importovf 200 /path/to/arbiter-edge_<v>_amd64.ova local-lvm
qm set 200 --net0 virtio,bridge=vmbr0
qm set 200 --serial0 socket --vga serial0   # serial console for firstboot
qm start 200

KVM / libvirt

The qcow2 has to live under /var/lib/libvirt/images/ and be readable by qemu. libvirt's AppArmor (Debian / Ubuntu) or SELinux (RHEL / Fedora) profile only grants qemu access to disks in that path, so a qcow2 left in your home directory makes the VM fail to start with a disk permission error even though your own shell can read the file. Move it in and fix ownership:

# Move the download into libvirt's image store, then let qemu read it.
sudo mv arbiter-edge_<v>_amd64.qcow2 /var/lib/libvirt/images/

# Debian / Ubuntu:
sudo chown libvirt-qemu:kvm /var/lib/libvirt/images/arbiter-edge_<v>_amd64.qcow2

# RHEL / Fedora (SELinux):
sudo chown qemu:qemu /var/lib/libvirt/images/arbiter-edge_<v>_amd64.qcow2
sudo restorecon -v   /var/lib/libvirt/images/arbiter-edge_<v>_amd64.qcow2

Then import with virt-install. Replace <v> with the version in the filename and <host-nic> with your physical LAN interface (typically enp0s31f6 or similar; check with ip link show).

sudo virt-install \
  --name        arbiter-edge \
  --memory      1024 \
  --vcpus       2 \
  --disk        path=/var/lib/libvirt/images/arbiter-edge_<v>_amd64.qcow2,bus=virtio \
  --network     type=direct,source=<host-nic>,source_mode=bridge,model=virtio \
  --os-variant  debian13 \
  --graphics    none \
  --console     pty,target_type=serial \
  --import \
  --noautoconsole

# Start the firstboot wizard on the serial console:
sudo virsh console arbiter-edge        # Ctrl+] to escape later
sudo virsh autostart arbiter-edge      # survive host reboots

The source_mode=bridge macvtap flag puts the appliance directly on your LAN without requiring a Linux bridge on the host. The catch: the KVM host itself cannot ping or SSH the Edge VM (Linux kernel rule). Everything else on your LAN can reach it normally, including your switches. This does not affect the appliance's job; it just means you test reachability from a workstation, not from the host.

Power on the imported VM and attach to its console (VirtualBox / VMware open one automatically; on KVM use sudo virsh console arbiter-edge; on ESXi / Proxmox use the web console). The first-boot wizard runs automatically once and prompts for:

• Hostname (default: arbiter-edge). Pick something that distinguishes Primary from Secondary if you can, e.g. arbiter-edge-01 and arbiter-edge-02.
• Network mode: DHCP or static. The switches you will point at the Edge in step 6 need a stable destination address, so static is recommended. The wizard prompts for IP, prefix, gateway and DNS if you pick static.

The wizard writes the network config, restarts networking and hands the console to the Arbiter operator login. After this point the appliance has a stable IP on your LAN. If you picked DHCP, note the address shown in the post-boot banner; if you picked static, you already know it.

The wizard only runs on the very first boot. To reapply the saved network config later, log in as Arbiter (password Arbiter) and run arb-net-reapply. To change the network mode after first boot, contact Arbiter support for a wizard re-run.

Back in the portal, on the Edge / RadSec page, find the two pre-provisioned rows (labelled edge-primary and edge-secondary by default; rename them if you want).

On the first row, click Issue token. A modal opens showing a one-time activation token of the form ARB-EDGE-.... Copy it now: the plaintext is shown exactly once and only the hash is kept on the server. Tokens expire 24 hours after issue.

If a token leaks before you use it, click Revoke token and issue a fresh one. A revoked token cannot be used to activate the appliance even if it has not yet expired.

The appliance console logs you straight into the Arbiter operator account: a restricted menu of arb-* commands. To work remotely instead, SSH in as Arbiter with the password Arbiter. Then run the registration command and paste the device id shown on the portal row and the one-time token you just issued at the prompts:

arb-register
# You are prompted for the device id and the one-time token:
#   Device id:  edge-primary
#   Token:      ARB-EDGE-7f3c...e91a

Registration does several things in one go:

• POSTs the token to app.arbiter.ie over HTTPS.
• Receives a freshly-minted ECDSA leaf certificate signed by your tenant root, the trust bundle, the tenant RADIUS PSK and the cloud listener address.
• Atomic-writes those files into /etc/arbiter/edge/ and does a live TLS handshake against the cloud listener to prove the credentials work.
• Starts arbiter-edge.service. The tunnel connects within seconds and the portal flips the row from Pending to Active.

The Arbiter console is a restricted shell: it runs only the arb-* commands and registration, nothing else. All control-plane traffic stays on the outbound tunnel, and all configuration is portal-driven.

Wait for the portal row to show Active with a recent heartbeat before continuing. If it sticks on Pending, the appliance cannot reach the cloud on TCP 2083 or 443. Check the firewall first.

Repeat steps 5 and 6 for the second row (edge-secondary) on the second appliance.

Configure each switch to use both Edges as RADIUS servers in the same group. Cisco IOS / IOS-XE pattern shown below; equivalent syntax for Aruba, UniFi, Fortinet, MikroTik and the rest is in the network device guides.

! Point RADIUS auth + accounting at both Edge IPs.
! The switch fails over to Secondary automatically when Primary stops
! answering, and falls back to Primary the moment it recovers.
radius server arbiter-primary
 address ipv4 10.20.0.10 auth-port 1812 acct-port 1813
 key 7 <tenant-psk-from-portal>
!
radius server arbiter-secondary
 address ipv4 10.20.0.11 auth-port 1812 acct-port 1813
 key 7 <tenant-psk-from-portal>
!
aaa group server radius arbiter
 server name arbiter-primary
 server name arbiter-secondary
!
aaa authentication dot1x default group arbiter
aaa authorization  network default group arbiter
aaa accounting     dot1x default start-stop group arbiter

The tenant PSK to paste in for key 7 is the same on both Edges (it is per-tenant, not per-appliance). You can copy it from the same Edge / RadSec page in the portal: click the eye icon on either row to reveal.

Some switches probe the dead server periodically and only fail back when it answers. If yours does not, set its dead-server-detect interval to 30 s or less so a Primary reboot recovers within a minute.

On every client VLAN, add the Edge IPs as DHCP helpers in addition to whatever DHCP server you already point at. The Edge does not serve DHCP leases: it just snoops the relayed Discover and Request frames so the endpoint-profiling pipeline can read option 55 (parameter request list), option 60 (vendor class) and the hostname.

! Relay every client-VLAN DHCP request to both Edge IPs so
! the endpoint-profiling pipeline sees the option-55 fingerprint,
! option-60 vendor class and hostname for every device that
! authenticates. Without this, MAB still works but devices show up
! in Arbiter as "Unknown" until 802.1x or accounting fills the gap.
interface Vlan10
 ip address 10.10.0.1 255.255.255.0
 ip helper-address 10.20.0.10
 ip helper-address 10.20.0.11

DHCP relay is optional for MAB to work, but without it new devices will show up in Arbiter as Unknown until 802.1x accounting fills in the gap. With it, every device has its vendor, model class and fingerprint visible the first time it touches the network, which is what your access policies need to match accurately on the very first auth.

From a workstation on a client VLAN, plug into a port that requires authentication (or join a wireless SSID backed by the policy). Then on the portal:

• Edge / RadSec page: both rows show Active, last heartbeat under one minute, certificate validity green.
• Auth Log: the new event appears within a few seconds, with the originating switch IP, the MAC, the policy matched and the VLAN assigned.
• Endpoints page: the device is listed with its vendor and model class populated (this is the DHCP-relay payoff).

If you got this far, the appliance is production-ready. The Edge renews its own leaf certificate at 30 days out, keeps its offline cache warm, accepts CoA from the cloud and ships every auth event to Arbiter for policy evaluation and SIEM forwarding.