IKEv2 is a modern, robust VPN protocol that combines fast session establishment, strong cryptography, and built‑in mobility support. OpenBSD’s native IKE daemon (iked) implements IKEv2 with a focus on security and correctness, making it an excellent choice for hosting dedicated-IP VPN services for site owners, enterprises, and developers. This guide walks through a practical, production‑ready IKEv2 deployment on OpenBSD with ample technical detail: certificate management, iked configuration, PF rules, route handling, client considerations, and troubleshooting tips.

Why IKEv2 on OpenBSD?

OpenBSD is renowned for its secure defaults, code audits, and integrated network stack. Using iked on OpenBSD provides several advantages:

  • Native IKEv2 support with a small, audited codebase.
  • Consistent system integration with rcctl, pf, and native crypto/libssl.
  • Mobility and multi‑homing — IKEv2 supports MOBIKE for client roaming and NAT traversal.
  • Performance — modern ciphers and kernel network stack deliver good throughput for dedicated‑IP VPN services.

Overview of Deployment Steps

The high‑level steps covered below are:

  • Create a Certificate Authority (CA) and server/client certificates (recommended over PSK).
  • Prepare iked configuration for IKEv2 with strong cryptographic proposals.
  • Configure PF to allow IKE traffic and handle client routing/NAT as needed.
  • Enable and manage daemons with rcctl and test with common clients.

1) Cryptography: Choose Strong, Interoperable Algorithms

Design your proposals to maximize compatibility while prioritizing strong primitives. Recommended IKE/ESP proposals:

  • IKE (IKE_SA): PRF = SHA2-256, DH = X25519 (curve25519, DH group 31/28 equivalent), Encryption = AES-GCM-256 or CHACHA20-POLY1305
  • ESP (Child SA): AES-GCM-256 or CHACHA20-POLY1305; fallback AES-CBC+SHA2 if older clients required

These choices yield authenticated encryption with associated data (AEAD), reducing configuration clutter (no separate integrity algorithm required for AES-GCM/ChaCha20-Poly1305).

2) Generate a CA and Certificates

Using certificates is strongly recommended for server authentication and scalable client provisioning. The example below uses OpenSSL; you can adapt to your CA tooling.

Server steps (example commands, adapt to your environment):

  • Create a CA key and cert:

    openssl genpkey -algorithm RSA -out ca.key -pkeyopt rsa_keygen_bits:4096

    openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=VPN-CA"

  • Create server key and CSR, then sign with CA:

    openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:3072

    openssl req -new -key server.key -out server.csr -subj "/CN=vpn.example.com"

    openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 1825 -sha256

  • Secure keys and copy to OpenBSD host, e.g. /etc/ssl/private and /etc/ssl/certs. Ensure file permissions are restrictive (chmod 600).

Client certificates can be signed similarly or you can use username/password or PSKs for lightweight clients (less recommended for large deployments).

3) iked Configuration

OpenBSD’s iked uses a simple text file /etc/iked.conf. Below is an example configuration focusing on IKEv2, certificate auth, and a virtual network for route-based VPN (enc0). Adjust interface names and addresses to your topology.

Example /etc/iked.conf (annotated):

<Note: This is sample content to paste into /etc/iked.conf — adapt CNs and addresses>

listen on egress
ikev2
include /etc/iked/ikev2.conf

Contents of /etc/iked/ikev2.conf:

auth certificate
cert "/etc/ssl/certs/server.crt" key "/etc/ssl/private/server.key"
id "vpn.example.com"
policy esp encryption aes-gcm-256
policy esp encryption chacha20poly1305
proposal encalg aes-gcm-256 prf sha2-256 dhgroup curve25519
proposal encalg chacha20poly1305 prf sha2-256 dhgroup curve25519
group "default" from any to 0.0.0.0/0

Key points:

  • listen on egress instructs iked to bind to the outgoing interface (safer for dynamic IPs).
  • auth certificate makes certificate authentication the default for peers in this file; you can additionally configure PSK blocks for legacy clients.
  • policy/proposal entries set ESP and IKE proposals. Keep the list short and strong to avoid negotiation with weak algorithms.

Per‑peer or client policies

If you need separate client groups (e.g., mobile vs site‑to‑site), use peer blocks to define client-specific IP pools, IDs, and authentication. Example snippet for a client pool and virtual interface configuration:

peer "mobile" from any to 0.0.0.0/0 {
auth certificate
id "client@example.com"
ikev2 from any to 10.10.10.0/24
child {
local addrs 10.10.10.1/24
remote addrs 10.10.10.2-/24
}
}

Note: iked’s exact peer/child syntax may vary across OpenBSD versions. Refer to man iked.conf for your platform.

4) Route‑based vs Policy‑based: Use enc(4) for Flexibility

Route‑based VPNs are more flexible for multi-client or multi‑subnet setups. On OpenBSD, you can configure an enc(4) interface and assign an IP to it; iked will bind SAs to that interface when requested. Example:

  • Create and configure interface in /etc/hostname.enc0:

    inet 10.10.10.1 255.255.255.0

  • Enable at boot: rcctl enable iked and rcctl enable pf.

With enc0 configured, advertise the client pool (10.10.10.0/24) and add PF rules to pass and/or NAT traffic from enc0 to the internet or other subnets.

5) PF (Packet Filter) Rules and NAT

PF controls what traffic enters and leaves the VPN. Minimal PF rules to allow IKE and ESP are:

Example /etc/pf.conf (simplified):

ext_if="egress"
vpn_if="enc0"
set skip on lo
block all
pass in on $ext_if proto udp from any to ($ext_if) port {500, 4500} keep state
pass in on $ext_if proto esp
pass on $vpn_if from $vpn_if:network to any keep state
match out on $ext_if from $vpn_if:network to any nat-to ($ext_if)

Important items:

  • Allow UDP/500 and UDP/4500 for IKE and NAT‑T.
  • Allow ESP (IP protocol 50) if clients are not using NAT‑T. If NAT-T is used, ESP may be unnecessary.
  • NAT (masquerade) traffic from enc0 if you want clients to access the Internet via the server IP.

6) System Settings & Daemon Management

Enable and start services:

  • rcctl enable iked; rcctl start iked
  • rcctl enable pf; rcctl start pf

Harden sysctl settings as needed (e.g., anti-spoofing). Example tunables in /etc/sysctl.conf:

  • net.inet.ip.forwarding=1 (if routing traffic)
  • net.inet.ip.fw.enable=0 (unless using legacy firewall)

7) Client Setup and Interoperability

Most modern clients (iOS, macOS, Windows 10/11, strongSwan on Linux/Android) support IKEv2 out of the box. Key client considerations:

  • Server identity: Use the server certificate CN or SAN that matches the DNS name clients will connect to (e.g., vpn.example.com).
  • Certificates on client: If using certificate auth, ensure the client trusts the CA (install ca.crt) and has its client certificate (client.crt, client.key) in the correct format.
  • PSK fallback: You may provide PSK entries for legacy clients, but avoid for large deployments due to poor key management.
  • MOBIKE/NAT traversal: IKEv2 handles roaming; ensure UDP/4500 is open for NAT traversal.

8) Monitoring and Troubleshooting

Logs and debugging are essential during rollout:

  • Tail system logs: tail -f /var/log/messages to view iked events and errors.
  • Increase iked verbosity temporarily: stop iked and start manually in debug mode (/usr/sbin/iked -d -D), watch for IKE_SA negotiation steps, proposals, and certificate validation results.
  • Check SAs: use ikectl -s or platform-specific status utilities to list active SAs and children; consult man ikectl.
  • PF counters: pfctl -s state and pfctl -s nat help verify traffic flows.

9) Security Best Practices

  • Prefer certificates over PSKs. Certificate revocation and per-client keying provide better control.
  • Use long-lived server keys (3072–4096 bits RSA or ECC keys like X25519/Ed25519) and rotate client certs periodically.
  • Limit management access to the OpenBSD host; use separate out-of-band management NIC or firewall rules.
  • Use a dedicated IP address for the VPN endpoint where possible to simplify DNS and ACLs.

10) Scalability and Operational Tips

For larger deployments consider:

  • Automated certificate issuance (ACME for server certs and a private PKI for client certs) and key management workflows.
  • Monitoring SAs, bandwidth, and client counts with standard tools (netstat, ifstat, SNMP exporters) and alerting for stale SAs or saturating links.
  • Load balancing across multiple OpenBSD nodes using DNS round-robin with session affinity, or fronting with a TCP/UDP load balancer that preserves source IP and port when possible. Note IKEv2 relies on UDP and IPsec SAs, so stateful load balancing must be IPsec-aware or use distinct public IPs per node.

IKEv2 on OpenBSD offers a secure, performant, and maintainable foundation for dedicated‑IP VPN services. With certificate-based authentication, strong AEAD cipher suites, careful PF rules, and route‑based enc interfaces, you can deliver robust VPN access for employees, partners, and customers. For production, document your certificate lifecycle, automate provisioning where possible, and monitor SA and network health closely to maintain reliable service.

For more deployment guides and tailored VPN solutions, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.