Create a ticket

Q100030: Accessing a floating license via a virtual private network (VPN) connection


Customers sometimes ask if or how they can connect their client-side machines back to their floating license server when the client-side machine is off-site, away from the network of the license server.  This is commonly done by connecting over the internet, using a VPN.


Accessing a floating license via a virtual private network (VPN) connection:

A VPN is simply a tunnel on a network (usually the internet).

The client connects to the server on 2 TCP ports, whether using a VPN or not.
If there is a firewall, then it must be open for those 2 ports, whether using a VPN or not. This information is in the Foundry License Tools manual FLT.pdf.

Please note: We are not able to assist in configuring a network. Please contact your network administration for assistance.

However, the following summarization for the requirements of the floating license system may be useful:

In order for a remote client-side machine to get a floating license from a
license server, it simply has to address the server and do it on the network
TCP port(s) the server is using. That's 2 levels of addressing. Our RLM
server is usually listening on port 4101 for a connection request from a
client. If the client cannot ping the server, that is, "see" it on the
network at the lowest level available (a ping) , then it doesn't matter what
ports it needs to connect on - it has to first address the server.

Clients can address the server by the server's hostname, fully qualified
domain name (FQDN) or IP address. Whichever one of these terms the client
uses, it only has to remain valid for the duration of the license use. In
other words, if the server's is reachable by the server's IP address, but that
IP address periodically changes, then the client has to adapt to use the right
address when it needs it. It probably won't maintain a connection if the IP
changes during a session.

Moreover, a client typically has a local .lic license file that has the
server's hostname, fully qualified domain name (FQDN) or IP address in it.
If the client keeps adding more variations of these files, because the
server's data is changing, then you have to clean-up these client files or
else they'll start to have a slowing effect on the connected, as the client
tries and fails on all the bad .lic files.

Every time a user opens a product and tries to license at a client with a
different input string (port@server), s/he creates a new license file, and
often we have to clean a lot of bad license files off the clients.

The client-side license file is a plain-text .lic file stored here:

on Mac:
/Library/Application Support/TheFoundry/RLM/

on Linux:

on Windows:
C:\Program Files\The Foundry\RLM\
C:\ProgramData\The Foundry\RLM\
C:\Program Files (x86)\The Foundry\RLM\

The file contains one line:

HOST servername any 4101

where servername is the server's hostname, fully qualified domain name (FQDN)
or IP address.

A simple ping test can validate the term that will work for your
client-to-server connection, i.e. from the client, type

ping servername

where servername is the server's hostname, fully qualified domain name (FQDN)
or IP address.

A good ping test looks like this example (sikorski is the client doing the

sikorski:~ dave$ ping grim
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.477 ms
64 bytes from icmp_seq=1 ttl=64 time=0.380 ms
64 bytes from icmp_seq=2 ttl=64 time=0.249 ms
64 bytes from icmp_seq=3 ttl=64 time=0.313 ms
64 bytes from icmp_seq=4 ttl=64 time=0.327 ms

(type <control> + c to halt the stream of output)

A bad ping test looks like this example:

sikorski:~ dave$ ping goofy
ping: cannot resolve goofy: Unknown host
sikorski:~ dave$

Typically a ping test at the server is not blocked by firewall settings - but
it could be.

Assuming you get a good ping test, then you have to test the second level of addressing - the TCP port number of the server. These are MUCH MORE commonly blocked by firewall settings. Firewalls typically block most TCP network ports unless you open them up specifically.

The easiest firewall approach is to prepare the server to open the ports for
the RLM license manager. Download the Foundry Licensing Tools User Guide and follow instructions starting on page 67 of the FLT.pdf

A Telnet command verifies the port is actually open and the client can connect
to it. Many times, we've had customers assure us that the firewall is off but
there's something overlooked somewhere in the network path - a server setting,
a router, ... something.

From a terminal on the client (Windows machines have a telnet client you can
enable) the command is

telnet yourservername 4101

If it connects, then the terminal will display

Trying <yourservername's IP address>...
Connected to nemo.
Escape character is '^]'

or if there's a DNS involved, it could display

Trying <yourservername's IP address>...
Connected to <yourservername's fully-qualified domain name>.
Escape character is '^]'

Use <control>+ right bracket to get back to telnet prompt and use <control>+c
to get back to the terminal prompt

In either case, the The output above shows that port 4101 is opened on host

If that all works, then you need to try the second of the two ports - this one
is in the FLU diagnostic output from the server. Because it is NOT specified
in the license file, it is chosen at random when the license manager starts
up. Here's an example from someone's server diagnostic:

==> --------- ISV servers ----------
==> Name Port Running Restarts
==> foundry 49153 Yes 0
==> ------------------------


telnet yourservername 49153

Was this article helpful?

We're sorry to hear that

Please tell us why
4 out of 5 found this helpful