There are times when you need to reverse proxy through a server.
The most common example is when you have an internal web server that isn’t exposed to
the internet, and you have a public web server accessible to
the internet. If you want to serve up traffic from
the internal web server, you can do this through
the public web server by creating a tunnel (aka reverse proxy). Essentially, you can front
the internal web server with a friendly URL, even hiding custom ports. For example, consider an internal web server with a URL of http://10.10.0.50:8111. You can make that available through a public URL like http://tools.mysite.com/ as seen in
the following image.
The URL can be made public or it can be used for your internal staff and have it password protected and/or locked down by IP address. This is easy to do with URL Rewrite and
IIS. You will also need Application Request Routing (ARR) installed even though for a simple reverse proxy you won’t use most of ARR’s functionality. If you don’t already have URL Rewrite and ARR installed you can do so easily with
the Web Platform Installer. A lot can be said about reverse proxies and many different situations and ways to route
the traffic and handle different URL patterns. However, my goal here is to get you up and going in
the easiest way possible. Then you can dig in deeper after you get
the base configuration in place. URL Rewrite makes a reverse proxy very easy to set up. Note that
the URL Rewrite Add Rules template doesn’t include Reverse Proxy at
the server level. That’s not to say that you can’t create a server-level reverse proxy, but
the URL Rewrite rules template doesn’t help you with that. Getting Started First you must create a website on your public web server that has
the public bindings that you need. Alternately, you can use an existing
site and route using conditions for certain traffic. After you’ve created your
site then open up URL Rewrite at
the site level. Using
the “Add Rule(s)…” template that is opened from
the right-hand actions pane, create a new Reverse Proxy rule. If you receive a prompt (the first time) that
the proxy functionality needs to be enabled, select OK. This is telling you that a proxy can route traffic outside of your web server, which happens to be our goal in this case. Be aware that reverse proxy rules can be dangerous if you open sites from inside you network to
the world, so just be aware of what you’re doing and why.
The next and final step of
the template asks a few questions.
The first textbox asks
the name of
the internal web server. In our example, it’s 10.10.0.50:8111. This can be any URL, including a subfolder like internal.mysite.com/blog. Don’t include
the http or https here.
The template assumes that it’s not entered. You can choose whether to perform SSL Offloading or not. If you leave this checked then all requests to
the internal server will be over HTTP regardless of
the original web request. This can help with performance and SSL bindings if all requests are within a trusted network. If
the network path between
the two web servers is not completely trusted and safe then uncheck this. Next,
the template enables you to create an outbound rule. This is used to rewrite links in
the page to look like your public domain name rather than
the internal domain name. Outbound rules have a lot of CPU overhead because
the entire web content needs to be parsed and updated. However, if you need it, then it’s well worth
the extra CPU hit on
the web server. If you check
the “Rewrite
the domain names of
the links in HTTP responses” checkbox then
the From textbox will be filled in with what you entered for
the inbound rule. You can enter your friendly public URL for
the outbound rule. This will essentially replace any reference to 10.10.0.50:8111 (or whatever you enter) with tools.mysite.com in all <a>, <form>, and <img> tags on your
site. That’s it! Well, there is a lot more that you can do, this but will give you
the base configuration. You can now visit www.mysite.com on your public web server and it will serve up
the site from your internal web server. You should see two rules show up; one inbound and one outbound. You can edit these, add conditions, and tweak them further as needed. One common issue that can occur without outbound rules has to do with compression. If you run into errors with
the new proxied
site, try turning off compression to confirm if that’s
the issue. Here’s a link with details on how to deal with compression and outbound rules. I hope this was helpful to get started and to see how easy it is to create a simple reverse proxy using URL Rewrite for
IIS.
