Which Address Do You Register as the NPS RADIUS Client?

A VPN gateway that hands authentication to Windows NPS needs one object on the NPS side before any user policy can run: a RADIUS client entry for the gateway. Most failed attempts register the wrong address, because the address that matters is the one the gateway uses on its backend path, not the hostname staff type into their VPN app. Get that value wrong and NPS silently discards the request, which looks like a bad password from the client side. Three conditions decide which address belongs in the field, so work them out before opening the console.

Register the gateway, not the laptops or the pool

The RADIUS client object represents the network access device that sends authentication requests. That is the VPN gateway, not every laptop running the client, and not the range of addresses handed out inside tunnels.

Those tunnel addresses never appear as the source of a RADIUS request, because the request travels over the gateway's own network path. Registering a client pool entry produces a policy that can never match, while the real request arrives from an address NPS has never heard of. The same confusion leads people to add each employee's home IP, which is both unmaintainable and wrong.

Three conditions decide the address you enter

First, find the source address the gateway actually uses toward NPS. A multi-interface gateway often sends from a management or backend interface rather than its public VPN listener. Second, check for NAT between the two: if the request is translated, NPS sees the translated address, and that is the value to register. Third, if two gateways share the role, each request source needs its own client entry, because a single object with one address covers only one of them.

A two-ended record keeps the pair straight. The table below uses private addresses for illustration, so substitute the ones your path actually uses.

Confirm the source rather than guessing it. Watch the NPS or firewall log during one attempt, or capture on the NPS host with sudo tcpdump -ni any udp port 1812. The address in that capture is the only defensible answer for the client entry. If the gateway has several possible sources, register each one under its own friendly name.

The shared secret is a gateway-to-NPS value

The shared secret authenticates the device relationship. It is not a user password and it is never distributed to staff or embedded in client profiles.

Choose one value, enter it in both places, and store it where the gateway's configuration backup lives. A mismatch produces a request that NPS drops without a useful error, which is indistinguishable from an unreachable server in the gateway's log. Rotate it during a maintenance window and update both ends in the same change.

Confirm with one permitted request

Use a controlled account and correlate a single attempt on both sides. At the gateway, confirm the request left toward the intended server; at NPS, confirm it arrived from the registered client and matched the expected connection request policy. A timeout and a rejection mean different things, and treating both as a credential problem wastes the next hour. Then test a valid but ineligible account and a wrong password, because a policy that accepts everything passes the first test too.

Finally, check what the gateway does with the returned authorization. Registering a RADIUS client only permits the device to participate; it does not grant every resulting session access to the LAN.

Keep diagnostic output scoped: no shared secrets, no user passwords, no full packet payloads in a support ticket. If the design calls for the NPS server to read directory attributes, that permission is a separate administrative task from the client registration, and it fails in a different way when it is missing.