10.2. Site-to-Site VPN connections

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

In the Users and devices --> Users section, create a user for each of the remote UserGate servers that will work as VPN clients and set passwords for the users. It is recommended to place all these users in a group that will be given permission to connect using a VPN. To that end, there is a default group named VPN servers in UserGate.

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

In the Network --> Zones section, edit the access control settings for the zone to which VPN clients will connect, and enable the VPN service. Usually, this is the Untrusted zone.

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

In the Network --> Zones section, create a zone where the servers connecting via a VPN will be placed. This zone can later be used in security policies.

It is recommended to use the existing default zone, VPN for Site-to-Site.

Step 4. Create a firewall rule that allows traffic from the zone created earlier.

In the Network policies --> Firewall section, create a firewall rule that allows traffic from the zone you created to other zones.

In UserGate, there is a default rule named VPN for Site-to-Site to Trusted and Untrusted that allows all traffic from the zone VPN for Site-to-Site to the Trusted and Untrusted zones. This rule is disabled by default.

To let the traffic pass to the client via the VPN tunnel from the desired server zone, you need to create an allowing firewall rule, specifying that zone as the source and VPN for Site-to-Site as the destination zone.

Step 5. Create an authentication profile.

In the Users and devices --> Auth profiles section, create an authentication profile for VPN users. The same authentication profile may be used that you use to authorize users for Internet access. Note that transparent authentication methods such as Kerberos, NTLM, or SAML IDP cannot be used for VPN authorization.

For more details on authentication profiles, see the section Authentication Profiles.

Step 6. Create a VPN security profile.

A security profile contains settings such as the pre-shared key and encryption and authentication algorithms. Multiple security profiles may be used for connecting to different client types.

To create a profile, go to VPN --> Security profiles, click Add, and fill in these fields:

• Name: the name of the security profile.

• Description: a description of the profile.

• The version of the IKE (Internet Key Exchange) protocol: the IKE (Internet Key Exchange) protocol is used to create a secure link between two networks. UserGate uses IKEv1.

• IKE mode: main or aggressive.

  The difference between the modes is that the aggressive mode uses fewer packets, which allows for quicker establishment of connections. The aggressive mode does not transmit some negotiation parameters and thus requires that they be configured identically at the opposite ends of the connection.

  • Main mode. In the main mode, the devices exchange six messages. During the first exchange (messages 1 and 2), the encryption and authentication algorithms are negotiated. 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.

  • Aggressive mode. In the aggressive mode, there are 2 exchanges, 3 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.

• Peer authentication: device authentication using a pre-shared key.

• Pre-shared key: a string that must match on the client and server for a successful connection.

Next, the settings for the first and second negotiation phases need to be configured.

In the first phase, IKE security is negotiated. The authentication is done using a pre-shared key in the mode selected earlier. Provide the following settings:

• Key lifetime: the time period after which the parties re-authenticate and re‑negotiate the first-phase settings.

• Dead peer detection interval: the state and availability of the neighboring devices is checked using the Dead Peer Detection (DPD) mechanism. DPD sends R-U-THERE messages periodically to check if the IPsec neighbor is available. Minimum interval: 10 seconds. Set 0 to disable checking.

• Max failures: the maximum number of failed discovery requests to an IPsec neighbor after which the neighbor will be considered unavailable.

• Diffie-Hellman groups: select the Diffie-Hellman group that will be used for key exchange. Instead of the key itself, certain general information is transmitted that the DH key generation algorithm needs to create the shared secret key. The larger the Diffie-Hellman group number, the more bits are used to make the key secure.

• Authentication and encryption algorithms. The algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse in or use the Up/Down buttons.

In the second phase, the method for securing IPsec connections is selected. You need to specify the following:

• Key lifetime: the time period after which the nodes must rotate the encryption key. The lifetime for the second phase is shorter than for the first one, which entails a more frequent key rotation.

• Key lifesize: the key lifetime can also be expressed in bytes. If both values (Key lifetime and Key lifesize) are specified, the counter that reaches the limit first will trigger session key re-generation.

• Authentication and encryption algorithms. The algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse in or use the Up/Down buttons.

In UserGate, there is a default security profile named Site-to-Site VPN profile that provides the required settings. If you plan to use this profile, make sure to change the pre-shared encryption key.

To facilitate connection setup for 3rd party devices, there are additional default security profiles (Cisco compatible VPN profile for Cisco devices and Fortinet compatible VPN profile for Fortinet devices).

Step 7. Create a VPN interface.

A VPN interface is a virtual network adapter that will be used to connect VPN clients. This is a cluster-type interface, which means that it will be created automatically on all UserGate configuration cluster nodes. If a HA cluster exists, VPN clients will be automatically switched to a backup server in case of any problems with the active server without terminating the existing VPN connections.

In the Network --> Interfaces section, click Add and select Add VPN. Provide the following settings:

• Name: the name of the interface. Should be in the form tunnelN, where N is the ordinal number of the VPN interface.

• Description: a description of the interface.

• Zone: the zone to which this interface will belong. All clients with a VPN connection to the UserGate server will be placed in the same zone. Specify the zone created at Step 3.

• Netflow profile: the Netflow profile used for this interface. This parameter is optional.

• Mode: the IP address assignment type, such as no address, a static IP address, or a dynamic IP address obtained using DHCP. If the interface is to be used for accepting VPN connections (Site-2-Site VPN or Remote access VPN), a static IP address must be used.

• MTU: the MTU size for the selected interface.

There is a default VPN interface named tunnel2 that is recommended for use as a site-to-site VPN interface.

Step 8. Create a VPN tunnel.

A VPN determines the network settings that will be used for connecting the client to the server. This is primarily the assignment of IP addresses to the clients inside the tunnel, the DNS settings, and (optionally) the routes that will be passed to the clients that support the use of routes assigned to them. Multiple tunnels may be used with different settings for different clients.

To create a VPN tunnel, go to VPN --> VPN networks, click Add, and fill in these fields:

• Name: the name of the network.

• Description: a description of the network.

• IP address range: the range of IP addresses that will be used by the clients and server. Exclude the addresses assigned to the VPN interface used with this network from the range. Do not enter network addresses or the broadcast address here.

• Specify the DNS servers that will be passed to the client or set the Use system DNS checkbox, in which case the client will be assigned the DNS servers used by UserGate.

  Important! A maximum of two DNS servers can be specified.

• Specify the Routes passed to the client in the Classless Inter-Domain Routing (CIDR) format.

There is a default network in UserGate named Site-to-Site VPN network with the recommended settings. To use this network, you need to add routes that will be passed to the client server.

To allow the VPN server to know about the client's subnets, configure a static route on the server by specifying the VPN tunnel address used on the client server as the destination address.

Step 9. Create a VPN server rule.

Create a VPN server rule using the VPN tunnel and profile created earlier. To create the rule, go to VPN --> Server rules, click Add, and fill in these fields:

• Name: the name of the rule.

• Description: a description of the rule.

• Server profile: the VPN server profile created earlier.

• VPN Tunnel: the VPN tunnel created earlier.

• Auth profile: the authentication profile created earlier.

• Source: the zones and IP addresses from which VPN connections are allowed. Normally, the clients are on the Internet, so specify the Untrusted zone.

  Important! Traffic processing performed with the following statements:

  • applying logic OR if several IP lists and/or domain lists are specified;

  • applying logic AND if several GeoIP and lists of IPs and/or domains are specified.

• Destination: one or more interface addresses to which the clients will connect. The interface must belong to the zone specified at Step 2.

• Interface: the VPN interface created earlier.

• Users: a group of server accounts or individual server accounts for which VPN connections are allowed.

In UserGate, there is a default server rule named Site-to-Site VPN rule that provides the required settings for a site-to-site VPN, and VPN access is allowed to the members of the local group VPN servers.

Important! To apply different server rules to different clients, use the Source zone and Source address settings. The User parameter does not govern the selection of a server rule, as the user is checked only after the VPN connection has been established.

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

In the Network --> Zones section, create a zone where the interfaces used for VPN connections will be placed. This zone can later be used in security policies.

It is recommended to use the existing default zone, VPN for Site-to-Site.

Step 2. Create a firewall rule that allows traffic to the zone created earlier.

Create an allowing firewall rule for the incoming traffic to the zone in the Network policies --> Firewall section.

In UserGate, there is a default rule named VPN for Site-to-Site to Trusted and Untrusted that allows all traffic between the VPN for Site-to-Site, Trusted, and Untrusted zones.

To let the traffic pass to the server via the VPN tunnel from the desired client server zone, you need to create an allowing firewall rule, specifying that zone as the source and VPN for Site‑to‑Site as the destination zone.

Step 3. Create a VPN security profile.

A security profile contains settings such as the pre-shared key and encryption and authentication algorithms. Multiple security profiles may be used for connecting to different client types.

To create a profile, go to VPN --> Security profiles, click Add, and fill in these fields:

• Name: the name of the security profile.

• Description: a description of the profile.

• The version of the IKE (Internet Key Exchange) protocol: the IKE (Internet Key Exchange) protocol is used to create a secure link between two networks. UserGate uses IKEv1.

• IKE mode: main or aggressive.

  The difference between the modes is that the aggressive mode uses fewer packets, which allows for quicker establishment of connections. The aggressive mode does not transmit some negotiation parameters and thus requires that they be configured identically at the opposite ends of the connection.

  • Main mode. In the main mode, the devices exchange six messages. During the first exchange (messages 1 and 2), the encryption and authentication algorithms are negotiated. 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.

  • Aggressive mode. In the aggressive mode, there are 2 exchanges, 3 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.

• Peer authentication: device authentication using a pre-shared key.

• Pre-shared key: a string that must match on the client and server for a successful connection.

Next, the settings for the first and second negotiation phases need to be configured.

In the first phase, IKE security is negotiated. The authentication is done using a pre-shared key in the mode selected earlier. Provide the following settings:

• Key lifetime: the time period after which the parties re-authenticate and re-negotiate the first-phase settings.

• Dead peer detection interval: the state and availability of the neighboring devices is checked using the Dead Peer Detection (DPD) mechanism. DPD sends R-U-THERE messages periodically to check if the IPsec neighbor is available. Minimum interval: 10 seconds. Set 0 to disable checking.

• Max failures: the maximum number of failed discovery requests to an IPsec neighbor after which the neighbor will be considered unavailable.

• Diffie-Hellman groups: select the Diffie-Hellman group that will be used for key exchange. Instead of the key itself, certain general information is transmitted that the DH key generation algorithm needs to create the shared secret key. The larger the Diffie-Hellman group number, the more bits are used to make the key secure.

• Authentication and encryption algorithms. The algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse in or use the Up/Down buttons.

In the second phase, the method for securing IPsec connections is selected. You need to specify the following:

• Key lifetime: the time period after which the nodes must rotate the encryption key. The lifetime for the second phase is shorter than for the first one, which entails a more frequent key rotation.

• Key lifesize: the key lifetime can also be expressed in bytes. If both values (Key lifetime and Key lifesize) are specified, the counter that reaches the limit first will trigger session key re-generation.

• Authentication and encryption algorithms. The algorithms are used in their listing order. To reorder the algorithms, drag and drop them with the mouse in or use the Up/Down buttons.

In UserGate, there is a default security profile named Client VPN profile that provides the required settings. If you plan to use this profile, make sure to change the pre-shared encryption key.

To facilitate connection setup for 3rd party devices, there are additional default security profiles (Cisco compatible VPN profile for Cisco devices and Fortinet compatible VPN profile for Fortinet devices).

Step 4. Create a VPN interface.

A VPN interface is a virtual network adapter that will be used to connect VPN clients. This is a cluster-type interface, which means that it will be created automatically on all UserGate configuration cluster nodes. If a HA cluster exists, VPN clients will be automatically switched to a backup server in case of any problems with the active server without terminating the existing VPN connections.

In the Network --> Interfaces section, click Add and select Add VPN. Provide the following settings:

• Name: the name of the interface. Should be in the form tunnelN, where N is the ordinal number of the VPN interface.

• Description: a description of the interface.

• Zone: the zone to which this interface will belong. All clients with a VPN connection to the UserGate server will be placed in the same zone. Specify the zone created at Step 1.

• Netflow profile: the Netflow profile used for this interface. This parameter is optional.

• Mode: the IP address assignment type, such as no address, a static IP address, or a dynamic IP address obtained using DHCP. To use the interface as a client VPN interface, use the Dynamic address assignment mode.

• MTU: the MTU size for the selected interface.

There is a default VPN interface named tunnel3 that is recommended for use for site-to-site VPN client connections.

Important! If the existing tunnel2 interface with the default settings was selected during the configuration of a tunnel interface on the server side, an IP conflict will occur on the client trying to connect to the server, because a similar tunnel2 interface with the same address range already exists on the client. For things to work correctly, the address ranges of the tunnel interfaces should not overlap. It is recommended to change the address range on the client to a unique one.

Step 5. Create a VPN client rule.

Create a VPN client rule that will initiate a VPN server connection. To create the rule, go to VPN ‑‑> Client rules, click Add, and fill in these fields:

• Enabled: enables or disables the rule.

• Name: the name of the rule.

• Description: a description of the rule.

• Security profile: the VPN security profile created earlier.

• Interface: the VPN-interface created earlier.

• VPN server address: the IP address of the VPN server to which this VPN client will connect. It is usually the IP address of an interface in the Untrusted zone on the UserGate server that acts as a VPN server.

• VPN protocol: can be L2TP (for connecting to a UserGate VPN server) or IPsec tunnel mode (for connecting to a Cisco VPN server).

• VPN networks: the IP address of the network that will be accessible to the clients on the UserGate side (Remote network) and on the VPN server side (Local network).

• Login/Password (only for the L2TP protocol): the name and password for the user created at Step 1 of configuring the VPN server.