Setup IIS with URL Rewrite as a reverse proxy for real world apps

[pcociuba]

Application Request Routing, 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 Application Request Routing (ARR for short)

The first step is to install the add-on module for Application Request Routing for IIS. With Windows Server 2012 R2 or later versions of Windows Server 2016 and 2018, you can use the Microsoft Web Platform Installer 5.1 (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 - https://www.iis.net/downloads/microsoft/application-request-routing.

Once the module is installed in IIS, you will see a new Icon in the IIS Administration Console, called URL Rewrite - you may note that Url Rewrite is also an add-on that can be installed separately, but that ARR uses functionality provided by Url Rewrite to allow the server to act as a reverse proxy. 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.

[carehart]

FWIW, I'll note for readers here that while this post is shown here with a Sep 2019 date, the content is actually a re-post of the author's original blog entry from 2016 at https://blogs.msdn.microsoft.com/friis/2016/08/25/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-.... And though the comments on that one are closed, there are some useful ones (from others and the author) which readers here may want to note.

And as we CAN comment here, I would like to ask the author, Paul: why did you not take the chance to revise this post to clarify how one needs to install ARR for this to work?  Anyone proceeding to the step to click on/add the "reverse proxy" rule will be prompted that they must install ARR first.  You hadn't indicated this in the first article (or the next 3 parts), but you did acknowledge it in later comments. Is it perhaps that when you wrote the article, you had ARR installed and so didn't notice this as a requirement? That would be understandable. 

But it would be helpful for people to know of this requirement/prerequisite, when reading this post (and the older version of it).

Some may argue, "since IIS tells you, why should the article bother?" But the point is that some will read the article (perhaps on a mobile device) and later go back to try it (to tell others that "it's possible"), only to find this new, unexpected requirement. Perhaps they are not in a position to install new software, or they may worry that ARR is a large addition to IIS that could change its behavior in other ways.

I'm just pointing all this out for the sake of other readers who find it, but I would plead with Paul to consider adding mention of the AR requirement in the article, either near the top or at that point where the prompt would appear for those who don't have it installed.

Finally, if anyone may know of a solution for IIS that enables simple reverse proxy capabilities (without requiring ARR), I'd love to hear of that. And I'd be ok if it was an add-on. Again one may wonder, "then why not accept ARR as the needed add-on?", but the point is that that does a lot MORE than just add reverse proxy capability. If some add-on did just that, I and others may consider it first over having to go the ARR route.

All that said, thanks, Paul, for the effort on this and the other parts of the article series.

[pcociuba]

Hello CareHart,

You are absolutely correct in pointing out these things in your comment above:
- the old blog (which was on the MSDN blogs side) will sunset soon, so this is why this article has been transitioned here. Unfortunately, the comments section could not be switched over.
- I have also reviewed the section regarding the install requirements, so that it specifies outright that what you need to download and install is ARR rather than just URL Rewrite (so readers can now know what to expect).

As for being able to use IIS as a reverse proxy without ARR, there are several modules that do this for very specific purposes, but they are all third party modules. There is a module that will forward jsp requests to a Tomcat Application server for example.
- what you have to understand is that ARR is two pieces of technology:

1) an HTTP Handler that will take and forward requests and read responses coming out of the backend
2) a UI component that is loaded inside the IIS manager console to allow you to edit the <rules> configuration sections in the web.config in an easy and graphical way.

You could argue that you could build your own managed handler to achieve the same, however ARR is written in native code and will thus outperform any managed handler we could write.

[carehart]

Thanks for the reply, Paul. And thanks very much for updating the post to offer that additional clarification (and more).

As for the alternatives that could offer reverse proxy without ARR, I appreciate that you mention there are some, but again I would love to hear from you or anyone offering more about those. I have tried to find them before with no success. I did say I didn't mind if they are 3rd-party add-ons. :)

And it's not that I am anti-ARR, but I fear that because it does much more than just setup reverse-proxying, it would be that some would either not want to or perhaps even not be allowed to enable it. And yes, I realize ARR "is" at least those two things you list, but it also adds still more, from load balancing to caching, and several more features listed at the bottom of that page. Again my concern is that someone may worry that adding such a toolbox when they want just a hammer may be overkill.

For instance, they may want simply one IIS instance (perhaps running as a Docker container) to proxy requests to just one backend server (perhaps also in Docker), to avoid exposing that backend publicly. You mention Tomcat, and there is its AJP approach to connecting IIS to it. But Tomcat also offers its own web server. Someone may want to leverage IIS features to be the front-end for a site, but have those requests then processed by the backend Tomcat. That would be a perfect use case of enabling such a proxy. 

And of course both Apache and nginx make it simple, but IIS does not. And adding ARR is overkill for that one need. So again if there is any alternative that would provide for this, I'd love to hear it. This URL Rewrite option of a "reverse proxy" rule was compelling, until I found everywhere that it was only offered if ARR was added.

And in case anyone may think it's just a technicality that the IIS UI only adds that rewrite option if ARR is installed, I can confirm that it will not work if you enable it via xml, such as in web.config, at least in trying to do a rewrite to a URL not processed by IIS itself, which again is my goal above. You will get errors indicating that IIS cannot process the request. Others have wanted to also do it (without respect to Docker) simply to have an IIS request be forwarded to some other back-end application, and they have encountered (and reported) the same problem.

[humewccl]

Thank you for putting together a clear set of steps to create a reverse server proxy. We are in a situation where we need to create such a server. We have several legacy apps on a web server that we will have to keep running for some time. The webserver receives traffic from both internal and external users. My read is that the reverse proxy server doesn't care where the traffic comes from, only that it is addressed to the backend server it is set up to service. Once we set up the server and then repoint our DNS settings to direct web traffic to the reverse proxy server first, will it be able to deal with the traffic from both our private network and the internet?   Our set up would be  Internet to RPS to Legacy and Private to RPS to Legacy. Is there any reason I am missing to cause this to fail, other than the usual vagaries of computers and networks?

[hey77]

Hi, 

Thanks for the post. I have successfully tested this for couple of URLs hosted in the same server configuring the URL Rewrite. 

However when I opened the Application Request Routing properties, it shows me the following alerts. Is it Ok to leave it as is?