Accessing On-Premise Licence Servers

blog-ryan

One of the common challenges related to running engineering simulations in the cloud is trying to leverage an existing license. Many applications will periodically connect to a license server in order to checkout license tokens. Typically, companies will have a license server running on premise, sitting behind the corporate firewall. ISVs will provision licenses that are locked to single machine in order to prevent unauthorized duplication and thus it is not possible to “lift and shift” the license server into the cloud due to this hardware dependency. The challenge then is how to securely allow clusters launched in the cloud to communicate with the license server sitting on premise.

The most robust way of making an on-premise license server available to cloud instances is to setup a VPN connection to the cloud provider. However, setting up a VPN is something that typically requires corporate IT involvement and approval. This is a process that could very easily take several weeks to resolve. Are there any easier, secure alternatives available to engineers on a tight deadline?

One attractive option is to leverage SSH. Rather than modifying the corporate firewall to allow inbound connections from the cloud, we can create a reverse SSH tunnel that makes an outbound connection to a secured license proxy server instead. Then, cloud instances can be configured to connect to the license proxy server and traffic will flow through to the license server sitting behind the firewall. There are several benefits to this approach:

  1. All data being sent over the wire is encrypted since we are using SSH.
  2. No firewall modifications are needed. Outbound SSH access is typically permitted in most corporate environments.
  3. The customer is in complete control of the connection. The tunnel can be shutdown at any time and all access to the on-premise license server from the cloud instances is severed at that point.

The following diagram depicts the reverse SSH tunnel configuration. The license proxy server and all of the cloud instances can freely communicate with each other but are walled off to everyone else. The license proxy server can be configured to allow inbound SSH access from a set of IPs controlled by the company.

Ryan 1

Let’s look at a sample FlexLM configuration as a concrete example. With FlexLM there are two ports that need to be mapped: the vendor daemon port and the license server port. These ports can vary depending on the installation but for the purposes of this example, assume they are set to 7701 and 32916 respectively.

First, upon request, Rescale can deploy a license proxy and provide the private key, username, and host information to the company.

Then, once the vendor daemon and license server port information is determined, the following SSH command can be run from Joe Engineer’s workstation, which is sitting behind the firewall and has access to the on-premise license server:

This command will route TCP traffic sent to port 7701 on the license proxy to port 7701 on the company’s license server. Similarly, TCP traffic sent to port 32916 on the proxy will be forwarded to port 32916 on the license server. After the command is run, the user can submit jobs through the Rescale user interface and point the FlexLM environment variable to the license proxy. To do this, select an application from your Rescale job’s Software Settings page and check the Provide Existing License box. Then, enter the license server port (32916 in our example) and the hostname of the license proxy (company-proxy.rescale.com) in the following format 32916@company-proxy.rescale.com.

Ryan 2

In the above screenshot, the LM_LICENSE_FILE environment variable and the port@hostname format is being used to specify the license server. Please note that this can vary depending on the selected application.

Please don’t hesitate to contact us at support@rescale.com if you are interested in learning more about license server connectivity options.

This article was written by Ryan Kaneshiro.