VPN Address vs LAN DHCP Lease: Who Assigned the Tunnel IP?

Connect the client and look at the adapter instead of the Wi-Fi icon. An address such as 10.80.0.14 can sit on a tunnel while no DHCP server on the office LAN has ever recorded that lease. Which process picked the number decides where the troubleshooting starts.

On the client everything looks the same: one IPv4 address, one mask, sometimes a default gateway. The difference appears only when you ask who answers for that address and who keeps a record of it.

Read the Tunnel Address From the Client Side

Windows shows the distinction if you read the whole block rather than the first line. ipconfig /all prints an adapter description, a physical address and a DHCP line. A PPP or IKEv2 dial-up adapter normally reports DHCP as disabled, because the connection negotiated its address during dial-up instead of leasing it from a LAN server. A DHCP-enabled tunnel adapter is unusual and worth investigating on its own.

Linux splits the same information across two tools. ip -4 addr show dev tun0 gives the address and prefix length. nmcli -f IP4 connection show work reveals whether the value came from the connection profile, a DHCP exchange on the link, or a pushed configuration. WireGuard is the clearest case, since wg-quick applies the Address line from the config file when the interface appears and no peer allocates anything at connect time.

The prefix tells you something too. A /32, or a mask of 255.255.255.255, means the gateway expects to route to one host address, while a wider mask suggests an on-link subnet somewhere behind the tunnel.

What the IKEv2 Configuration Payload Carries

IKEv2 has a dedicated mechanism for this job. The Configuration Payload described in RFC 7296, section 3.15.1 carries attributes such as INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS and their IPv6 counterparts. The client sends an attribute with a zero-length value when it has no preference, and the responder returns the value it wants used. That exchange rides inside IKE_AUTH, already encrypted, so no DHCP broadcast ever crosses the tunnel.

Two consequences follow. First, the address is chosen by the responder or by whatever authorization backend the responder consults, which is why a pool can live on the gateway, in a RADIUS reply, or in an identity-provider mapping. Second, the DNS attribute is separate from the address attribute. Receiving 10.80.0.14 says nothing about which resolver came back, or whether one came back at all.

The netmask attribute is optional in practice. Plenty of deployments return only an address and let the client install a host route, which is why the same pool can look like a /32 on one client and a /24 on another.

Where a LAN DHCP Scope and a VPN Pool Collide

Trouble starts when both allocators point at the same range. A DHCP server for 10.20.30.0/24 knows nothing about a VPN pool configured for 10.20.30.128/25, so nothing stops it from leasing 10.20.30.140 to a printer while the gateway hands the same address to a remote client. The collision stays silent for days and then surfaces as an intermittent duplicate.

A routed site-to-site design avoids the collision by construction. A host in the branch keeps the address its local DHCP server gave it. The tunnel interfaces on both gateways carry their own link addresses, and the routing table decides how packets travel. Remote-access client addresses are a third category and should not be mixed with gateway link addresses.

Bridging the tunnel onto the LAN removes that separation. If the design genuinely needs one broadcast domain, the VPN endpoint has to take part in the same allocation decisions as the DHCP server, through a relay or a shared authoritative source, instead of issuing addresses on its own.

Verify Which Process Owns the Address

Prove the ownership before you change a scope. On the client, capture the address and prefix. On the LAN, search the lease database. On the gateway, list the pools it is configured to hand out. An address found in the lease file belongs to a DHCP server, which means the tunnel is bridged or relayed; an address found only in the gateway pool belongs to the tunnel endpoint.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Record four things once the answer is clear: which component assigns the client address, which range is reserved for it, how return traffic reaches that range, and which resources accept it. Those four entries turn a virtual adapter line into an operational fact.

Repeat the check for the DNS attribute while you are there. A pool that hands out addresses but no resolver leaves the client on its local DNS, which is a different failure from a pool that hands out an address the LAN already uses.