Preventing accidental RADIUS public access via NPS interface binding or Connection Request Policy source IP filtering

Question

An administrator seeks to prevent RADIUS authentication requests from traversing public network segments while maintaining uninterrupted service for legitimate internal clients such as VPN relays and DHCP agents.

The documented NPS hardening options for this constraint include binding the RADIUS listener to specific internal IP addresses or relying on Connection Request Policies that evaluate the client's source IP address. Interface binding enforces network‑layer restriction but requires reconfiguration when subnet topology changes. Connection Request Policies provide software‑only flexibility but depend on correct policy ordering and explicit deny rules to avoid unauthorized bypass.

A documented uncertainty persists: when TLS is enabled for RADIUS, discarded connection requests are logged only at the Informational level, which may result in unauthorized attempts going unnoticed in large deployments.

How should an administrator weigh interface binding against Connection Request Policies when network topology is subject to frequent changes?
What logging configuration ensures discarded TLS‑protected RADIUS requests are captured at a severity level sufficient for security monitoring?
Can Connection Request Policies be reliably ordered to explicitly deny unauthorized source IPs without disrupting legitimate relay traffic?

Tasadduq Burney · Answer

Answer firstUse interface binding as a hard network-layer fail-safe and use Connection Request Policies for flexible source-IP allow/deny. In a topology that changes frequently, keep binding on the stable internal NIC and manage relay IPs with CRPs ordered Allow-specific → Deny-all. For RadSec, discarded requests are typically logged at Informational; raise NPS audit verbosity and monitor Event IDs for discarded requests in your SIEM. CRPs can reliably deny unauthorized sources without breaking legitimate relay traffic if specific Allow policies for known VPN/DHCP relays are placed above a catch-all Deny.Confirmed facts vs likely explanationConfirmed: NPS listeners can be bound to specific IP addresses, which prevents the service from accepting packets on unintended interfaces. CRP evaluation is top-down; the first matching policy is applied. Legitimate relay traffic is preserved by placing specific Allow policies for known relay IPs above general restrictive policies.Likely: RADIUS over TLS/RadSec changes logging behavior compared to UDP RADIUS and often requires higher verbosity to surface discarded packets. Discarded TLS-protected requests may appear only at Informational level in default configurations.Weighing interface binding vs CRP with frequent topology changesInterface binding provides a hard barrier, no packets reach NPS on unbound interfaces. It is rigid; IP or NIC changes require listener reconfiguration and service impact.CRP source-IP filtering is software-only and can be updated without restarting the listener, suitable for changing subnets.Recommendation for frequent changes: bind to the internal NIC(s) that should never be public, and use CRPs for dynamic relay allow-listing. Do not rely on CRP alone.Reliable CRP ordering for deny without disrupting relaysCreate specific Allow policies for each VPN relay and DHCP agent source IP / subnet, with NAS Port Type and other conditions as needed, and place them at the top.Add a final Deny or Discard policy with a broad match for all other sources, placed at the bottom.Ensure no broad Allow policy precedes the Deny.This whitelist-first order prevents fail-open.Logging discarded TLS-protected RADIUS requestsEnable full NPS auditing via Local Security Policy or Group Policy.Collect Network Policy Server operational events and monitor for discarded request events. With RadSec, ensure the SIEM ingests Informational level events, not only Warning/Error.Correlate with packet captures to confirm drops.Verification stepsnetstat -ano | findstr :1812Verify listening addresses are internal only. Perform a test from an unauthorized IP and confirm no response. Review Event Viewer for discarded request events at the configured severity.One missing diagnostic detail that changes the recommendation: Is RADIUS traffic fronted by a load balancer or NAT device? If yes, the source IP seen by NPS/CRP will be the balancer’s IP, requiring policy conditions on Calling-Station-ID or RADIUS attributes instead of raw source IP.

Preventing accidental RADIUS public access via NPS interface binding or Connection Request Policy source IP filtering

1 answer

Answer first

Confirmed facts vs likely explanation

Weighing interface binding vs CRP with frequent topology changes

Reliable CRP ordering for deny without disrupting relays

Logging discarded TLS-protected RADIUS requests

Verification steps

Your perspective belongs here.

1 question comment