Setup Reverse Proxy on Windows Server: ARR in IIS and the WAP remote access role

The Web Application Proxy (WAP in typical parlance) is incredibly intuitive and easy to use. Publishing a “passthrough” is a simple unauthenticated TLS terminating reverse proxy. (Unauthenticated in this case referring to the lack of pre-authentication at the proxy level, relying on the Application itself to authenticate normally. It’s by no means insecure!)

The WAP however, while a fantastic product, has a dirty little secret – It requires Active Directory Federated Services (ADFS) as a dependency. ADFS is a wonderful piece of infrastructure that allows you to create both internal and external federations using WS-FED, WS-Trust and SAML all in one neat package. If you haven’t evaluated ADFS, it’s highly recommended, but it does make the WAP a less appealing solution if you don’t already have this infrastructure deployed. The WAP, from a technical level, stores its configuration in the ADFS Database (which can either utilize the Windows Internal Database feature, or store its shared sessioning in a proper SQL Database).

It utilizes a wildcard certificate.You can purchase one from SSLTrust starting at just $67.10 per year to protect all of your sub domains. Or we highly recommend a GeoTrust Wildcard Certificate for high browser and device trust.

If you utilise ADFS to federate your applications, the WAP can actually act as an authenticated terminating reverse proxy prompting for sign in to your browser-based federation and allowing access to all of your applications without the user having to sign in to each one. In either situation, having one or two WAP servers (they cluster automatically – just spin up multiple servers running the role and connect them to the same ADFS Farm), will allow you to configure only a few servers with your SSL Baseline and be assured that something isn’t slipping through the cracks – imagine the flexibility and security!

If you already have ADFS up and running, you can install the WAP with a few simple powershell cmdlets (Or simply perform the action via Server Manager in the GUI).

Will install the role, and take approximately 10 minutes.

Once the role is installed run

Where the –CertificateThumbprint is the thumbprint of the wildcard certificate, installed under “local machine” personal certificates. (If you issue your CSR from the WAP, when you import the signed certificate from SSLTrust this will be done for you automatically), and FederationServiceName is the resolvable name of your ADFS Federation. You will need to provide the username and password of your ADFS Service account, and you’ll be ready to add entries through the GUI.

Here we set up an entry to proxy to our backend application. Note that even though this is “pass through” (No pre-authentication is performed), it is not SSL-Offloading, it is SSL-Terminating.

Note that “External URL” and “Internal URL” must match except for subdomain.

ARR does not come bundled with IIS, but can be downloaded from Microsoft’s site here:

http://www.iis.net/downloads/microsoft/application-request-routing

Once installed, in IIS Select “Application Request Routing Cache”. On the righthand side, select “Server Proxy Settings”.

Under “HTTP Version”, select “Passthrough” – because we are setting up a load balancing proxy, this is a non-terminating TLS proxy. This is also known as “SSL Offloading” in ARR terms, and SSL Offloading will be automatically checked below. If you have only one backend, or are load balancing elsewhere with a virtual IP, you can select “HTTP 1.1” for a terminating TLS proxy.

Now, create a Server Farm in IIS.

The Farm members are the backend servers we are load balancing. Under the farm on the left hand side, select the name of your farm. On the middle pane, select “Proxy”. You can now configure individual proxy settings for this farm. Make sure to select “Reverse Rewrite Host in response headers”. Back in that middle pane, you can select “Health Test” to define health checks for the member servers. You can also define rewrite rules to remap requests on the fly as they hit the web server. Remember, because this is a non-terminating proxy offloading SSL to the application itself, no wildcard certificate is needed here. However, it still makes sense to purchase a wildcard to consolidate the need to request and update certificates.

Remember, there might be special considerations if your backend is using SNI. Also remember that a non-terminating reverse proxy does not create a baseline, and because it indiscriminately passes requests to a backend server, you must insure that each backend server is configured to handle SSL/TLS correctly.