6. UserGate Getting Started. VPN

Welcome readers to the sixth publication of a series of articles dedicated to the company’s products UserGate… This article will consider how you can provide access for remote users to internal company resources using UserGate.

I will show you how to set up Remote access VPN and SSL VPN. In the first case, UserGate needs to be configured as a server, and users, on their part, will need to configure a client to connect to UserGate (UserGate supports work with standard clients of most popular operating systems). In the second case, users only need a browser, but not all types of resources can be configured in this way.

VPN for client remote access

UserGate does not have its own VPN client, so it uses Layer 2 Tunnelling Protocol (L2TP) to create tunnels, and IPSec to protect the transmitted data. Since L2TP / IPsec is supported by most modern operating systems, it allows you to configure connection to UserGate using standard clients. As I wrote above, UserGate acts as a server and in order to configure it, you need to do the following:

in the “Network” section, you need to enable the VPN service for the zone from which clients will connect, for me this is the “Untrusted” zone. Further, in the same section, you need to create a zone in which clients connected via VPN are placed, you can use the already existing VPN for remote access zone.

In order for traffic to go from the “VPN for remote access” zone to the zones we need, create a NAT rule in the “Network Policies” section or use the preset “NAT from VPN for remote access to Trusted and Untrusted” rule. It allows traffic from the VPN for remote access zone to the Trusted and Untrusted zones.

The next step is to create a firewall rule, for this, in the “Network Policies” section, enable the existing “VPN for remote access to Trusted and Untrusted” rule or create your own rule (this rule should allow traffic from the “VPN for remote access” zone to zones “Trusted” and “Untrusted”).

Next, we create an authorization profile in the “Users and devices” section. Here you can use the same authorization profile that is used to authorize users to access the Internet, but according to the UserGate manual, transparent authorization methods such as Kerberos, NTLM, SAML IDP cannot be used for VPN authorization.

The VPN supports multi-factor authentication, but as you can see from the screenshot, I won’t be setting up MFA.

We create a VPN interface, for this we go to the “Network”, “Interfaces” section, where by default the tunnel1 VPN interface has already been created, which is recommended to be used for Remote access VPN, enable it.

We proceed to the direct configuration of VPN parameters, for this we go to the “VPN” section.

In the subsection “VPN Security Profiles” there is already a pre-configured “Remote access VPN profile” profile, it remains to open it and on the “General” tab change the general encryption key (Preshared key). On the “Security” tab, you can select pairs of authentication and encryption algorithms. Algorithms are used in the order in which they are depicted (top to bottom) and when establishing a connection, the first pair is used that the server and client support. The authorization and encryption algorithms shown in the example are suitable for most standard VPN clients. It is allowed to have several profiles and use them to build connections with different types of clients.

Next, go to the subsection “VPN networks”, and either create a new VPN network, or change the existing “Remote access VPN network”:

Let’s configure the range of IP addresses that will be used by clients. We exclude from the range the addresses that are assigned to the VPN interface that are used in conjunction with this network. Also, do not specify a broadcast address.

You can assign your own DNS servers, which will be transferred to the client, or check the “Use system DNS” checkbox, in this case the client will be assigned the DNS servers that UserGate uses.

On the VPN routes tab, routes are specified that are transmitted to the client in the form of classless addressing (CIDR), for example, if you specify any, then all the remote user’s traffic will go into the tunnel, and then be routed as local traffic by the gateway. If it is necessary to let traffic only to the local network, then we indicate this network here, and the rest of the traffic will go past the tunnel.

When creating a server rule in the “Server Rules” subsection, we use the previously configured VPN network, VPN interface and VPN profile, and also select the “Untrusted” zone to which VPN users will connect, the “User auth profile” authorization profile and VPN users (I have this is the local group “VPN users” and the domain user “test”).

Also, if you need to configure the MFA TOTP (Time-based One-time Password Algorithm), then the initial initialization of the TOTP device is performed here.

The next step is to configure the VPN client on the user’s computer. For Windows 10, the settings are shown in the screenshot below, but there are a few nuances. To connect, an unencrypted password (PAP) is used, respectively, in the adapter settings, we specify this protocol. Although this is an unencrypted password, it is transmitted over a channel encrypted by our shared key. Also, for correct operation in this system, you need to change the HKEY registry parameterLOCALMACHINE SYSTEM CurrentControlSet Services PolicyAgent according to article…

For configuration on Linux clients, UserGate offers to install additional packages network-manager-l2tp and network-manager-l2tp-gnome. After that, you can start setting up:

create a new VPN connection by choosing Layer 2 Tunneling Protocol (L2TP).

After that, we configure the connection parameters and specify the data for authentication. In the PPP settings, we leave PAP as the authentication method and disable all types of compression. In the IPsec settings, specify the Pre-shared key and specify the following parameters:

Phase1 algorithms: aes128-sha1-modp1024!

Phase2 algorithm: aes128-sha1!

Web portal (SSL VPN)

The web portal allows you to provide access to internal web resources, terminal and ssh servers of the company for remote or mobile users, using only the HTTPS protocol.

It is necessary to enable the web portal in the “Settings” section by clicking on the corresponding button.

In the settings window that opens, turn on the portal with the “Enabled” checkbox, set the hostname, specify the port that will be used by the web portal service, authorization profile, authorization page template, portal template. Optionally, you can add AD / LDAP domain selection on the portal page, as well as display CAPTCHA. If you do not assign your certificate to create an HTTPS connection, then the certificate for the Captive Portal SSL role will be used. You can also enable user authorization by certificate, but then you need to add the user certificate to the list of UserGate certificates with the “User Certificate” role and associate it with the user.

To allow access to the service, you need to check the box next to the web portal for the zone from which users will connect.

Actually now, users have access to the portal. It remains to add internal resources. To do this, go to the “Global Portal” section and in the “Web Portal” subsection create records of publications of internal resources.

By clicking the “Add” button in the “Web portal” subsection, the resource settings window appears. After enabling the resource and filling in the name, go to the “URL” field, here you must specify the full URL, starting with http: //, https: //, ftp: //, ssh: // or rdp: //. For RDP access to work, you must disable the Network Level Authentication option on the terminal server. The “Direct access domain” field is optional, if you specify the domain, the user can access the published resource bypassing the web portal. In the “Icon” field, you can select the icon that will be displayed on the web portal for this bookmark. The Sub URLs tab lists the URLs required for the primary URL to work. On the “Users” tab, select the users for whom the resource will be displayed.

Conclusion

This article covered two methods of accessing a company resource for remote users. It is also possible to provide access to some resources using DNAT / Port Forwarding and Reverse Proxy, but DNAT / Port Forwarding has already been covered, and Reverse Proxy is used to publish HTTP / HTTPS servers with only some advantages (unlike DNAT / Port forwarding):

1. Publishing over HTTPS servers running over HTTP and vice versa.

2. Balancing requests to a web server farm.

3. Possibility to restrict access to published servers from specific Useragent.

4. Possibility of substitution of domains and paths of published servers.

It should also be noted that when publishing internal resources using DNAT / Port Forwarding, Reverse Proxy and Web Portal, the order of applying the rules is as follows: 1. DNAT rules. 2. Reverse proxy rules. 3. Rules of the web portal.

Stay tuned for updates in our channels (Telegram, Facebook, VK, TS Solution Blog)!