No Separate Credential Store
Your team uses the same credentials they use for everything else. No extra passwords, no separate VPN user accounts to provision or maintain.
PrivyNet's dedicated VPN infrastructure uses RADIUS authentication over IKEv2 - and it is pre-configured as part of every deployment. There is nothing to set up on your side. Your users authenticate through your existing identity infrastructure: Active Directory, FreeRADIUS, or any RADIUS-compatible identity provider, without any configuration work required from your team.
When a user connects to their PrivyNet node, the authentication request is forwarded to your RADIUS server, validated against your identity store, and the result returned - transparently, in seconds
RADIUS is already configured in PrivyNet's infrastructure. Your organisation only needs to point PrivyNet at your RADIUS server IP and provide the shared secret - there is no VPN-side configuration work required.
The operational impact of delegating authentication to your existing identity infrastructure
Your team uses the same credentials they use for everything else. No extra passwords, no separate VPN user accounts to provision or maintain.
Access rules, group policies, and account lockouts configured in your identity provider apply automatically to VPN access - no duplication required.
Disable a user in Active Directory and their VPN access is revoked at the next authentication attempt. No separate step needed in PrivyNet.
RADIUS is pre-configured in PrivyNet's infrastructure. Your IT team provides the RADIUS server details - PrivyNet handles the rest.
PrivyNet's RADIUS authentication is compatible with any standards-compliant RADIUS server or proxy. If your identity provider supports RADIUS or has a RADIUS agent, it will work with PrivyNet.
| Identity Infrastructure | How It Works With PrivyNet |
|---|---|
Windows Active Directory + NPS | NPS acts as the RADIUS server and validates credentials directly against Active Directory. The most common enterprise setup - no additional software required. |
FreeRADIUS | Open-source RADIUS server - configure as the RADIUS endpoint. Supports a wide range of back-end identity stores including LDAP and SQL. |
Cisco ISE | Enterprise-grade RADIUS server with native policy enforcement. Connects to PrivyNet as a standard RADIUS client - works as-is. |
Azure AD (via NPS Extension) | The NPS Extension for Azure AD bridges Azure AD (including MFA) to RADIUS. Supports Azure AD Conditional Access policies on VPN connections. |
Okta (via RADIUS Agent) | The Okta RADIUS Agent exposes Okta as a RADIUS endpoint. Supports Okta MFA flows for VPN authentication. |
Google Workspace (via proxy) | Use a RADIUS proxy that supports Google Workspace authentication. Any RADIUS-compatible proxy that bridges to your identity provider will work. |
Three values. That is all your IT team needs to provide. PrivyNet handles everything else.
Provide the IP address or hostname of your RADIUS server. This is the only endpoint PrivyNet needs to forward authentication requests.
Provide the shared secret that authenticates the RADIUS client (the PrivyNet node) to your RADIUS server. This is a standard RADIUS configuration value.
Confirm that UDP port 1812 is open from the PrivyNet VPN node's static IP to your RADIUS server. If you use RADIUS accounting, also open UDP 1813.
PrivyNet handles the RADIUS client configuration on the VPN node - it is pre-built into the infrastructure. If your RADIUS server also supports accounting (UDP 1813), session data can be fed directly into your existing log aggregation.
Common questions about RADIUS authentication on PrivyNet
Yes. PrivyNet's dedicated VPN infrastructure uses RADIUS authentication over IKEv2. It is pre-configured as part of every deployment - your team provides the RADIUS server details and PrivyNet handles the rest.
No. RADIUS authentication is pre-configured in PrivyNet's infrastructure. You provide your RADIUS server IP address and shared secret - there is no VPN-side configuration required from your team.
PrivyNet works with any standards-compliant RADIUS server, including Windows NPS (for Active Directory), FreeRADIUS, Cisco ISE, and cloud identity providers that expose a RADIUS endpoint such as Okta (via RADIUS Agent) or Azure AD (via NPS Extension).
Yes. Because authentication is delegated to your RADIUS server and identity store, disabling a user in Active Directory prevents them from authenticating on their next VPN connection attempt. No separate step is required in PrivyNet.
UDP port 1812 must be open between the PrivyNet VPN node's static IP and your RADIUS server. If you are using RADIUS accounting, UDP port 1813 should also be open.
Yes. If your identity provider supports MFA through RADIUS - for example Azure AD via the NPS Extension, or Okta via the RADIUS Agent - your existing MFA policies will apply to VPN authentication automatically. No additional configuration is needed on the PrivyNet side.
RADIUS authentication is pre-configured in every PrivyNet deployment. Provide your RADIUS server details and your team is connected through your existing identity infrastructure - no VPN-side configuration required.