VPN Settings

VPN (Description)

VPN (Virtual Private Network) is a generic name for technologies that make it possible to create logical networks (tunnels) on top of public networks to provide communications security.

To create a VPN, at least two network devices are needed that can identify each other and encrypt the data flow between them.

Types of VPN Connection

In UserGate NGFW, you can create the following types of VPN connections:

• Site-to-Site VPN connections. In this case, one host works as a VPN server and another as a VPN client. This kind of server-to-server connection allows you to consolidate corporate offices into a single logical network.

• Remote Access VPN. In this case, NGFW UserGate works as a VPN server and user devices as VPN clients. UserGate Client can be used as the VPN client software on user devices. Standard VPN clients for most of the popular operating systems like Windows, Linux, Mac OS X, iOS, Android and others are also supported.

Secure VPN Tunneling Options

Secure VPN tunnels can be created using L2TP/IPsec(IKEv1), IKEv2/IPsec, and GRE/IPsec protocols.

L2TP/IPsec VPN

With an L2TP/IPsec VPN, a tunnel is created using L2TP (RFC 3931) protocol where network-layer packets are transmitted inside PPP frames. Since L2TP itself does not provide strict authentication, confidentiality, and integrity of the data being transmitted, the IPsec (RFC 6071) group of protocols is used for those purposes.

The L2TP tunnel is created inside a secure IPsec link, and to establish it, you first need to create a secure IPsec connection between the hosts. In this case, IPsec works as a transport and uses ESP (Encapsulating Security Payload) to encrypt L2TP packets.

VPN has two encapsulation levels: internal L2TP encapsulation and external IPsec encapsulation. The internal level has L2TP and UDP headers in addition to the PPP frame. The external level adds an IPsec ESP header and trailer. An IPsec Auth trailer provides message integrity check and authentication.

The process of creating a VPN comprises these main steps:

1. Establish a secure data link

2. Establish a VPN tunnel.

Secure data link establishment

To establish a secure data link, the IPsec group of protocols is used.

IPsec has three underlying protocols:

• Authentication Header (AH)

• Encapsulating security payload (ESP)

• Internet Key Exchange (IKE).

Authentication Header (AH) ensures the integrity of the transmitted data, authentication of the data source, and protection from retransmission. AH does not provide confidentiality for the data in transit because it does not perform encryption. The IP protocol number for AH is 51.

Encapsulating security payload (ESP) uses encryption to ensure the confidentiality of the transmitted data and also supports data integrity and data source authentication. The IP protocol number for ESP is 50.

Internet Key Exchange (IKE) is a service data exchange protocol for negotiating an establishing a security association (SA). A security association includes a set of secure connection parameters that can be used by both sides of the connection for mutual authentication and the encryption of transmitted data. IKE uses the UDP port 500.

The IPsec has two modes of operation:

• Tunnel mode

• Transport mode.

In the tunnel mode, IPsec encrypts the entire original IP packet along with its header. Then it is encapsulated inside an additional packet that has its own header. The tunnel mode is used when two private networks transmit data via an insecure public network.

In the transport mode, only the payload of the IP packet is encrypted, and the original IP header is kept with some extra information added to it. The transport mode is used when the two hosts already have an IP connection, but that connection does not provide security for the transmitted data.

When a VPN is created using L2TP/IPsec, the tunnel between the two hosts is created using the L2TP protocol, and IPsecis to provide security for the data link. In this case, IPsec operates in the transport mode, and the negotiation of the security association and establishment of the secure link is done using the IKE protocol (IKEv1) in two phases.

In phase 1, the neighboring hosts are mutually authenticated, an IKE SA is negotiated, and a secure service link is established between the hosts for IKE data exchange.

The negotiated parameters of an IKE SA are:

• Hash algorithms (MD5, SHA)

• Encryption algorithms (DES, 3DES, AES)

• Tunnel lifetime parameters

• Diffie-Hellman groups.

Pre-shared keys are used for authenticating the link peers.

IKEv1 phase 1 negotiation can be carried out in two modes:

• Main

• Aggressive

In the main mode, the devices exchange six messages. During the first exchange (messages 1 and 2), the encryption and authentication algorithms are negotiated for IKE SA. The second exchange (messages 3 and 4) implements the Diffie-Hellman (DH) key exchange. After the second exchange, the IKE service on each device creates a master key to use for authentication. The third exchange (messages 5 and 6) authenticates the reporter and responder of the connection (identity checking) and the information is secured using the encryption algorithm established earlier.

In the aggressive mode, there are two message exchanges with three messages in total. In the first message, the reporter transmits information corresponding to messages 1 and 3 of the main mode --- that is, the information on encryption and authentication algorithms as well as the DH key. The second message, transmitted by the responder, contains information corresponding to messages 2 and 4 of the main mode and also authenticates the responder. The third message authenticates the reporter and confirms the exchange.

The fewer number of messages allows for a quicker connection establishment in the aggressive mode, but the peer IDs are exchanged in plain text. The main mode is considered more secure because it encrypts the ID data.

The result of phase 1 is a successfully negotiated bidirectional IKE SA and the establishment of a secure service link. This channel will be used in phase 2 for negotiating the IPsec SA parameters for the main data channel.

In phase2, the secure service link established earlier in phase1 is used to negotiate an IPsec SA for the secure transmission of data over the IPsec link.

IKEv1 has one mode in phase 2 called quick mode.

The negotiated parameters of an IPsec SA are:

• Encryption algorithms (DES, 3DES, AES)

• Hash algorithms (MD5, SHA-1, SHA-2)

• SA lifetime parameters.

Based on the IPsec SA negotiation results, a secure data link is created operating in the IPsec transport mode with ESP encapsulation that has two unidirectional SAs to both sides of the link.

After this mode is set, the service link established in phase 1 does not disappear and is used to update the SA for the main channel.

The IPsec SA is terminated when the VPN is disconnected on one side of the connection or upon a timeout. A timeout occurs when the key lifetime has elapsed or the link lifesize has been reached. When the SA is terminated, the keys are deleted. If additional IPsec SAs are required for data transmission, a new IKE negotiation phase follows.

VPN tunnel establishment

At this stage, an L2TP tunnel is negotiated and established between the SA endpoints. The actual parameter negotiation occurs over a secure IPsec SA link. The L2TP protocol uses UDP port 1701.

When the VPN has been established, L2TP packets flowing between the endpoints are encapsulated using IPsec. Since the L2TP packet itself is wrapped into an IPsec packet, the original source and destination IP addresses are encrypted inside the outer packet. In addition, there is no need to open UDP port 1701 on the firewall between the endpoints because the inner packets are not processed until the IPsec data have been decrypted, which only happens at the tunnel endpoints.

IKEv2/IPsec VPN

When a VPN is created using IKEv2/IPsec, a secure VPN tunnel is established only using the IPsec group of protocols together with IKEv2(RFC 7296, RFC 7427).

In this scenario, IPsec operates in the tunnel mode where the original IP packets are fully encapsulated and encrypted inside a new packet that has its own header and trailers.

Similar to IKEv1, IKEv2 also has a two-stage secure connection establishment process, but with fewer message exchanges.

The first stage is known as IKE_SA_INIT. In the two messages comprising an IKE_SA_INIT exchange between two neighboring hosts, IKE SA parameters are negotiated, and a secure service link is established. The negotiated parameters of an IKE SA are:

• Hash algorithms

• Encryption algorithms

• Diffie-Hellman key.

Every host generates a seed key (SKEYSEED) that is used afterwards to generate keys used in the IKE SA. All the subsequent IKE keys are generated using the SKEYSEED.

The second stage is called IKE_AUTH. At this stage, the neighboring hosts are authenticated. The two messages comprising an IKE_AUTH exchange are authenticated and encrypted in the context of the IKE SA created during the IKE_SA_INIT message exchange.

At the end of the second negotiation stage, a child security association (CHILD SA) is created under the IKE SA for secure data transmission. CHILD SA is an IKEv2 term that is similar to IPsec SA in IKEv1. IKEv2 uses UDP ports 500 and 4500 (IPsec NAT Traversal).

Additional CHILD SA can be created to establish a new tunnel. This message exchange is called CREATE_CHILD_SA and can be used to negotiate new Diffie-Hellman group values and encryption/hash algorithm combinations.

IPsec tunnel peer authentication can be done using certificates based on a Public Key Infrastructure (PKI) or using the Extensible Authentication Protocol (EAP).

GRE/IPsec VPN

GRE (RFC 2784) is a tunneling protocol that can encapsulate the packets of various types of protocols inside IP tunnels, creating a virtual point-to-point link over an IP network. GRE is used for managing the process of transmitting multiprotocol and multicast IP traffic between two or more sites that can only communicate using the IP protocol. Note that GRE does not provide confidentiality and integrity for the transmitted data. To that end, IPsec protocols are used together with GRE.

When GRE and IPsec are used together, two types of connection can be created: IPsec over GRE and GRE over IPsec.

In case of an IPsec over GRE connection, encrypted traffic is transmitted over an unencrypted GRE tunnel, meaning that GRE encapsulation follows IPsec encapsulation. A downside of IPsec over GRE is that multicast and broadcast packets are not supported.

GRE over IPsec connections allow you to combine the advantages of GRE (multicast and broadcast support) and IPsec (encrypted traffic transmission). A GRE over IPsec connection encapsulates the traffic packets in GRE and then transmits them over an encrypted link (IPsec encapsulation).

To configure GRE over IPSec, follow these steps:

Site-to-Site VPN Connections

A VPN connection that makes it possible to interconnect the local networks of remote offices is called a Site-to-Site VPN.

In this case, one firewall works as a VPN server and another as a VPN client. The client initiates a connection to the server. A Site-to-Site VPN can be created between two UserGate firewalls or between a UserGate firewall and a third-party device.

To create a Site-to-Site VPN, L2TP/IPsec(IKEv1) and IKEv2/IPsec protocols are used.

Configuring Site-to-Site VPN Using Admin Console

Creating a Site-to-Site VPN requires that the relevant settings be configured at both endpoints of the secure connection, i.e., the VPN server and VPN client.

VPN Server Host Configuration

VPN Client Host Configuration

When the VPN server and client have been configured, the client initiates a connection to the server, and if the settings are correct, a VPN tunnel is brought up. To bring down the tunnel, disable the VPN client rule (set on the client) or the VPN server rule (set on the server).

Configuring Site-to-Site VPN Using CLI

This example shows the creation of a Site-to-Site VPN using the L2TP/IPsec protocols.

VPN Server Host Configuration

Step 1. Create a local user for the authentication of the VPN client server.

Use the following command:

Admin@nodename# create users user <parameters>

To learn more about the commands and parameters for creating local users using the CLI, see the Configuring Users article.

Here is an example command that creates a user named VPN-client 1 with the login vpn_client1 and adds the user to the VPN servers group:

Admin@nodename# create users user name "VPN-client 1" login vpn_client1 groups [ "VPN servers" ] enabled on

Step 2. Allow the VPN service in the zone to which VPN clients will connect.

To edit the zone parameters, use the following command:

Admin@nodename# set network zone <parameters>

To learn more about the commands and parameters for creating and editing zones using the CLI, see the article Zones.

Here is an example command that edits the Untrusted zone to allow the VPN service inside it:

Admin@nodename# set network zone Untrusted enabled-services [ VPN ]

Step 3. Create a zone where the servers connecting using a VPN will be placed.

To create a zone, use the following command:

Admin@nodename# create network zone <parameters>

To learn more about the commands and parameters for creating and editing zones using the CLI, see the article Zones.

Here is an example command that creates a zone called S2S_VPN:

Admin@nodename# create network zone name S2S_VPN enabled-services [ VPN ]

Step 4. If required, create a firewall rule that allows traffic from the zone created earlier to the desired network segment.

Firewall rules are created using a command that employs the UPL syntax:

Admin@nodename# create network-policy firewall <position> upl-rule <commands>

For more details on how to configure firewall rules using the CLI, see the Configuring Firewall Rules article.

An example of creating firewall rules that allow traffic from the zone S2S_VPN to the zone Zone1 is shown below. To let the traffic pass to the client in Zone1 from the desired server zone via the VPN tunnel, you also need to create an allowing firewall rule, specifying the desired source and destination zones.

Admin@nodename# create network-policy firewall 1 upl-rule PASS \ ...src.zone = S2S_VPN \ ...dst.zone = Zone1 \ ...rule_log(session) \ ...name("S2S_VPN to Zone1") \ ...enabled(true) Admin@nodename# create network-policy firewall 2 upl-rule PASS \ ...src.zone = Zone1 \ ...dst.zone = S2S_VPN \ ...rule_log(session) \ ...name("Zone1 to S2S_VPN") \ ...enabled(true)

Step 5. Create an authentication profile for VPN users.

For more details on configuring authentication profiles using the CLI, see the Configuring Authentication Profiles article.

Here are example commands that create an LDAP authentication server named New ldap server for the domain testd.local and authentication profile named New profile:

Admin@nodename# create users auth-server ldap name "New ldap server" address 192.168.1.2 domains [ test.local ] bind-dn test@test.local password 12345 enabled on Admin@nodename# create users auth-profile name "New profile" auth-methods ldap [ "New ldap server" ]

Step 6. Create a VPN server security profile.

To create a VPN server security profile, use the following command:

Admin@nodename# create vpn server-security-profiles <parameters>

For more details on configuring VPN security profiles using the CLI, see the Configuring VPN Security Profiles article.

Here is an example command that creates a VPN server security profile named "New VPN-server profile" for a L2TP/IPsec VPN:

Admin@nodename# create vpn server-security-profiles name "New VPN-server profile" ike-version 1 ike-mode main psk 12345 dh-groups [ "Group 2 Prime 1024 bit" "Group 14 Prime 2048 bit" ] phase1-security [ SHA1/AES256 SHA256/AES256 ] phase2-security [ SHA1/AES256 SHA256/AES256 ] Repeat preshared key: Admin@nodename#

Step 7. Create a VPN interface.

To create a VPN interface, use the following command:

Admin@nodename# create network interface vpn <parameters>

For more details on how to create a VPN interface using the CLI, see the Interfaces article.

Here is an example command that creates a VPN interface named tunnel4 belonging to the zone S2S_VPN:

Admin@nodename# create network interface vpn interface-name 4 zone S2S_VPN ip-addresses [ 172.30.251.1/24 ] enabled on

Step 8. Create a VPN network.

To create a VPN network, use the following command:

Admin@nodename# create vpn networks <parameters>

For more details on how to create a VPN network using the CLI, see the Configuring VPN Networks article.

Here is an example command that creates a VPN network named "New VPN network":

Admin@nodename# create vpn networks name "New VPN network" ip-range 172.30.251.2-172.30.251.200 mask 255.255.255.0 use-system-dns on routes-ip-list [ "Int net address" ]

Step 9. Create a VPN server rule.

VPN server rules are created using a command that employs the UPL syntax:

Admin@nodename# create vpn server-rules <position> upl-rule <commands>

For more details on how to create VPN server rules using the CLI, see the Configuring Server Rules article.

Here is an example command that creates a VPN server rule named "New VPN-server rule" using the following previously defined items: VPN server security profile "New VPN-server profile", VPN network "New VPN network", user authentication profile "New profile", VPN interface tunnel4, and VPN server external IP address list "Ext VPN address":

Admin@nodename# create vpn server-rules 1 upl-rule OK \ ...name("New VPN-server rule") \ ...profile("New VPN-server profile") \ ...vpn_network("New VPN network") \ ...auth_profile("New profile") \ ...interface(tunnel4) \ ...src.zone = Untrusted ...dst.ip = lib.network("Ext VPN address") ...user = (vpn_client1) ...enabled(true)

VPN Client Host Configuration

Step 1. Create a zone where the interface used for VPN connections will be placed.

Here is an example command that creates a zone called S2S_VPN:

Admin@nodename# create network zone name S2S_VPN enabled-services [ VPN ]

Step 2. Create a firewall rule that allows traffic to the zone created earlier if it is required.

Here is an example of creating firewall rules for a zone named Zone2:

Admin@nodename# create network-policy firewall 1 upl-rule PASS \ ...src.zone = S2S_VPN \ ...dst.zone = Zone2 \ ...rule_log(session) \ ...name("S2S_VPN to Zone2") \ ...enabled(true) Admin@nodename# create network-policy firewall 2 upl-rule PASS \ ...src.zone = Zone2 \ ...dst.zone = S2S_VPN \ ...rule_log(session) \ ...name("Zone2 to S2S_VPN") \ ...enabled(true)

Step 3. Create a VPN client security profile.

To create a VPN client security profile, use the following command:

Admin@nodename# create vpn client-security-profiles <parameters>

For more details on configuring VPN security profiles using the CLI, see the Configuring VPN Security Profiles article.

Here is an example command that creates a VPN client security profile named "New VPN-client profile" for a L2TP/IPsec VPN:

Admin@nodename# create vpn client-security-profiles name "New VPN-client profile" protocol ipsec2 ike-mode main psk 12345 authentication-login vpn_client1 authentication-password 12345 dh-groups [ "Group 2 Prime 1024 bit" "Group 14 Prime 2048 bit" ] phase1-security [ SHA1/AES256 SHA256/AES256 ] phase2-security [ SHA1/AES256 SHA256/AES256 ] Repeat preshared key: Admin@nodename#

Step 4. Create a VPN interface.

Here is an example command that creates a VPN interface named tunnel5 belonging to the zone S2S_VPN:

Admin@nodename# create network interface vpn interface-name 5 zone S2S_VPN iface-mode dynamic enabled on

Step 5. Create a VPN client rule.

VPN client rules are created using a command that employs the UPL syntax:

Admin@nodename# create vpn client-rules <position> upl-rule <commands>

For more details on how to create VPN client rules using the CLI, see the Configuring Client Rules section.

Here is an example command that creates a VPN client rule named "New VPN-client rule" using the following previously defined items: VPN client security profile "New VPN-client profile", VPN interface tunnel5, and VPN server IP address 10.10.0.1:

Admin@nodename# create vpn client-rules 2 upl-rule OK \ ...name("New VPN-client rule") \ ...profile("New VPN-client profile") \ ...interface(tunnel5) \ ...server_address("10.10.0.1") \ ...enabled(true)

Remote Access VPN

A Remote Access VPN is a virtual private network with remote access that allows the users to access their corporate network. It implements secure communication between a segment in the corporate network and an individual user that connects to the corporate resources via Internet.

UserGate Client software provides secure remote access to the corporate network via a VPN link. It uses encryption and protects the data in transit between a remote device and the corporate infrastructure. Compatible with Windows operating system. User authentication can be implemented using a login and password, two-factor authentication (2FA), or certificates, which ensures that only authorized users will get access. UserGate Client is centrally managed from UGMC, allowing the administrators to configure access policies, define which resources will be available to users and user groups, and control access levels. For more details on UserGate Client, see the UserGate Client Endpoints section.

UserGate Client IPsec L2TP

In this case, NGFW acts as a VPN server, and the user with the UserGate Client software installed acts as a VPN client. When you create a VPN using L2TP/IPsec(IKEv1), L2TP creates a tunnel that carries network layer packets in PPP frames. IPsec provides encryption, authentication, and integrity checks for transmitted data.
To do this you need to follow these steps:

Configuring Remote Access VPN Using CLI

​Step 1. Allow the VPN service in the zone to which VPN clients will connect.

To edit the zone parameters, use the following command:

Admin@UGOS# set network zone <parameters>

To learn more about the commands and parameters for creating and editing zones using the CLI, see the article Zones.

Here is an example command that edits the Untrusted zone to allow the VPN service inside it:

Admin@UGOS# set network zone Untrusted enabled-services [ VPN ]

Step 2. Create a zone where the servers connecting using a VPN will be placed.

To create a zone, use the following command:

Admin@UGOS# create network zone <parameters>

To learn more about the commands and parameters for creating and editing zones using the CLI, see the article Zones.

Here is an example command that creates a zone called RA_VPN:

Admin@UGOS# create network zone name RA_VPN enabled-services [ VPN ]

Step 3. Create a NAT rule for the newly created zone.

NAT rules are created using a command that employs the UPL syntax:

Admin@UGOS# create network-policy nat-routing <position> upl-rule <parameters>

For more details on how to configure firewall rules using the CLI, see the Configuring NAT and Routing Rules article.

Here is an example command that creates a NAT rule from RA_VPN to Zone1:

# create network-policy nat-routing 1 upl-rule PASS \ ...src.zone = RA_VPN \ ...dst.zone = Zone1 \ ...nat \ ...rule_log(session) \ ...name("RA NAT rule") \ ...enabled true

Step 4. If required, create a firewall rule that allows traffic from the zone created earlier to the desired network segment.

Firewall rules are created using a command that employs the UPL syntax:

Admin@UGOS# create network-policy firewall <position> upl-rule <commands>

For more details on how to configure firewall rules using the CLI, see the Configuring Firewall Rules article.

An example of creating firewall rules that allow traffic from RA_VPN to Zone1 is shown below:

Admin@UGOS# create network-policy firewall 2 upl-rule PASS \ ...src.zone = RA_VPN \ ...dst.zone = Zone1 \ ...rule_log(session) \ ...name("RA_VPN to Zone1") \ ...enabled(true)

Step 5. Create an authentication profile for VPN users.

For more details on configuring authentication profiles using the CLI, see the Configuring Authentication Profiles article.

Here are example commands that create an LDAP authentication server named New ldap server for the domain testd.local and authentication profile named New profile:

Admin@UGOS# create users auth-server ldap name "New ldap server" address 192.168.1.2 domains [ test.local ] bind-dn test@test.local password 12345 enabled on Admin@UGOS# create users auth-profile name "New profile" auth-methods ldap [ "New ldap server" ]

Step 6. Create a VPN server security profile.

To create a VPN server security profile, use the following command:

Admin@UGOS# create vpn server-security-profiles <parameters>

For more details on configuring VPN security profiles using the CLI, see the Configuring VPN Security Profiles article.

Here is an example command that creates a VPN server security profile named "VPN-server profile 2" for a L2TP/IPsec VPN:

Admin@UGOS# create vpn server-security-profiles name "VPN-server profile 2" ike-version 1 ike-mode main psk 12345 dh-groups [ "Group 2 Prime 1024 bit" "Group 14 Prime 2048 bit" ] phase1-security [ SHA1/AES256 SHA256/AES256 ] phase2-security [ SHA1/AES256 SHA256/AES256 ] Repeat preshared key: Admin@UGOS#

Step 7. Create a VPN interface.

To create a VPN interface, use the following command:

Admin@UGOS# create network interface vpn <parameters>

For more details on how to create a VPN interface using the CLI, see the Interfaces article.

Here is an example command that creates a VPN interface named tunnel1 belonging to the zone RA_VPN:

Admin@UGOS# create network interface vpn interface-name 1 zone RA_VPN ip-addresses [ 172.30.252.1/24 ] enabled on

Step 8. Create a VPN network.

To create a VPN network, use the following command:

Admin@UGOS# create vpn networks <parameters>

For more details on how to create a VPN network using the CLI, see the Configuring VPN Networks article.

Here is an example command that creates a VPN network named "VPN network 2":

Admin@UGOS# create vpn networks name "VPN network 2" ip-range 172.30.252.2-172.30.252.254 mask 255.255.255.0 use-system-dns on routes-ip-list [ "Int net address" ]

Step 9. Create a VPN server rule.

VPN server rules are created using a command that employs the UPL syntax:

Admin@UGOS# create vpn server-rules <position> upl-rule <commands>

For more details on how to create VPN server rules using the CLI, see the Configuring Server Rules article.

Here is an example command that creates a VPN server rule named "VPN-server rule 2" using the following previously defined items: VPN server security profile "VPN-server profile 2", VPN network "VPN network 2", user authentication profile "New profile", VPN interface tunnel1, and VPN server external IP address list "Ext VPN address":

Admin@UGOS# create vpn server-rules 2 upl-rule OK \ ...name("VPN-server rule 2") \ ...profile("VPN-server profile 2") \ ...vpn_network("VPN network 2") \ ...auth_profile("New profile") \ ...interface(tunnel1) \ ...src.zone = Untrusted ...dst.ip = lib.network("Ext VPN address") ...enabled(true)

UserGate Client IKEv2 with certificate

To connect VPN clients to the corporate network, NGFW needs to be configured for working in the VPN server role, and the user with the UserGate Client software installed acts as a VPN client. When a VPN is created using IKEv2/IPSec, the IKEv2 protocol exchanges keys and establishes and manages a secure connection. Before establishing an IKEv2 IPsec tunnel, devices must authenticate to each other, ensuring that they are legitimate. This includes the use of pre-negotiated certificates. The certificates are verified:

• Over an encrypted channel, the VPN client sends a user certificate and encrypted data signed with a private key.

• The VPN server decrypts the data using the client's public key and compares it with its control set, checking whether the client has a private key.

• The VPN server, according to the configured user certificate profile, checks the client certificate against the specified certificate chain.

• The VPN server checks for revoked certificates.

• The VPN server checks the UPN attributes of the user specified in the authentication profile with the attributes in the CN and\or SAN:principal name certificate.

• If any of the four steps fails, the connection will not be established.

• If all checks are passed, the VPN server, for its part, sends its certificate and encrypted data signed with its private key, as well as the presence of the second factor (if specified).

• The client checks the authenticity of the server's signature and the correspondence of subjectAlternativeName to the address to which it connected.

Follow these steps:

UserGate Client IKEv2 Authentication via Radius Using Login and Password

When initializing a VPN tunnel using the IKEv2/IPsec protocol, the user is authenticated using login and password via Radius. To connect VPN clients to the corporate network, NGFW needs to be configured for working in the VPN server role and the user with the UserGate Client software installed acts as a VPN client.

The VPN client initiates the process of establishing a VPN tunnel with the VPN server by sending an IKE_AUTH message. The server responds to the client that authorization via EAP-MSCHAPv2 is required. The client exchanges several EAP packets with the server. The VPN server broadcasts EAP packets via RADIUS to the domain RADIUS server, which makes the authentication decision. Next, after receiving a positive response from the RADIUS server, the VPN server, using the received login, requests the domain for this user and asks all of its groups, then a decision is made whether this user can connect to the VPN server.