Policy-Based VPN Creation Using Remote Access Server Users Overview
For VPNs that support RAS users, you must create a user object to represent each user. NSM supports two types of users:
Local Users—A local user has an account on the security device that guards the protected resources in the VPN. When a local user attempts to connect to a protected resource, the security device authenticates the user.
External Users—An external user has an account on RADIUS or SecureID authentication server. When an external user attempts to connect to a protected resource, the security device forwards the request to the authentication server for authentication.
The topic includes:
Authenticating RAS Users
You can authenticate or encrypt a RAS user using one or more of the following protocols. Table 1 describes the various protocols:
Table 1: Authenticating RAS Users
Uses IPsec ESP and a username and password for authentication. XAuth RAS users must authenticate with a username and password when they connect to the VPN tunnel.
Uses IPsec ESP and AH for encryption and authentication. AutoKey IKE users have a unique IKE ID that NSM uses to identify and authenticate the user during IKE Phase I negotiations. To simplify RAS management for large numbers of AutoKey IKE users, you can also create AutoKey IKE groups that use a shared group IKE ID.
Uses Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) for authentication (password sent in the clear).
Manual Key IKE
Uses IPsec ESP and AH for encryption and authentication. Because manual key users are device-specific, you create them in the security device configuration, not in the Object Manager. For details on creating manual key users, see L2TP and Xauth Local Users Configuration Overview.
We strongly recommend that you do not use null AH with ESP.
NSM allows certificate with DC in certificate DN to be used for dial-up user IKE ID selection.
When you use certificate DN as dialup user IKE ID, the following takes place:
On the device sever, a partial or whole DN is associated with a VPN configuration.
On the client side, the certificate DN is sent as IKE ID for the server to match the VPN configuration based on the content of DN.
The server DN configuration can contain a container part and a wildcard part as follows:
The container part contains a continuous section of the D; for example, “ OU=a,O=b” . Any DN containing all specified elements in correct order are accepted.
Up to seven wildcards can be specified, one for each of the following elements: CN, OU, O, L, ST, C, E-mail.
NSM needs to support DC container type when using ASN1-DN to create IKE ID or a group of IKE ID that enables multiple, concurrent connections to the same VPN tunnel. During Phase 1 negotiations, IKE first attempts to make an exact match between the RAS IKE ID and peer gateway IKE ID.
If no match is found, IKE then attempts to make a partial match between the RAS IKE ID and group IKE ID. When selecting this type, you must enter a container identity or a wildcard ID (CN, OU, O, L, ST, C, Email).
NSM devices authenticate a RAS IKE user's ID if the values in the RAS IKE user's ASN-1DN identity fields exactly match the values in the group IKE user's ASN1-DN identity fields. The container ID type supports multiple entries for each identity field (for example, "ou=eng,ou=sw,ou=screenos"). The ordering of the values in the identity fields of the two ASN1-DN strings must be identical. In this IKE ID matching part, we need to allow DC element to be matched.
NSM also supports DC in wildcard when using ASN1-DN to create IKE ID or a group of wildcard ID. NSM devices authenticate a RAS IKE user's ID if the values in the RAS IKE user's ASN1-DN identity fields match those in the group IKE user's ASN1-DN identity fields. The wildcard ID supports only one value per identity field (for example, "ou=eng" or "ou=sw", but not "ou=eng, ou=sw"). The ordering of the identity fields in the two ASN1-DN strings are inconsequential. In this IKE ID matching part, we need to support DC as a wildcard element.
Configuring Group IKE IDS
If your VPN includes multiple remote users, it can be impractical to create an IKE ID and VPN rule for each. Instead, you can use a group IKE ID to authenticate multiple users in a single VPN rule. In the security device configuration VPN settings, create a VPN group and specify the maximum number of concurrent connections that the group supports (cannot exceed the maximum number of allowed Phase 1 SAs or the maximum number of VPN tunnels allowed on the Juniper Networks security device platform).
For details on group IKE IDs, see the ScreenOS 5.x Concepts and Examples Guide.