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 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.
A few more options can be configured in the Advanced panel.
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:
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.
Also all the sub-paths relative to the main path are included.
When this checkbox is ticked, also the content present in the local resource’s header will be rewritten
Disable this option if you experiences issues (like e.g., badly displayed pages, pages not loading, browser crash) on 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.