New in version 3.0-2014MMDD.
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 Edge 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 Edge 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 Edge 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 Edge 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.
The certificate to be used to connect to HTTS sites.
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 it is possible to carry out the following actions:
- Disable or enable the path.
- Modify the path.
- remove the path.
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 are included.
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 Edge Appliance.
When this checkbox is ticked, also the content present in the local resource’s header will be rewritten
Hint
Disable this option if you experiences issues (like e.g., badly displayed pages, pages not loading, browser crash) on the path.
The source IP addresses allowed to access the path, in CIDR notation.
A custom description.
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.