Static OpenVPN Client Addresses Behind OPNsense

Names need addresses that do not move, and OpenVPN's pool file only makes an address sticky. Lose that file, or reissue a certificate under a different common name, and the returning client lands somewhere else in the pool while its DNS record still points at the old address. The durable answer is a client-specific override that pins the address, plus a wider tunnel network so pinned addresses sit outside the dynamic range. The arithmetic behind that widening is where most of the confusion lives.

OPNsense keeps those overrides in the server's client-specific settings, keyed by the certificate common name, which makes the common name part of the address plan.

A Sticky Lease Is Not a Static Address

The pool file writes address-to-client mappings and hands them back when a known client reconnects. That is convenience rather than a contract: the file can be regenerated, the mapping disappears when the client's identity changes, and two servers sharing a pool will not agree about it. A client-specific override works differently, because the address comes from configuration instead of from history. It also survives a restart and a reinstall of the appliance, provided the override is backed up with the rest of the configuration.

The dynamic alternative, wiring the VPN into DNS with a client-connect script and dynamic updates, works and requires a resolver that accepts updates plus a script on every connect. On an appliance you are limited to the packages the vendor ships, which is usually where that plan stops.

The /30 Arithmetic Nobody Enjoys

Under the default net30 topology, each client gets its own /30: the first usable address goes to the server side, the second to the client. Overrides must therefore sit outside the server's dynamic tunnel network, which means widening that network first. A server on 10.8.0.0/24 can move to 10.8.0.0/23, leaving half the old range for dynamic clients and the other half for overrides. Add the original /24 as an additional IPv4 local network so traffic to both halves routes into the tunnel.

Each override address has to land on a /30 boundary, so the last octet is a multiple of four. A /30 at 10.8.1.0 gives the client 10.8.1.2, and that is the address the DNS record carries. Choosing 10.8.1.3 instead produces a client that connects and cannot pass traffic, because the address belongs to a subnet the topology never assigned it.

The plan is easier to keep if overrides are allocated from the top of the widened range downward, so the dynamic pool expands into free space rather than around fixed islands.

Local Networks and the Zone Clients Query

Client-to-client traffic needs its own permission. The server's IPv4 local networks list has to include both halves of the range, dynamic and static; without it the server accepts a packet from one client and has no policy allowing it through to another. The symptom reads like a DNS failure, because the name resolves and the connection still fails. Check the client-to-client setting at the same time, since a local-network entry alone does not enable forwarding between peers.

Publish the records in the zone remote clients actually query. A record in a zone served only by the LAN resolver is invisible to a client whose pushed resolver points elsewhere, and adding more records to the wrong zone never repairs that. Confirm the pushed DNS option and the search domain before adding anything.

What to Check on a Fresh Connection

Reconnect the client and confirm the assigned address matches its override before testing anything else. Then resolve the name from a second client and connect to the service by name, which exercises the DNS record, the route and the firewall together. Confirm the reply path on the server side, since a name that resolves while the service stays unreachable is a routing or policy problem rather than a naming one. Keep the override table next to the certificate list so both get reviewed together.

A certificate reissued under a different common name stops matching its override and returns the client to the dynamic pool. Expect that after any identity change.