At the moment I am responsible for several ongoing experiments in a laboratory. Most instruments have their own computer to manage the experiments. These computers are accessed via remote desktop. In some experiments a server is running which controls and monitors the tests. The servers can be accessed via applications installed on host computers. When I am on site in the lab or in the office, I can access all experiments. But unfortunately I cannot connect to all experiments from home via VPN. The reason for this is that not all computers are located in the same subnet, which is accessible via VPN. There is only one server in the subnet accessible through VPN, which is used as a database server. For security reasons, the IT department does not simply grant VPN access to every computer in the lab. That’s why I’m looking for a simple flexible solution where I can define myself which experiments should be accessible via VPN.

Route Incomming VPN Traffic

The idea is to use the database server to route traffic from VPN to my experiments. On the database server Windows Server 2008 R2 is running. Fortunately I have enough rights to configure the proxyport on this machine. With proxyport I am able to route incoming traffic on a certain port to another IP address and port. For example, I can specify that incoming data on port 50000 is forwarded to the IP address 172.16.32.105 and the Remote Desktop Protocol (RDP) port. On my local host computer on which I want to connect to the computer in a lab, I only need to configure in my RDP connection the IP address from the database server and port 50000.

The following example shows how a new configuration on the database server can be entered in proxyport. Traffic arriving on the database server on port 50000 is forwarded to the computer with IP 172.16.32.105 and port 3389 (RDP).

netsh interface portproxy add v4tov4 listenport=50000  connectport=3389  connectaddress=172.16.32.105

If necessary, port 50000 on the database server can be opened with the following command. The opened ports can be tested with TELNET.

netsh advfirewall firewall add rule name="P50000TCPin" dir=in action=allow protocol=TCP localport=50000

With the following command all configured routes on the database server can be listed.

netsh interface portproxy show all

A routing entry can be removed by specifying the listening port of proxyport on the database server. The second command can be used to close the openen port in the firewall.

netsh interface portproxy delete v4tov4 listenport=50000
netsh advfirewall firewall delete rule name="P50000TCPin" dir=in protocol=TCP localport=50000 

Conclusions

The use of proxyport on the database server makes it possible to operate and monitor running experiments in the laboratory from anywhere via VPN. The solution is practical because changes can be made at any time without the support of the IT department. After several weeks of operation one can say that the connection always works reliably. Also the transfer of larger measurement data works, but slowly.