The VPN portal seamlessly operates between a client and a server, allowing a client to retrieve remote HTTP and HTTPS resources without a direct connection to the server. To do so, it processes requests from the client, then it fetches the resource from the server, and finally it delivers it back to the client. In other words, the VPN portal acts as a kind of proxy, and more precisely as a reverse proxy, i.e., a proxy in which, contrary to a normal (forward) proxy, the server resides within one zone served by the Endian UTM Appliance -usually the DMZ, while the client connects from a remote location. Hence, the connection originates from the RED untrusted network segment and, without the VPN portal, it would not be allowed.
Although in principle very similar to methods like port forwarding, the Endian UTM Appliance' s VPN portal advantages are manifold, as it is a fully featured web server, which provides the abilities to authenticate the client and restrict the possible source IPs for the connection, making the communication more secure. Moreover, the ability to define multiple paths from the remote connection to different resources on the server adds more flexibility to the possible configuration.
A very immediate use case that can be devised from the description is to allow a company’s employee or coworker to remotely access a resource located in the company’s Intranet, without the necessity of setting up and enabling the OpenVPN server. It is worth noting that on the same Endian UTM Appliance may coexist both a VPN server and a VPN portal.
In order to implement this use case, define a new path and the destination, then require authentication for the user, which can be carried out locally on the Endian UTM Appliance, or by connecting to a LDAP/AD installation in the Intranet.
In this tab it is possible to configure the main portal’s options,
related to the domain name and uplink used. To activate the portal,
click on the grey switch 
, which would turn green after a few
seconds.
The name assigned to the portal.
The domain for which the portal is responsible and accepts traffic.
The name of the company that owns the domain. It will be used in the help page, see next option.
By ticking this option, when a domain’s root path has not been configured, an informative page will be shown to the user connecting to the domain. The portal’s owner name will be included in that page’s content as reference for contact.
The uplink through which to access the resources associated to the domain.
By ticking this checkbox, the VPN portal would also allow to connect to HTTPS domains and another option will appear.
Certificate configuration and management is carried out exactly like in the case of OpenVPN server (in ), in which all the various management modalities are explained.
A few more options can be configured in the Advanced panel.
The port used by the portal for normal HTTP traffic.
The port used by the portal for encrypted HTTPS traffic.
Write in the text-field additional domain names associated with the main one, one per line.
Once the main portal configuration has been carried out, it is possible to set up the various resources that can be accessed within the zones. Here, a table carrying all the paths already defined to local resources appears at the bottom of the table. On each path in the table it is possible to carry out some actions.
New paths can be defined by clicking on the Add new path link above the table.
The path to the resource requested by the client.
Note
Also all the sub-paths relative to the main path will be included as well.
The local resource to which the traffic will be redirected by the portal, which should be located in any zone reachable from the Endian UTM Appliance.
The source IP addresses allowed to access the path.
A custom description.
When this checkbox is ticked, also the content present in the local resource’s header will be rewritten
Hint
Disable this option in case of issues (like e.g., badly displayed pages, pages not loading, browser crash) are experienced while accessing the path.
Tick the checkbox to require authentication for the path.
If a custom authentication server should be used to access the path, tick the checkbox and select one from the multiselect box below.
Tick the checkbox to activate the path.
Best practices for nested authentication.
While authentication can be present on both the VPN portal and the path reached through the portal, it is a good practice to have authentication only on either of the two sides. Indeed, there is a subtle problem with the nested authentication. Consider a scenario in which the portal requires as username-password the pair john/somepass whereas the path requires mary/otherpass. At the first connection, in the pop-up that requires authentication, the pair john/somepass shall be supplied, to gain access to the path behind the portal. Now, the pair mary/pass gives access to the path. However, when another page in the path is required, the portal receives the last credentials stored, which are those of the path and do not match with those required for the portal and another pop up for authentication is presented.
As a workaround, if nested authentication is a mandatory requirement, the suggestion is to use the same username-password pair for both the portal and the path authentication.