John Gully's Blog  { technology tips, tricks and errata; }

Reverse Proxy Using Url Rewriter

I recently came to realize that our website situation was growing out of hand. We had a corporate website, an intranet site, and even a site for web access to email. All of these sites were scattered across multiple servers and each was on a unique port. While this worked, it was not simple. Each new site had to have a new rule configured in the firewall, and who wants the hassle of putting port number at the end of a url?

The solution to this mess turned out to be adding a reverse proxy to our network. By simply providing different urls (, the incomming traffic can be anlayzed by the proxy server and routed to the appropriate internal web server. All the incomming traffic is sent over the default port 80 so the end user never sees any difference. That's exactly what I wanted, great!

Since our sites are all built upon ASP.NET and hosted on IIS6 the natural option for this was Microsoft ISA Server. Unfortunately, the $1500 cost was way beyond our small company's internal IT budget. So it was off to Google for me, and after some searching, it appeared that the open source project Url Rewriter by ManagedFusion seemed to fit the bill.

IIS7 also provides some of these feature through the Application Request Routing Module, so if you are running the newer version you may want to check it out.
Although everything seemed fairly straight forward it took several hours of trial and error for me to get this figured out. I'm hoping to consolidate this information, to help anyone else out that ends up in the same situation.

Before I made any changes our network was setup as depicted below. Traffic comes through the firewall and is directed by rules on the firewall router to the appropriate server. This is all based upon the rules routing traffic on port 80 -> Server1 and port 8080 - Server2.

The goal is to allow all traffic to arrive on port 80 and use the reverse proxy to route the traffic to the appropriate server. The reverse proxy and main website are both installed on Server1, but could easily be installed on separate harware (I just didn't have the extra machine lying around). After the reverse proxy is in place the network will be as depicted below.

Setup Reverse Proxy Website
The first task is to create a new website that will function as the reverse proxy. Using IIS create a new site on Server1. I named the site ReverseProxy and placed it on port 80 (if another site already exists on port 80 make sure you relocate it to another port).  

Once created the site needs to have wildcards enabled to gain the full functionality of Url Rewriter. Right-click the new ReverseProxy site and select properties. Select the Home Directory tab and click the Configuration button. On the Mappings tab, under the Wildcard application maps section click the Insert button. Enter C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll and Uncheck the Verify that file exists checkbox. Click OK on all the prompts.

Additional instructions for configuring IIS5 can be found here on the Url Rewriter website.

Download and Install Url Rewriter
Next get the Url Rewriter application and install it. The application can be found on CodePlex at: Just go to the Downloads tab and download the latest version as a zip file (version 3.0 was the most current at the time this was written).  

Open the zip file and extract the two files to the files (ManagedFusion.Rewriter.dll and ManagedFusion.Rewriter.pdb) to a new directory name bin in the ReverseProxy site's root location.

Setup a Url Rewriter web.config
In order for the new website to use the Url Rewriter code a web.config must be created and the proper references to Url Rewriter must be added. It boils down to adding a config section for the rewriter dll, specifying where the configuration file exists, and adding the rewriter as an Http Module. The simplest thing to do is to download the example web.config that I have already created. (Make sure you rename the web.config.txt to web.config before attempting to use it)

<?xml version="1.0"?>
      <section name="managedFusion.rewriter" type="ManagedFusion.Rewriter.Configuration.ManagedFusionRewriterSectionGroup"/>
  <managedFusion.rewriter xmlns="">
    <rules engine="Apache">
      <apache defaultFileName="ManagedFusion.Rewriter.txt" />
      <proxy useAsyncProxy="true" />
      <add name="RewriterModule" type="ManagedFusion.Rewriter.RewriterModule, ManagedFusion.Rewriter"/>

A more in-depth explanation of these configuration changes can be found here on the Url Rewriter website.

Create the Reverse Proxy Configurations
This final step is what actually configures the reverse proxy to route traffic to the appropriate web server. This is done using the same syntax used by Apache's mod_rewrite (I'm not an Apache expert, so this part actually threw me for a while). Simply create a file named ManagedFusion.Rewriter.txt in the root of the ReverseProxy site. Open the file and add the following lines:
RewriteEngine On

# redirect to another server based upon the domain name
RewriteCond %{HTTP_HOST} ^
RewriteRule ^/(.*) http://Server2:8081/$1 [P]

# Send all other requests here.
RewriteRule ^/(.*) http://Server1:8080/$1 [P]
These lines tell the Url Rewriter to redirect all traffic directed at to go to Server2 on port 8081 and all other traffic to go to Server1 on port 8080. You can add additional url -> server mappings by simply adding more RewriteCond and RewriteRule lines similar to  

You can also download the example ManagedFusion.Rewriter.txt that I have created and modify it to fit your environment.

Once you have done this once, you should find it fairly straight forward. The impact to existing infrastructure is minimal, and the flexibility is outstanding. Since the Url Rewriter implements the mod_rewrite syntax from the Apache web server, this means that moving to or from Apache should be a breeze.  

I'm excited about this new configuration we have at our office, and will be moving some of our clients to it shortly. I can't wait!

Labels: , , , , ,

Yubico Provider Alpha Release

I happy to announce that first release of the Yubico .NET Membership Provider!  The alpha release of the provider validates Yubikey one-time passwords against Yubico's public validation servers.  This realease can be easily integrated into ASP.NET websites to provide simple Yubikey authentication.

The Yubico .NET Membership Provider source code is now hosted on Google Code and is provided with the open source GPLv3 license.  You can also visit the project wiki for more detailed technical information.

Download Yubico .NET Membership Provider (Alpha)

Labels: , , ,

Yubico .NET Membership Provider

After recently receiving my first Yubikey in the mail I was so inspired by device that I decided to do a little development against it. One of the most obvious uses of the Yubikey is for authentication of web site users. After a few minutes of searching the web I was unable to find an existing .NET membership provider. With the lack of an existing provider and the new Yubico Yubiking contest in full swing, I decieded to take on the creation of a Yubikey membership provider myself.

The goal of the Yubico .NET Membership Provider is to implement the Yubikey authentication using the standard .NET Membership Provider Model. This will allow any developer using ASP.NET to easily add Yubikey functionality to their site.

When complete the Yubico .NET Membership Provider should allow authentication of Yubikeys against either the public Yubico validation server or a private validation server. It should also allow for configuration of single, or multi-factor authentication.

I truely believe that the Yubikey is finally making advanced security accessible. I'm looking forward to showing it off to my clients and seeing their reaction. I'll post more information about the progress of the project as it unfolds.

Labels: , , ,

CSS  |  XHTML 1.1