Accessing a Cloud-Based Demo Environment - Destination NAT or Reverse Proxy?

Several months ago I moved my entire demo environment to the cloud. Before that I was struggeling with the limitations of my laptop. Instead of sacrificing mobility for performance, I decided that its worth the extra money to rent a hardware box in the cloud. But then I was facing new obstacles when demonstrating use cases. The virtual machines are isolated in a virtual LAN which is not accessible publicly. In the end, it became a question of using destination network address translation (DNAT) or a reverse proxy to seemlessly access the virtual LAN.

Use Cases

Due to my focus in enterprise IT, I am working with many different but related products. Some of them even address the same use case with a similar access scenario, for example:

It has always been a challange to make those accessible through a single public IP address.

Destination NAT

The first incarnation of my cloud-based demo environment was with Windows Server 2008 R2. I installed Forefront Threat Management Gateway (TMG) to protect the machine as well as the virtual LANs (Hyper-V based) against access from the internet.

To publish the services mentioned above through a single IP address, you need to use separate target ports. Based on these ports, destination NAT can be used to forward connections to the designated service.

When I upgraded to Windows Server 2012, I was shocked to find out that TMG is not supported on the latest Windows server and will even be discontinued. So, I had to move to Routing and Remote Access Services (RRAS) to use IP forwarding. But the management interface for RRAS is a nightmare to use because its features are very well hidden. I never managed to configure destination NAT according to my needs.

Although, I had a shiny new installation with the latest Windows server, it was still a step backwards in terms of manageability.

Reverse Proxy

A few days ago, I thought of another solution to my situation while I was falling asleep. Guess what, I was wide awake all of a sudden! A reverse proxy server on the host OS would allow for connections from the internet into the virtual LAN. I would have to configure the proxy in the browser on my device and would be able to access services on the virtual LAN by their DNS name on their default port.

I came across WinGate, a professional proxy server, which comes with a free 3 user license. A proxy servers terminates client connections makes requests to the target server in their stead. By default, this concept is used for internal clients to access the internet. In my case I needed to configure WinGate to accept connections on the public interface and allow them to reach services on the private LAN.

You need to take the following steps to setup WinGate for proper external access to the private LAN:

Activate proxy on external interface

Create users and groups for authentication

Define a list of internal sites

Create a category

Create a manual classifier

Create an access rule

Voila, your reverse proxy is ready to serve connections!

But … I do not want my browser to point to my reverse proxy for all targets. It slows down connections because of the additional hop and it makes me dependent on a service provided by demo environment. Therefore, I created a Proxy Auto-Configuration (PAC) file to filter for my private domain and IP addresses. The following JavaScript function realizes my requirements for routing connections:

function FindProxyForURL(url, host) {
    if (dnsDomainIs(host, "myvirtualdomain.local")) {
        return "PROXY mypublicname.com:8080; DIRECT";
    }
    if (shExpMatch(host, "192.168.182.*")) {
        return "PROXY mypublicname.com:8080; DIRECT";
    }
    return "DIRECT";
}

The logic in the PAC file is also backwards just like the (reverse) proxy. Usually you use a PAC file to direct all connections to your proxy server and specify exceptions when a direct connection is possible or desirable. But in my case I wanted to have direct access to all sites except connections to my demo environment.

When placing the PAC file on your device, Internet Explorer will not access a local path in its configuration. You will have to convert the location into a file URL, e.g. file://c:/temp/proxy.pac.

Comparison and Summary

By using a reverse proxy and a local PAC file I was able to access arbitrary services in my private LAN without any hassle. You can even use almost any device to access the environment by simply configuring the reverse proxy for the time needed.

The approach has one limitation. If you need a proxy server to access the internet, you will not be able to access your own proxy. As soon as you configure it, the browser looses the internet connection.

Feedback is always welcome! If you'd like to get in touch with me concerning the contents of this article, please use Twitter.