RRAS DHCP: New Address or Just Configuration Options?

Reading a DHCPACK in a capture as proof that the VPN client got its address from DHCP is a mistake. Usually it proves only that some DHCP message was answered. Windows RRAS can hand out session addresses from its own static pool while DHCP still supplies options to the connected client. The request type tells you which of the two jobs was happening.

Two jobs that share a message type

DHCP does two separate things, and they share message types. One is allocating an address and a lease. The other is delivering configuration to a host that already has an address, which RFC 2131 calls DHCPINFORM. The reply in the second case carries options and no lease time.

So an ACK is evidence of an answer, not evidence of an allocation. The message that preceded it decides which question was asked. Read the request line first and the rest of the trace usually explains itself.

Where RRAS gets the address

RRAS owns the VPN address decision through its configured IPv4 assignment method: either a DHCP server or a static address pool. When the pool is static, the pool is the allocator, and a reservation on a separate DHCP server has no say in that session. The two mechanisms can coexist on the same network without either one controlling the other.

Get-Command -Module RemoteAccess *IPAddress*

Find the assignment method in force before debugging the address. If it is a static pool, the DHCP scope is the wrong place to look. The command above lists the cmdlets available on the version you run, which is enough to find the setting.

What a user class can and cannot prove

A DHCP user class is a string the client sends, not an authenticated group membership. Even when a client sends one and the server matches a policy on it, the label proves only that the string arrived. RFC 3004 says plainly that the option does not authenticate entitlement to the class.

Do not expect a VPN username, a security-group identifier or the laptop's Ethernet address to appear in that request in a usable form. Those are authentication and directory facts, and the DHCP request carries neither. If the requirement is to distinguish authorized people, enforce it in the VPN policy where the identity actually exists. That separation is the reason the two systems stay independent.

Compare the evidence, not the ACK

Build the evidence chain instead of reading one packet. Record the address the session received, the message type and fields of the request, the options the server returned, and the client's effective configuration afterwards. Each link answers a different question, and a missing link is where the real fault usually sits.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

If the address came from the RRAS pool, a DHCP reservation explains nothing. If the options arrived but the client ignored them, the server did its job and the client configuration is the next stop. Compare those two outcomes explicitly and the ACK stops being ambiguous. Two traces, one from each assignment method, settle the argument faster than any documentation.