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 (www.example.com, mail.example.com) 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: urlrewriter.codeplex.com. 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"?>
<configuration>
  <configSections>
      <section name="managedFusion.rewriter" type="ManagedFusion.Rewriter.Configuration.ManagedFusionRewriterSectionGroup"/>
  </configSections>
  <managedFusion.rewriter xmlns="http://managedfusion.com/xsd/managedFusion/rewriter">
    <rules engine="Apache">
      <apache defaultFileName="ManagedFusion.Rewriter.txt" />
    </rules>
    <rewriter>
      <proxy useAsyncProxy="true" />
    </rewriter>
  </managedFusion.rewriter>
  <system.web>
    <httpModules>
      <add name="RewriterModule" type="ManagedFusion.Rewriter.RewriterModule, ManagedFusion.Rewriter"/>
    </httpModules>
  </system.web>
</configuration>

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
# mail.example.com
RewriteCond %{HTTP_HOST} ^mail.example.com
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 mail.example.com 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 mail.example.com.  

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

Conclusion
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: , , ,




Avoid the Oh-no factor when sending email

How many times have you clicked Send on an email only to regret it moments later?  There is no undo in email, but if you are using Microsoft Outlook here's the next best thing.

Fire up Outlook, and from the Tools menu select Rules and Alerts.  From the "Rules and Alerts" window click the New Rule button.

Step1

Select the last template in the list, Check messages after sending and click the Next button.

Step2

This rule does not require anything conditions from the "Which condition(s) do you want to check" step so just click the Next button again.  You will be warned that "The rule will apply to every message you send" click Yes when prompted.

Step3

On the "What do you want to do with the message" step select the last option in the list "defer delivery by a number of minutes".  Click on "a number of" and specify how long to wait before sending messages, and click the Next button. 

 Step4

At the "Are there any exceptions" step check the "except if it is marked as importance" option.  Click on "importance" and select "High" from the drop-down list and click the Next button.

Step5

Finally at the "Finish rule setup" step name the rule "Delay outgoing messages for 5 minutes" or something that provides you similar understanding of the rule.  Click the Finish button to complete the rule.

Step6

That's it!  Now any new email you create will remain in the Outlook outbox for 5 minutes before being sent.  This should give you enough time to edit a message if you decide you have made a mistake. 

Don't worry about setting the delay to less than 5 minutes, or turning off the rule for time-sensitive email.  If you have something urgent simply mark it as a message of HighImportance high importance and it will be sent immediately, bypassing any delay.




Auto-start Virtual Server Guest OS

I have been using Virtual Server 2005 R2 for a few months now and have been quite pleased with it's performance and manageability.  The server is used primarily to replicate environments for clients that would otherwise require a lot of different hardware to support. 

When the server was recently upgraded I discovered that our virtual machines were not configured to start automatically.  Although this seems like a simple configuration there are a few tricks that alluded me at first.

Here are the steps required to have a virtual machine start up automatically when the Virtual Server host starts:

  • Launch the Virtual Server Administration Website
  • If it is already running, shut down the virtual machine you would like to start automatically.
  • Go to the configuration screen for the virtual machine and click the "General Properties" link.
  • Check the "Run virtual machine under the following user account" check box
  • Enter a user name and password.  I simply used the administrator account.
  • Change the "Action when Virtual Server start" to "Always automatically turn on virtual machine".
  • Change the "Action when Virtual Server" stops to "Shut down guest OS".
  • Click the "OK" button to save your changes
  • There are two of these steps in particular that were confusing for me.  The first being the requirement to use a specified username and password.  As I understand it, a virtual machine is run under the permissions of the user who starts it.  By specifying a user account you are specifying are essentially telling Virtual Server which account to use when this process is automated.  For more information read this TechNet article.

    The second confusion was setting the "Action when Virtual Server" stop to "Shut down guest OS".  This was originally set to "Save State" but this setting will not resume the guest OS loses power, as the virtual machine's state was never saved.  If you stick with "Shot down guest OS" you should avoid any potential problems.




    Setting up iSCSI on Windows Server

    Recently I took on the challenge of converting some of my home server disk space to iSCSI SAN storage.  While this may seem like overkill for a household network (and you may be right), I had several reasons that drove me to this solution.  However, the main reason and the focus of this article was to simplify network storage for my Windows Vista Media Center setup.

    In my case I wanted to add additional storage to my living room Media Center PC.  I had been toying with the idea for sometime, but had only limited success configuring Media Center to use a network location for it's television recording storage.  The advantage that an iSCSI SAN provided was that any storage pools appear to the Media Center PC as a local drive.  With this goal in mind I set off into the unknown ...

    After several nights of research, a few false starts, and a load of caffeine I came up with a workable solution.  Here is a quick breakdown of the software I used:

    • Microsoft Windows Server 2008
    • Microsoft Windows Visa Ultimate
    • Rocket Division StarWind
    • iSCSI Initiator

    Windows Server is not required and there are quite a few different ways this could be configured, but this is the setup I had on hand at the time. 

    The basic plan of action was to use a spare hard drive in the server as an iSCSI target, point the living room PC to this target, then configure Vista Media Center to use the new storage.

    1. Install StarWind on the server.
    2. Configure storage on the server as an iSCSI target.
    3. Configure iSCSI Initiator on the client PC.
    4. Configure applications to use new storage location.

    What is a Target and What is an Initiator?
    In the iSCSI world a "target" is the storage being served.  The "initiator" is the client requesting access to the target storage.  In the example illustrated here the target is the stored shared by the Windows Server 2008.  The initiator is the Windows Vista Media Center.

     

    Setting up the Server
    The server setup starts by downloading and installing the iSCSI target software.  Rocket Division provides a great solution StarWind that will do exactly what is needed.  Even better this software is completely free for our basic needs. 

    I downloaded StarWind and installed the application on my Windows Server 2008 machine.  The setup is straight forward, and I had no problems what so ever.  Once installed, I fired up the StarWind program and then commenced scratching my head.  Fortunately once I determine what needed to be done, the process proved to be quite simple.

    Login to the Default Connection
    When you look at main screen of StarWind for the first time you should see just the basic information.  At this point there isn't much you can do.  The trick is to right-click "localhost:3260" and select "Connect".  When prompted for a username and password enter "test" into both fields and click the OK button.  Once the connection has been established devices (storage) need to added.

    StarWind01

    Add a Device
    Adding a device is the process of assigning storage space to the iSCSI connection.  This is the space that will become a local drive on a client machine.  To add a device simply right-click on the connection "localhost:3260" and select "Add Device".  From the "Device type selection" window choose Disk Bridge device.  This will assign an entire physical hard drive as an iSCSI target.

    StarWind02

    There are quite a few different choices for the type of device to assign.  I had a new drive I wished to allocate entirely to my media center.  If you wish to use only a portion of a drive you could use an "Image File device" instead.  This creates the iSCSI target within a single file on the server.  You can specify the file size and even enlarge if you decide you need more storage in the future.

    Next you must select the physical drive you would like to assign as a target.  Make sure you verify the physical drive number in the Disk Management because PhysicalDrive0 may not be your C:\ drive.  You want to be sure not to specify your C:\ system drive since the local system will no longer be able to access the targeted drive.

    StarWind03

    Finally you can name the device.  I gave mine the simple name of "Data", just to ensure that I knew which device was the one I just created.  After the device is created successfully you should be directed back to the main StarWind screen, only now the new device you added should display below the "localhost:3260" connection.

    StarWind04 StarWind05

     

    Setting up the Media Center PC
    The client PC setup really just consists of configuring the storage using Microsoft's iSCSI Initiator program.  This application is included in Windows Vista, but it can be downloaded free for use with other Microsoft operating systems.

    Add a Target Portal
    The first thing to do when you run the iSCSI Initiator is to select the "Discovery" tab and configure a target portal.  The target portal is the machine hosting the iSCSI storage, in our case the Windows Server 2008 machine running StarWind.  Simply click the "Add Portal" button enter the network name or IP address of the target portal and click "OK". 

    iSCSIInitiator01 iSCSIInitiator02

    Add a Target
    Once the target portal has been assigned, select the "Targets" tab.  This should now display any iSCSI target devices you have added to the target portal.  In our example, an iSCSI target named "data" should display.  Highlight the desired target and click the "Log on" button.  Check "Automatically restore this connection when the computer restarts", and click "OK".

    iSCSIInitiator03 iSCSIInitiator04

    Assign a Drive Letter
    Once the target has been configured, a new drive letter should automatically be drive be assigned.  Once you verify the storage is available you can permanently assign that drive letter by selecting the "Volumes and Devices" tab and clicking the "Autoconfigure" button.  This step will reduce confusion as it ensures that the drive letter will not change.

    iSCSIInitiator05

    Configuring Media Center
    Once I completed the iSCSI configuration on both my Windows Server 2008 and on my Windows Vista PC I was able to move my Media Center recording over to the new drive.  I then added the new drive letter as a location for Recorded TV from the Media Center application.  No special configurations or hacks to Media Center were necessary because the storage appeared as if it were a local hard drive.  Media Center now goes about it's way happily never caring that the data is stored on another computer in my office upstairs.

     

    Summary
    So after overcoming the unknown factor of the iSCSI world the actual process is quite simple.  I have repeated this process for several other storage solutions I have been needing.  The setup is simple and the solution can resolve a wide variety of issues.  I hope this walk though will break down the barrier to entry for others who may wish to use some of this more advanced technology, without becoming an enterprise network administrator.




    CSS  |  XHTML 1.1