Url Rewrite, one of the many modules that can be added on to the IIS web-server to make this a very versatile tool can be used to perform a variety of tasks, including allowing you to setup your IIS web-server as a reverse-proxy server to some other back-end HTTP service. A reverse proxy is a network device that takes in traffic coming from the Internet (for example), and forwards this traffic to a backend server on your private network, allow that backend server to be accessible to people who are not necessarily connected to your network. There are a lot of articles on how to use IIS and Url Rewrite as a reverse proxy, but I have found that many are incomplete with regards to real world scenarios from today’s web applications.

Scenario: Setting up IIS with URL rewrite as a reverse proxy with SSL offloading for a backend service.

Details: suppose that we have a web-application hosted on one of our backend web-servers, IIS or another web server, and that this application server cannot be configured to use SSL and is not accessible to the end users because the end users do not have access to the network the server is on. We want IIS to perform the following tasks:

• Take in requests from the end users for content from this application using SSL
  
• Route these requests to the backend application server using HTTP
  
• Rewrite all responses from the backend server, so that any hyperlinks, form action tags and such are constructed with the URL that the IIS reverse proxy server has.
  

Below is the diagram of the setup we wish to accomplish using IIS as a reverse proxy server:

I would like to take you through the configuration steps required to setup such a system, where requests are routed via the IIS server to the backend application server and the re-written back again with the public host-name of the IIS server and sent back to the connecting clients.

Install URL Rewrite

The first step is to install the add-on module for URL Rewrite. With Windows Server 2012 R2, you can use the Microsoft Web Platform Installer (WebPI) to download and install the URL Rewrite Module. Just search for ‘URL Rewrite’ in the search options and click ‘Add’. You can also download the extension from IIS.net – http://www.iis.net/downloads/microsoft/url-rewrite .

Once the module is installed in IIS, you will see a new Icon in the IIS Administration Console, called URL Rewrite. This icon is present at the level or each site and web-application you have in the server, and will allow you to configure re-write rules that will apply from that level downwards.

Setup a Reverse Proxy rule using the Wizard.

Open the IIS Manager Console and click on the Default Web Site from the tree view on the left. Select the URL Rewrite Icon from the middle pane, and then double click it to load the URL Rewrite interface.

Chose the ‘Add Rule’ action from the right pane of the management console, and the select the ‘Reverse Proxy Rule’ from the ‘Inbound and Outbound Rules’ category.

Now we can proceed to fill in the routing information based on the diagram above in the Wizard window that is provided to us.

While still in the same configuration window, we also need to provide information to take care of the responses that will be emitted by the backend server and will transit the IIS server on their way back to the requesting browser. These responses may have absolute hyperlinks inside and other information which contains the hostname of the backend server. If these are sent to the browser as is, the end user will not be able to access the resources these links point to simply because the browser does not know where http://privateserver:8080/HomePage.aspx is located and how it can be reached. We need to convert these into the hostname of the reverse proxy server, and have them look like: https://www.mypublicserver.com/HomePage.aspx . For this reason, we will check the ‘Rewrite the domain names of the links in HTTP responses’ checkbox in the Outbound Rules section.

The basic setup for the reverse proxy is now complete, with IIS able to capture incoming traffic and forward it to the backend server, and inspect responses from the backend server and rewrite URL links inside the responses to match the host headers that IIS uses to publish the site.

Read on in part number 2 to see where the problems with this setup start.

By Paul Cociuba
http://linqto.me/about/pcociuba