OpenIKED

• Sign in to the Azure Portal and search the Marketplace for OpenIKED on Ubuntu 24.04 LTS by SecureAnyCloud.
• Select Create.
• Choose your subscription, resource group and region.
• Set the virtual machine name and select size Standard_B2s or larger.
• Set the administrator username to azureuser and upload your SSH public key.
• Under Inbound port rules, allow SSH (22) from your own address only.
• Review and create the VM.

az group create --name openiked-rg --location eastus
az vm image terms accept --urn sac1647283583153:openiked-ubuntu-24-04:default:latest
az vm create \
  --resource-group openiked-rg \
  --name openiked-vm \
  --image sac1647283583153:openiked-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Restrict the network security group. Allow SSH from your own address only, and allow the IKE ports from your VPN peer only. Never open UDP 500 or 4500 to the whole internet.

# SSH, from your address only az network nsg rule create --resource-group openiked-rg \
  --nsg-name openiked-vmNSG --name allow-ssh \
  --priority 1000 --access Allow --protocol Tcp \
  --destination-port-ranges 22 --source-address-prefixes "<your-public-ip>/32"
# IKEv2 and NAT traversal, from your VPN peer only az network nsg rule create --resource-group openiked-rg \
  --nsg-name openiked-vmNSG --name allow-ikev2 \
  --priority 1010 --access Allow --protocol Udp \
  --destination-port-ranges 500 4500 --source-address-prefixes "<peer-public-ip>/32"

Connect as the azureuser administrator:

ssh azureuser@<vm-public-ip>

To look up the public IP address, run:

az vm show --resource-group openiked-rg --name openiked-vm \
  --show-details --query publicIps --output tsv

Check the daemon and the host key:

sudo openiked-ctl status

The output shows that the daemon is active and enabled, that the per-VM key is present with mode 600 root:root, and that the policy count is zero. A policy count of zero is the secure default: the gateway accepts nothing until you declare a peer.

Confirm that the daemon is listening on the IKE ports:

sudo ss -ulnp | grep -E ':(500|4500)'

The host keypair was generated on the first boot of this VM. It is not in the SecureAnyCloud image, and no other deployment holds it. Inspect the fingerprint, the key files and their permissions:

sudo openiked-ctl fingerprint
sudo ls -l /etc/iked/private/local.key /etc/iked/local.pub
sudo stat -c '%a %U:%G' /etc/iked/private

The private key has mode 0600 and is owned by root. It sits inside a directory with mode 0700. Give a peer the public key only, never the private key:

sudo openiked-ctl pubkey

A running daemon and an open UDP port prove nothing about a VPN. Run the self test instead. It performs an actual IKEv2 exchange between two isolated endpoints on this VM, authenticates with this VM's own host key, and then checks the kernel's IPsec state.

sudo openiked-ctl selftest

Every line of the output is a distinct assertion:

• A keyed security association was installed in both directions, rather than an empty stub entry in the kernel.
• Both daemons reached the established state.
• The peer's public key was validated and its signature verified.
• The identities are the expected ones.
• The negotiated transform is AES 256 with HMAC SHA2 512 and ECP 256 forward secrecy.
• The kernel actually encrypted traffic.

A test that can only pass proves little. The negative control repeats the exchange with the responder holding the wrong private key. It passes only if no tunnel is established.

sudo openiked-ctl selftest --negative

sudo grep -E 'ikesa|childsa' /etc/iked.conf | grep '^#' | head -4 sudo sysctl -n net.ipv4.ip_forward

The forwarding check reports 0. The appliance terminates tunnels but does not route between networks until you enable forwarding in Step 9.

Public key authentication is the recommended method. Exchange public keys with your peer, import theirs, add a matching policy, and reload.

On this VM, print the public key and send it to your peer:

sudo openiked-ctl pubkey

Copy your peer's public key onto this VM, then import it and bind it to the peer's address:

sudo openiked-ctl import-peer <peer-public-ip> /home/azureuser/peer-local.pub

Add a policy to /etc/iked.conf. The commented Example 1 in that file is ready to copy. Replace the two network prefixes, this VM's private address and the peer's public address.

ikev2 "site-to-site" active esp \
  from 10.10.0.0/16 to 10.20.0.0/16 \
  local <this-vm-private-ip> peer <peer-public-ip> \
  ikesa enc aes-256-gcm prf hmac-sha2-256 group ecp256 \
  childsa enc aes-256 auth hmac-sha2-512 group ecp256

Validate the file and reload the daemon. The reload refuses to restart the daemon if the file does not parse, so a typo cannot take your gateway down:

sudo openiked-ctl reload

Watch the tunnel come up:

sudo openiked-ctl sa

A note on the cipher choice. The child security association uses aes-256 with hmac-sha2-512, not AES GCM and not SHA2 256. This is deliberate.

OpenIKED 7.3 accepts childsa enc aes-256-gcm in the configuration file and reports the configuration as valid. It then silently drops the proposal, so the tunnel never establishes. It also accepts auth hmac-sha2-256, and the peers authenticate successfully. The Linux kernel interface then refuses to load the security association, and the tunnel fails at the last step.

The proposals shipped in /etc/iked.conf are the ones verified to work end to end on this image.

An IPsec gateway needs three pieces of Azure configuration before it can carry traffic between networks.

1. Network security group. Allow inbound UDP 500 and UDP 4500 from your peer's address only, as shown in Step 2. Without this rule, the IKE exchange never reaches the VM.

2. IP forwarding, in two places. To route traffic between your peer's network and an Azure subnet, rather than only terminating a tunnel on this VM, enable forwarding in the guest:

sudo openiked-ctl forwarding on

Then enable it on the Azure network interface itself. This is a separate setting that Azure enforces independently of the guest:

az network nic update --name <nic-name> --resource-group openiked-rg --ip-forwarding true

3. A user-defined route. Azure does not learn your remote prefixes from IKEv2. Create a route table whose next hop for the remote network is this VM's private address. Then associate it with the subnets that should reach the far side:

az network route-table create --resource-group openiked-rg --name openiked-rt
az network route-table route create --resource-group openiked-rg \
  --route-table-name openiked-rt --name to-remote-site \
  --address-prefix 10.20.0.0/16 \
  --next-hop-type VirtualAppliance --next-hop-ip-address <this-vm-private-ip>

Manage the daemon with systemd and read its logs with journalctl:

sudo systemctl status openiked
sudo systemctl restart openiked
sudo journalctl -u openiked -n 50 --no-pager

The openiked-ctl commands are:

• openiked-ctl status: daemon and per-VM key health, exits non-zero when unhealthy
• openiked-ctl fingerprint: SHA 256 fingerprint of this VM's public key
• openiked-ctl pubkey: print the public key to send to a peer
• openiked-ctl psk: print this VM's per-VM secret, for pre-shared key policies
• openiked-ctl sa: live IKE security associations and kernel IPsec state
• openiked-ctl import-peer <ip> <file>: trust a peer's public key
• openiked-ctl forwarding on\|off\|status: control guest IP forwarding
• openiked-ctl reload: validate, then reload the configuration
• openiked-ctl selftest [--negative]: prove a real IKEv2 negotiation

• Never copy /etc/iked/private/local.key off this VM. It is this gateway's identity. Share only the public key.
• Prefer public key authentication over pre-shared keys. If you must use a pre-shared key, use the per-VM secret from openiked-ctl psk, never a shared or memorable string.
• Keep the NSG narrow. Open UDP 500 and 4500 to your peer's address only.
• Keep proposals modern. Do not add 3DES, DES, MD5, SHA1, or the modp768, modp1024 and modp1536 groups to a policy.
• Leave forwarding off unless you route. If this VM only terminates tunnels, keep forwarding disabled.
• Apply security updates. OpenIKED is installed from the Ubuntu archive as a normal apt package, so unattended-upgrades patches it along with the rest of the system and it stays visible to vulnerability scanning.