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

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?