RRAS VPN clients need their own IPv4 pool and a way back

The VPN client connects and receives an address, and the LAN host it needs still cannot answer it. In Windows Routing and Remote Access, the inner address for VPN clients comes from a pool configured separately from the server's LAN adapter, and the LAN side needs a route back to that pool. Two changes, not one, and they fail in different ways. Work through them in order so the address plan and the return path are proven before old ranges are retired.

Reserve the range before opening the console

Choose a prefix that does not overlap the LAN, other VPN ranges, or anything routed into the site. A /24 is a convenient size for a test, and the first usable portion can be handed to clients while the rest stays free for growth. Write it down with its purpose and owner before you type it into a console. Leave room at both ends of the block so a later split does not force a renumber.

An address plan that lives only in a console is one rebuild away from a collision. It also tends to grow: someone adds a second range later and nobody checks the first. Keep the plan next to the server documentation, not in a chat thread.

The server's LAN adapter does not define this pool. Changing the public listener or adding an adapter to the LAN does something else entirely. That is why clients can connect and still receive an address from the wrong place. The pool lives in the server's IPv4 properties, not in the adapter list.

Switching the method is not adding a range

RRAS has an assignment method and a set of ranges. Moving from DHCP to a static pool is a method change. Adding another block while the static pool is already active is a range change.

Preview both operations before running either, and read which one matches the server's current state:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

The second cmdlet fails or produces an unusable pool if the server is still on DHCP assignment. The first replaces the method rather than extending an existing pool. Neither preview applies anything, so run the one that matches, then confirm the resulting pool in the console. If you are unsure which state the server is in, read the assignment method on the IPv4 properties page and list the configured ranges:

Get-VpnIPAddressRange

A method of DHCP with an empty range list means the first preview applies. Static address pool with an existing range means the second does.

Account for the service restart the setting may require, and do not assume connected clients are renumbered immediately. A client that keeps its old address until it reconnects is behaving normally. Plan the change for a window where a reconnect is acceptable.

The LAN needs a route back

Suppose the LAN is 10.60.0.0/24 and the RRAS server is 10.60.0.10 on it. A host on that LAN replying to a client in 10.250.50.0/24 needs a path to the pool through the RRAS server. Without that path the request arrives and the reply dies.

If the host's default gateway is a different router, that router needs the return route for the VPN prefix. A static route on the RRAS server does not help here; the return path has to exist on the device that owns the LAN gateway, so add it to the routing table or to the dynamic routing process, whichever the site uses.

Check the host firewall and any network access rules against the new source range too. Rules written for the old client range reject the new one even though assignment succeeded. Client routes toward the LAN and DNS resolution are separate requirements, and both can fail while the tunnel looks healthy. Test each one on its own.

Prove the new pool on one device before retiring the old one

Take one authorization you control, reconnect, and read the pool address the client received. That single number separates allocation from routing. Then exercise a named application, watch the return traffic, and try a destination that should stay denied. Three observations, three different failure modes.

Name resolution deserves its own test: access by IP can work while the client's DNS still points at a resolver it cannot reach. A DNS server on the LAN is reachable only if the client has a route to it and the server accepts queries from the new range. Both are common misses when the pool moves.

Retire old ranges and their exceptions only after accounting for active sessions and the maintenance process. A connected client with a new address proves allocation, not the access policy. Keep the old range documented until the last session that used it has expired.

Check the result with three observations

Acceptance needs three facts: the client has an address from the new pool, a LAN host can reach it and get a reply, and a denied destination is still denied. Each has its own check, so a failure points at allocation, routing, or policy. Run them in that order.

From the client, confirm the address and the route to one LAN host:

ipconfig | findstr /i "IPv4"
route print -4

From the LAN host, confirm the reply path and the policy in one pass. If ping fails but the application works, the missing piece is likely an ICMP rule rather than the route. If both fail, read the route on the host before editing the VPN. Record the three results in the change ticket so the next person starts from evidence.