• Authentication Method—Determines how a user is identified before being allowed access to the network and network services. It controls access by requiring valid user credentials, which are typically a username and password. It may also include the certificate from the client. Supported authentication methods are AAA only, Client Certificate only, and AAA + Client Certificate.

  When you select the Authentication Method as:

  • AAA Only—If you select the Authentication Server as RADIUS, by default, the Authorization Server has the same value. Select the Accounting Server from the drop-down list. Whenever you select AD and LDAP from the Authentication Server drop-down list, you must select the Authorization Server and Accounting Server manually.

  • SAML—Each user is authenticated using the SAML single sign-on server. For more information, see Single Sign-On Authentication with SAML 2.0.

    Override Identity Provider Certificate—Select to override the primary identity provider certificate of the SAML provider with an IdP certificate specific to a connection profile or SAML application. Select the IdP certificate from the drop-down.

    Microsoft Azure can support multiple applications for the same entity ID. Each application (mapped to a different connection profile) requires a unique certificate. If you want to retain an existing entity ID for the single-sign-on object in current connection profile and use a different IdP certificate, you can select this option.

    This enables support for multiple SAML applications per Microsoft Azure SAML identity provider.

    The primary identity certificate is configured in the single sign-on server object.

    For information about configuring a single sign-on server object, see Add a Single Sign-on Server.

    Choose your SAML Login Experience to configure a browser for SAML web authentication:

    • VPN client embedded browser—Choose this option to use the browser embedded with the VPN client for web authentication. The authentication applies to the VPN connection only.

    • Default OS Browser—Choose this option to configure the operating system that default or native browser that supports WebAuthN (FIDO2 standard for web authentication). This option enables single sign-on(SSO) support for web authentication methods such as biometric authentication.

      The default browser requires an external browser package for web authentication. The package Default-External-Browser-Package is configured by default. You can change the default external browser package by editing a remote access VPN policy and selecting the file under Advanced > Secure Client Images > Package File.

      You can also add a new package file by selecting. Objects > Object Management > VPN > Secure Client File > Add Secure Client File.

  • Client Certificate Only—Each user is authenticated with a client certificate. The client certificate must be configured on VPN client endpoints. By default, the user name is derived from the client certificate fields CN and OU. If the user name is specified in other fields in the client certificate, use 'Primary' and 'Secondary' field to map appropriate fields.

    Select Enable multiple certificate authentication to authenticate the VPN client using the machine and user certificates.

    If have enabled multiple certificate authentication, you can select one of the following certificates to map the username and authenticate the VPN user:

    • First Certificate—Select this option to map the username from the machine certificate sent from the VPN client.

    • Second Certificate—Select this option to map the username from the user certificate sent from the client.

    Note	If you do not enable multiple certificate authentication, the user certificate (second certificate) is used for authentication by default.

    If you select the Map specific field option, which includes the username from the client certificate, the Primary and Secondary fields display default values: CN (Common Name) and OU (Organisational Unit) respectively. If you select the Use entire DN as username option, the system automatically retrieves the user identity. A distinguished name (DN) is a unique identification, made up of individual fields used as the identifier when matching users to a connection profile. DN rules are used for enhanced certificate authentication.

    The primary and Secondary fields pertaining to the Map specific field option contain these common values:

    • C (Country)

    • CN (Common Name)

    • DNQ (DN Qualifier)

    • EA (Email Address)

    • GENQ (Generational Qualifier)

    • GN (Given Name)

    • I (Initial)

    • L (Locality)

    • N (Name)

    • O (Organisation)

    • OU (Organisational Unit)

    • SER (Serial Number)

    • SN (Surname)

    • SP (State Province)

    • T (Title)

    • UID (User ID)

    • UPN (User Principal Name)

  • Client Certificate & AAA— Each user is authenticated with both a client certificate and AAA server. Select the required certificate and AAA configurations for authentication.

    Whichever authentication method you choose, select or deselect Allow connection only if user exists in authorization database.

  • Client Certificate & SAML— Each user is authenticated with both a client certificate and SAML server. Select the required certificate and SAML configurations for authentication.

    • Allow connection only if username from certificate and SAML are the same—Select to allow VPN connection only if the username from the certificate matches the SAML single sign-on username.

    • Use username from client certificate for Authorization—When you choose the option to pick username from client certificate for authorization, you must configure the fields to pick from the client certificate.

      You can choose to map a specific filed as the username or use the entire distinguished name (DN) for authorization:

      • Map specific field— Select to include the username from the client certificate; the Primary and Secondary fields display default values: CN (Common Name) and OU (Organisational Unit) respectively.

      • Use entire DN as username— The system automatically retrieves the user identity for authorization.

    You can also create a Dynamic Access Policy (DAP) to match user-specific SAML assertion attributes or username to DAP certificate attributes. See Configure AAA Criteria Settings for DAP.

• Authentication Server—Authentication is the way a user is identified before being allowed access to the network and network services. Authentication requires valid user credentials, a certificate, or both. You can use authentication alone, or with authorization and accounting.

  Select an authentication server from the list if you have added a server already or else create an authentication server:

  • LOCAL—Use a local database from the threat defense for user authentication.

    • Local Realm—Select a local realm or click Add to configure a realm. See Create an LDAP Realm or an Active Directory Realm and Realm Directory.

  • Realm—Configure an LDAP or AD realm. See Create an LDAP Realm or an Active Directory Realm and Realm Directory.

  • RADIUS Server Group—Add a RADIUS server group object with RADIUS servers. See Add a RADIUS Server Group.

  • Single Sign-On Server—Create a single sign-on server object for SAML authentication. See Add a Single Sign-on Server.

Fallback to LOCAL Authentication— The user is authenticated using the local database and the VPN tunnel can be established even if the AAA server group is unavailable, provided that the local database is configured.

• Use secondary authentication — Secondary authentication is configured in addition to primary authentication to provide additional security for VPN sessions. Secondary authentication is applicable only to AAA only and Client Certificate & AAA authentication methods.

  Secondary authentication is an optional feature that requires a VPN user to enter two sets of username and password on the Secure Client login screen. You can also configure to pre-fill the secondary username from the authentication server or client certificate. Remote access VPN authentication is granted only if both primary and secondary authentications are successful. VPN authentication is denied if any one of the authentication servers is not reachable or one authentication fails.

  You must configure a secondary authentication server group (AAA server) for the second username and password before configuring secondary authentication. For example, you can set the primary authentication server to an LDAP or Active Directory realm and the secondary authentication to a RADIUS server.

  Note	By default, secondary authentication is not required.

  Authentication Server— Secondary authentication server to provide secondary username and password for VPN users.

  • Fallback to LOCAL Authentication— This user is authenticated using the local database and the VPN tunnel can be established even if the AAA server group is unavailable, provided that the local database is configured.

  Select the following under Username for secondary authentication:

  • Prompt: Prompts the users to enter the username and password while logging on to VPN gateway.

  • Use primary authentication username: The username is taken from the primary authentication server for both primary and secondary authentication; you must enter two passwords.

  • Map username from client certificate: Prefills the secondary username from the client certificate.

    If you have enabled multiple certificate authentication, you can select one of the following certificates:

    • First Certificate— Select this option to map the username from the machine certificate sent from the VPN client.

    • Second Certificate— Select this option to map the username from the user certificate sent from the client.

    • If you select Map specific field option, which includes the username from the client certificate. The Primary and Secondary fields display default values: CN (Common Name) and OU (Organisational Unit) respectively. If you select the Use entire DN (Distinguished Name) as username option, the system automatically retrieves the user identity.

      See Authentication Method descriptions for more information about primary and secondary field mapping.

    • Prefill username from certificate on user login window: Prefills the secondary username from the client certificate when the user connects via Secure Client.

      • Hide username in login window: The secondary username is pre-filled from the client certificate, but hidden to the user so that the user does not modify the pre-filled username.

  • Use secondary username for VPN session: The secondary username is used for reporting user activity during a VPN session.

• Authorization Server—After authentication is complete, authorization controls the services and commands available to each authenticated user. Authorization works by assembling a set of attributes that describe what the user is authorized to perform, their actual capabilities, and restrictions. When you do not use authorization, authentication alone provides the same access to all authenticated users. Authorization requires authentication.

  To know more about how remote access VPN authorization works, see Understanding Policy Enforcement of Permissions and Attributes.

  When a RADIUS Server is configured for user authorization in the connection profile, the remote access VPN system administrator can configure multiple authorization attributes for users or user-groups. The authorization attributes that are configured on the RADIUS server can be specific for a user or a user-group. Once users are authenticated, these specific authorization attributes are pushed to the threat defense device.

  Note	The AAA server attributes obtained from the authorization server override the attribute values that may have been previously configured on the group policy or the connection profile.

• Check Allow connection only if user exists in authorization database if desired.

  When enabled, the system checks the username of the client must exist in the authorization database to allow a successful connection. If the username does not exist in the authorization database, then the connection is denied.

• When you select a realm as the Authorization Server, you must configure an LDAP attribute map. You can choose a single server for authentication and authorization or a different servers. Click Configure LDAP Attribute Map to add LDAP attribute maps for authorization.

  Note

  Threat Defense does not support SAML Identity Provider as the Authorization server. If the Active Directory behind the SAML Identity Provider is reachable via management center and threat defense, you can configure authorization following these steps: Add realm for the AD Server. See Create an LDAP Realm or an Active Directory Realm and Realm Directory. Select the realm object as the Authorization Server in remote access VPN connection profile. Configure LDAP attribute map for the selected realm.

  For information about configuring LDAP attribute maps, see Configuring LDAP Attribute Mapping.

• Accounting Server—Accounting is used to track the services that users are accessing and the amount of network resources they are consuming. When AAA accounting is activated, the network access server reports user activity to the RADIUS server. Accounting information includes when sessions start and stop, usernames, the number of bytes that pass through the device for each session, the services used, and the duration of each session. This data can then be analyzed for network management, client billing, or auditing. You can use accounting alone or together with authentication and authorization.

  Specify the RADIUS Server Group object that will be used to account for the remote access VPN session.

• Strip Realm from username—Select to remove the realm from the username before passing the username on to the AAA server. For example, if you select this option and provide domain\username, the domain is stripped off from the username and sent to AAA server for authentication. By default this option is unchecked.

• Strip Group from username—Select to remove the group name from the username before passing the username on to the AAA server. By default this option is unchecked.

  Note	A realm is an administrative domain. Enabling these options allows the authentication to be based on the username alone. You can enable any combination of these options. However, you must select both check boxes if your server cannot parse delimiters.

• Password Management—Enable managing the password for the remote access VPN users. Select to notify ahead of the password expiry or on the day the password expires.

The Client Services Server provides HTTPS (SSL) access to allow the Secure Client Downloader to receive software upgrades, profiles, localization and customization files, CSD, SCEP, and other file downloads required by the client. If you select this option, specify the client services port number. If you do not enable the Client Services Server, users will not be able to download any of these files that the Secure Client might need.

Use Perfect Forward Secrecy (PFS) to generate and use a unique session key for each encrypted exchange. The unique session key protects the exchange from subsequent decryption, even if the entire exchange was recorded and the attacker has obtained the preshared or private keys used by the endpoint devices. If you select this option, also select the Diffie-Hellman key derivation algorithm to use when generating the PFS session key in the Modulus Group list.

Modulus group is the Diffie-Hellman group to use for deriving a shared secret between the two IPsec peers without transmitting it to each other. A larger modulus provides higher security but requires more processing time. The two peers must have a matching modulus group. Select the modulus group that you want to allow in the remote access VPN configuration:

• 1—Diffie-Hellman Group 1 (768-bit modulus).

• 2—Diffie-Hellman Group 2 (1024-bit modulus).

• 5—Diffie-Hellman Group 5 (1536-bit modulus, considered good protection for 128-bit keys, but group 14 is better). If you are using AES encryption, use this group (or higher).

• 14—Diffie-Hellman Group 14 (2048-bit modulus, considered good protection for 128-bit keys).

• 19—Diffie-Hellman Group 19 (256-bit elliptical curve field size).

• 20—Diffie-Hellman Group 20 (384-bit elliptical curve field size).

• 21—Diffie-Hellman Group 21 (521-bit elliptical curve field size).

• 24—Diffie-Hellman Group 24 (2048-bit modulus and 256-bit prime order subgroup).

The lifetime of the security association (SA), in seconds. When the lifetime is exceeded, the SA expires and must be renegotiated between the two peers. Generally, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes.

You can specify a value from 120 to 2147483647 seconds. The default is 28800 seconds.

The volume of traffic (in kilobytes) that can pass between IPsec peers using a given security association before it expires.

You can specify a value from 10 to 2147483647 kbytes. The default is 4,608,000 kilobytes. No specification allows infinite data.

• Validate incoming ICMP error messages—Choose whether to validate ICMP error messages received through an IPsec tunnel and destined for an interior host on the private network.

• Enable 'Do Not Fragment' Policy—Define how the IPsec subsystem handles large packets that have the do-not-fragment (DF) bit set in the IP header, and select one of the following from the Policy list:

  • Copy—Maintains the DF bit.

  • Clear—Ignores the DF bit.

  • Set—Sets and uses the DF bit.

• Select Enable Traffic Flow Confidentiality (TFC) Packets— Enable dummy TFC packets that mask the traffic profile which traverses the tunnel. Use the Burst, Payload Size, and Timeout parameters to generate random length packets at random intervals across the specified SA.

  Note	Enabling traffic flow confidentiality (TFC) packets prevents the VPN tunnel from being idle. Thus the VPN idle timeout configured in the group policy does not work as expected when you enable the TFC packets. See Group Policy Advanced Options.

  • Burst—Specify a value from 1 to 16 bytes.

  • Payload Size—Specify a value from 64 to 1024 bytes.

  • Timeout—Specify a value from 10 to 60 seconds.

• Identity Sent to Peers—Choose the identity that the peers will use to identify themselves during IKE negotiations:

  • Auto—Determines the IKE negotiation by connection type: IP address for preshared key, or Cert DN for certificate authentication (not supported).

  • IP address—Uses the IP addresses of the hosts exchanging ISAKMP identity information.

  • Hostname—Uses the fully qualified domain name (FQDN) of the hosts exchanging ISAKMP identity information. This name comprises the hostname and the domain name.

• Enable Notification on Tunnel Disconnect—Allows an administrator to enable or disable the sending of an IKE notification to the peer when an inbound packet that is received on an SA does not match the traffic selectors for that SA. Sending this notification is disabled by default.

• Do not allow device reboot until all sessions are terminated—Check to enable waiting for all active sessions to voluntarily terminate before the system reboots. This is disabled by default.

• Cookie Challenge—Whether to send cookie challenges to peer devices in response to SA initiated packets, which can help thwart denial of service (DoS) attacks. The default is to use cookie challenges when 50% of the available SAs are in negotiation. Select one of these options:

  • Custom—Specify Threshold to Challenge Incoming Cookies, the percentage of the total allowed SAs that are in-negotiation. This triggers cookie challenges for any future SA negotiations. The range is zero to 100%. The default is 50%.

  • Always— Select to send cookie challenges to peer devices always.

  • Never— Select to never send cookie challenges to peer devices.

• Number of SAs Allowed in Negotiation—Limits the maximum number of SAs that can be in negotiation at any time. If used with Cookie Challenge, configure the cookie challenge threshold lower than this limit for an effective cross-check. The default is 100 %.

• Maximum number of SAs Allowed—Limits the number of allowed IKEv2 connections.

• Enable Fragmentation Before Encryption—This option lets traffic travel across NAT devices that do not support IP fragmentation. It does not impede the operation of NAT devices that do support IP fragmentation.

• Path Maximum Transmission Unit Aging—Check to enable PMTU (Path Maximum Transmission Unit) Aging, the interval to Reset PMTU of an SA (Security Association).

• Value Reset Interval—Enter the number of minutes at which the PMTU value of an SA (Security Association) is reset to its original value. Valid range is 10 to 30 minutes, default is unlimited.

• Keepalive Messages Traversal—Select whether to enable NAT keepalive message traversal. NAT traversal keepalive is used for the transmission of keepalive messages when there is a device (middle device) located between a VPN-connected hub and spoke, and that device performs NAT on the IPsec flow. If you select this option, configure the interval, in seconds, between the keepalive signals sent between the spoke and the middle device to indicate that the session is active. The value can be from 10 to 3600 seconds. The default is 20 seconds.

• Interval—Sets the NAT keepalive interval, from 10 to 3600 seconds. The default is 20 seconds.