Reverse Proxy on IIS

Requirements

• IIS 7.5
• You'll need to download and install these modules (check the correct version for your IIS version, might differ depending on the versions)
  
  • Microsoft URL Rewrite Module 2.0 for IIS 7  
  • Application request routing module  

Setup

This demo setup shows how 2 Windows 2008 IIS webservers can be setup to work together as reverse proxy.

Server 1: 192.168.0.43 (dev4)
The public facing webserver, that holds your application (e.g. ASP.net)

Server 2: 192.168.0.18 (dev1)
The server that is not open to the web, but only accessible through the internal network.

Server 1 also has an external IP and DNS

dev4.chili-publish.com points to 178.33.95.43
This ip translates to the internal IP on the firewall or router.

Goal

A client (browsers) requesting information on dev4 (server 1) should not be aware that all requests are passed internally to server 2, hosting the CHILI Application.

Not all requests should be transferred, only the requests to /CHILI should be passed to the second server.

Concept

IIS will internally rewrite the request to another server, and pass the info.

Howto

Step1: Download the modules, and install on your server

Check the versions for your server, you'll need IIS 7.5. This setup is tested on Windows 2008 R2, IIS 7.5

Step 2: Configure ARR

ARR is required for the rewriting rules to work.
In the IIS Manager, click on the server node, and double click on the icon: "Application Request Routing cache" 

Then click on the "Server Proxy settings" on the right.

Our settings would look like this.

In older versions of CHILI, you would not need to increase the Response buffer threshold (KB) setting to 2048, but since version 4.5.4.x you must increase the response buffer so that the Proxy can buffer our bigger files that are periodically flushed.

Step 3: Configure Rewrite rules

You should allready have a website configured.
This website should listen to the domain you'll be using.

Click on the website node in your IIS Manager

Ours is called "revproxy", and listens to "dev4.chili-publish.com" on port 80 (default)

If you installed the modules correctly, there should be a feature called "URL Rewrite"

Open the feature to see a list of rules.
Initially, there will be no rules.

We'll need to add 2 rules. One for inbound requests, and one for outbound.
You can start on the right with "Add Rule(s)..." >> Reverse Proxy, for a basic setup. 

Now we'll need to change the rules to fit our needs.

Inbound

The inbound rule looks like this:

As you notice, the rule catches all requests to CHILI/ and rewrites them internally to the dev1 server (Server 2 in our setup).
All URL paramaters are passed also through the {R:1} statement.

Outbound

All information that comes back from the server is passed back to the client.
Since this informations holds references to dev1 (since this is what the second servers knows as the client) we have to replace some links.
This is specific for CHILI Publisher, since the CHILI webservice WSDL has information with links to other resources. And these links in the WSDL needs to be rewritten back to the original server.

Since we don't want all the information in the response to be rewritten, we created a custom tag match.

The tags in the XML (WSDL definition) look like this (links allready replaced with the dev4)
In the real worlds (before this outbound rule, they would contain the link to dev1.chili-publish.com 

The custom tags we defined are

• soap
• soap:address
• soap12:address

All with the Matching attribute "location"

If the match is found, in the tags in the XML, the rewrite rule will replace all occurences of dev1 to dev4 again.

Important !

Due to the fact we are tampering with the response of the HTTP request, some clients could react in a strange way.
In the response, one of the headers mentions the length of the response, in characters.
If we change the content, and the length of the response, the checksum doesn't fit anymore.

Solution

Most safe way to work around this limitation, is to use 2 domainnames, with the same length, like in our example.

dev4.chili-publish.com
dev1.chili-publish.com

If you would use

www.yourapp.com and chili.yourapp.com then you might have problems, since the chili has 5 characters, and www has only 3. So the length of the response would be different. 

Result

This setup results in /CHILI/ being served from dev1 (server 2) in stead of dev4 (server 1)
The client doesn't notice the content is being served from somewhere else.

revproxy.mov