NPS Group Policy Is Not VPN Resource Enforcement

Two groups, two access profiles, one VPN gateway, and both groups end up reaching the same servers. The usual reason is not a broken policy but a missing second half of the design: NPS decides who may establish a session, and something else has to decide what that session may reach. When only the first half exists, authorization succeeds for everyone who authenticates. The policy is doing its job and the design is still incomplete.

A group-matched network policy is evidence about admission. It is not evidence about packets, and the gap between those two statements is where most of this work happens.

Find the policy that actually admitted the session

NPS evaluates ordered network policies, and the first enabled rule whose conditions match wins. Conditions can include user or computer group membership, connection type, time and device state. A broad policy placed earlier in the list therefore admits a connection before a narrower rule further down is ever considered. Ordering is not a detail of the interface; it is the policy.

Read the list in order and identify the one that matched, then note which settings it returned. The editor's group name is not the result; the result is the authorization the server received. Keep user authorization and device authorization separate where the deployment uses both, because an account that may open a tunnel is not automatically an account that should reach every internal service.

The RADIUS reply is an instruction, not a filter

A Filter-Id attribute carries the name of a filter list. It does not ship a portable set of packet-filter rules that every receiver understands, and sending a name the gateway has never defined enforces nothing at all. The same caution applies to VLAN attributes: assigning a tunnel session to a VLAN is not, by itself, a routed access rule for that user.

This is where a design that looks complete on the NPS side quietly does nothing. Confirm with the gateway vendor's documentation which authorization attributes are supported and what the receiver does with each one, rather than assuming that a standard attribute name implies standard behaviour.

Put enforcement where the traffic passes

A gateway that processes the user's packets can apply a per-session filter, map a group to a gateway policy, or hand the session an address from a segregated pool that a firewall treats differently. Any of those can work, and they fail in different ways. Identify which mechanism your gateway supports before writing the policy that names it. Then write down what happens to a session when that mechanism is absent, because silence is the default.

Describe the intended permission in four parts: source identity or group, destination, protocol and port. Add the dependencies the user genuinely needs, such as DNS or an authentication service, or the restriction will break login flows that nobody thought to test. Write the rule against the interface that actually filters, not against the interface that happens to be open in the editor.

Account for translation as well. If a downstream firewall sees one translated source address for every tunnel user, it cannot distinguish individuals from that address alone, and a rule written as if it could will be either useless or over-broad.

Client profiles live on the untrusted side

A managed VPN profile can push routes, split-tunnel rules or application filters, and those shape how a well-behaved device behaves. They are not protection for the service, because the client is the party you are trying to constrain. Removing a route in a profile is not authorization either, since a client may have another path to the same destination.

Treat client settings as convenience and gateway settings as control. When the two disagree, the gateway is right because it is the one that sees the packets.

Accept with two accounts, then trace in order

Create two ordinary test accounts with different intended permissions, establish fresh sessions, and check the effective gateway policy for each. Then test one harmless allowed operation and one specifically denied resource. A failed ping proves very little on its own, since ICMP may be filtered while the TCP service behind it answers happily.

When both accounts still get broad access, trace in a fixed order: which policy matched, what authorization the reply carried, and what the gateway did with it. Adding more NPS attributes before confirming the receiver implements them is how a small authorization problem turns into a change window with no result.