Which Identifier Does Your VPN Reservation Need?

Three conditions decide which identifier a reservation should use: which system hands out the address, whether that system ever sees a layer-2 frame, and what it uses as its client key. A home router doing DHCP, a bridged VPN and a routed tunnel answer those questions differently. Choosing the identifier is more durable than trying to freeze every MAC address an adapter reports, because the identifier is the thing the allocator actually reads.

Start at the allocator and work backward; the client-side identifier is whatever that system accepts.

Ask the Allocator First

A DHCP server allocates from a pool and matches reservations against an identifier it recognises, which may be the hardware address, a client identifier string or a DUID depending on the protocol version. A VPN server allocates from its own pool and matches against whatever its configuration model exposes, often the authenticated common name. A bridged network can hand the same problem to the DHCP server that already serves the LAN. Each is a different lookup, and a reservation valid in one is invisible to the others.

Confirm what the server actually sees before configuring anything. A reservation naming the wrong identifier fails silently: the client simply receives a pooled address, and the mistake looks like a client problem.

Where a MAC Address Still Means Something

On a physical Ethernet or Wi-Fi link, the hardware address identifies an interface on that segment. Privacy features rotate it, virtual adapters create new ones, and a laptop may present different values on Wi-Fi and on a dock. A routed TUN tunnel carries IP packets and does not convey the original wireless identity to a remote DHCP server, so a MAC-based reservation on that path has nothing to match. TAP differs: it carries Ethernet frames and can join a bridged domain where layer-2 identifiers still matter.

Even there, the relevant address is the one used on that domain, not automatically the physical uplink's.

Tunnel Addresses and Peer Keys Own Their Own Space

A routed OpenVPN deployment assigns addresses through its own model: per-client configuration keyed by an authenticated name, or an explicit pool. Changing a LAN router's DHCP reservation does not create that assignment, and adding a tunnel reservation does not influence the LAN. WireGuard goes further, because a peer is identified by its public key and allowed addresses rather than any hardware identifier. No generic Ethernet reservation substitutes for peer configuration there.

Keep an inventory that separates four objects: the device credential, the virtual adapter, the allocator's identifier and the assigned address. One physical machine can have several adapters, addresses and sessions.

A Stable Address Is Not an Identity

A predictable address is operationally convenient and is not an authentication credential. Access rules that rely on an address stop being identity checks the moment it is reassigned, shared or spoofed. If a rule depends on the address, coordinate reassignment and revocation with whoever owns the identity, and keep the real authentication decision elsewhere. That keeps a convenience from becoming the only evidence of which device connected.

Record the allocator, the identifier and the assigned address together. When one changes, the other two are what you check.

If two systems both claim to allocate for the same subnet, decide which one owns it before adding reservations to either.