Discussion

Web Access 10 in reverse proxy with IIS in DMZ

Web Client How To

Updated April 27, 2022

posted on February 26, 2016 • Show version history

I wanted to share my solution for getting Web Access 10 to work with a reverse proxy in the DMZ because it took me a long time to find the solution.

The reason for this is to give access to Laserfiche Web Access to external users in a secure way and allow windows authetification even if the server is in the DMZ. The only way specified in the documentation for getting Web Access to work with windows authetification in the DMZ is to setup a read-only domain controller in the DMZ and join the server hosting web access in the DMZ to that domain. That's a lot of work, setting up a revese proxy is much simpler once you know how to do it.

In this scenario I have a server hosting Web Access in my domain not in the DMZ and I have another server that reside in the DMZ and IIS is installed on that server. The goal is to setup a reverse proxy between the two server.

First step is to install URL Rewrite and Application Request Routing on both server.

http://www.iis.net/downloads/microsoft/url-rewrite

http://www.iis.net/downloads/microsoft/application-request-routing

(some detail instruction here:http://www.wrapcode.com/infrastructure/configure-reverse-proxy-with-url-rewrite-and-arr-for-iis/ )

Second step is to activate ARR on both server.

Open IIS manager. Double click on Application Request Routing Cache menu in center pane. If you don’t see it, you’ve not installed it properly. Repeat the above steps or reboot the system, sometimes it helps. You’ll find Server Proxy Settings on right pane. Open it and check Enable Proxy option.

All the other steps are done on the server in the DMZ:

Next step is to change the default web proxy configuration (If you do not change this you will get a popup for authetification on the login screen and you will get an access denied):

Open a command prompt as admin and run the following commands:

C:\Windows\System32\inetsrv\appcmd.exe set config -section:system.webServer/proxy /preserveHostHeader:"True" /commit:apphost
C:\Windows\System32\inetsrv\appcmd.exe set config -section:system.webServer/proxy /reverseRewriteHostInResponseHeaders:"False" /commit:apphost

iisreset

Next you need to set up the server variables in the URL Rewrite:

You’ll find URL Rewrite option in root level (computer name) as well as in added website. If you want to configure reverse proxy for all the requests coming to IIS, follow next procedure on root level URL rewrite otherwise do it on per website level. Open URL Rewrite by double clicking on it.

If you look at right pane in URL Rewrite settings, you’ll find server variables option. Open it and add following variables to avoid gzip and https related issues.

HTTP_ACCEPT_ENCODING

HTTP_X_ORIGINAL_ACCEPT_ENCODING

HTTP_CUSTOM

HTTP_HOST

HTTP_MAX_FORWARDS

HTTP_X_ORIGINAL_SERVER_PORT

HTTPS

Next step is to configure the rule in URL rewrite for the reverse proxy. Your web.config file should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="ReverseProxyInboundRule1" stopProcessing="false">
<match url="^laserfiche/(.*)" />
<action type="Rewrite" url="http://IP_ADRESSE_OF_THE_REMOTE_SERVER/laserfiche/{R:1}" />
<conditions>
<add input="{HTTP_HOST}" pattern=".*" />
</conditions>
<serverVariables>
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>
<rule name="ReverseProxyInboundRule2" stopProcessing="false">
<match url="^mobile/(.*)" />
<action type="Rewrite" url="http://IP_ADRESSE_OF_THE_REMOTE_SERVER/mobile/{R:1}" />
<conditions>
<add input="{HTTP_HOST}" pattern=".*" />
</conditions>
<serverVariables>
<set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>
</rules>
<outboundRules>
<rule name="Out" preCondition="ResponseIsHtml1">
<match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://IP_ADRESSE_OF_THE_REMOTE_SERVER/laserfiche/(.*)" />
<action type="Rewrite" value="http{R:1}://MYWEBSITE/laserfiche/{R:2}" />
</rule>
<rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
<match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
<action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
</rule>
<rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
<match filterByTags="A, Area, Base, Form, Img, Input, Link, Script" pattern="^http(s)?://IP_ADRESSE_OF_THE_REMOTE_SERVER/mobile/(.*)" />
<action type="Rewrite" value="http{R:1}://MYWEBSITE/mobile/{R:2}" />
</rule>
<preConditions>
<preCondition name="NeedsRestoringAcceptEncoding">
<add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
</preCondition>
<preCondition name="ResponseIsHtml1" logicalGrouping="MatchAny">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^application/json" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

12 0

Comments 2
Follow-Ups 4

replied on April 27, 2022

This configuration can be applied for Laserfiche forms as well ?

Thanks,

Adib

1 0

replied on August 22, 2017 • Show version history

A couple things I found while implementing this:

1. The command prompt commands at the beginning of the article didn't work for me in Windows Server 2016 Standard. I got errors about it not finding that attribute. I found that the following commands worked:

c:\windows\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -preserveHostHeader:true /commit:apphost
c:\windows\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -reverseRewriteHostInResponseHeaders:false /commit:apphost
iisreset

2. I did NOT install URL Rewrite or ARR on the Web Access server inside the LAN. Did the configuration steps only on the DMZ server. So far so good!

Thanks for the guide my friend.

UPDATE: edited a typo in the code snippet.

1 0

Web Access using a Read Only Domain Controller

Version 9.2

posted on June 7, 2016

Does this work for 9.2? Our Network Engineers know how to setup a Reverse Proxy. It would be great if this worked for 9.2.

0 0

replied on June 7, 2016

This is a general solution that should work with most web applications, including all versions of Web Access.

0 0

replied on June 7, 2016

Awesome. Thank you so much Brian McKeever

0 0

Thanks!

asked on February 26, 2016

First off, thanks for the walk through, I am sure I will find a use for it at a client that requires a DMZ server with minimal access.

My question is since you are just proxying all requests strait to the server, is it much different than just exposing the forms server via http/https from a security stand point?

0 0

replied on February 26, 2016

You can find some information here about the benifits and security of a reverse proxy.

http://mikehadlow.blogspot.ca/2013/05/the-benefits-of-reverse-proxy.html

The Benefits of a Reverse Proxy

A typical ASP.NET public website hosted on IIS is usually configured in such a way that the server that IIS is installed on is visible to the public internet. HTTP requests from a browser or web service client are routed directly to IIS which also hosts the ASP.NET worker process. All the functionality needed to produce the web site is embodied in a single server. This includes caching, SSL termination, authentication, serving static files and compression. This approach is simple and straightforward for small sites, but is hard to scale, both in terms of performance, and in terms of managing the complexity of a large complex application. This is especially true if you have a distributed service oriented architecture with multiple HTTP endpoints that appear and disappear frequently.

A reverse proxy is server component that sits between the internet and your web servers. It accepts HTTP requests, provides various services, and forwards the requests to one or many servers.

font-side-proxy

Having a point at which you can inspect, transform and route HTTP requests before they reach your web servers provides a whole host of benefits. Here are some:

Load Balancing

This is the reverse proxy function that people are most familiar with. Here the proxy routes incoming HTTP requests to a number of identical web servers. This can work on a simple round-robin basis, or if you have statefull web servers (it’s better not to) there are session-aware load balancers available. It’s such a common function that load balancing reverse proxies are usually just referred to as ‘load balancers’. There are specialized load balancing products available, but many general purpose reverse proxies also provide load balancing functionality.

Security

A reverse proxy can hide the topology and characteristics of your back-end servers by removing the need for direct internet access to them. You can place your reverse proxy in an internet facing DMZ, but hide your web servers inside a non-public subnet.

Authentication

You can use your reverse proxy to provide a single point of authentication for all HTTP requests.

SSL Termination

Here the reverse proxy handles incoming HTTPS connections, decrypting the requests and passing unencrypted requests on to the web servers. This has several benefits:

Removes the need to install certificates on many back end web servers.
Provides a single point of configuration and management for SSL/TLS
Takes the processing load of encrypting/decrypting HTTPS traffic away from web servers.
Makes testing and intercepting HTTP requests to individual web servers easier.

Serving Static Content

Not strictly speaking ‘reverse proxying’ as such. Some reverse proxy servers can also act as web servers serving static content. The average web page can often consist of megabytes of static content such as images, CSS files and JavaScript files. By serving these separately you can take considerable load from back end web servers, leaving them free to render dynamic content.

Caching

The reverse proxy can also act as a cache. You can either have a dumb cache that simply expires after a set period, or better still a cache that respects Cache-Control and Expires headers. This can considerably reduce the load on the back-end servers.

Compression

In order to reduce the bandwidth needed for individual requests, the reverse proxy can decompress incoming requests and compress outgoing ones. This reduces the load on the back-end servers that would otherwise have to do the compression, and makes debugging requests to, and responses from, the back-end servers easier.

Centralised Logging and Auditing

Because all HTTP requests are routed through the reverse proxy, it makes an excellent point for logging and auditing.

URL Rewriting

Sometimes the URL scheme that a legacy application presents is not ideal for discovery or search engine optimisation. A reverse proxy can rewrite URLs before passing them on to your back-end servers. For example, a legacy ASP.NET application might have a URL for a product that looks like this:

http://www.myexampleshop.com/products.aspx?productid=1234

You can use a reverse proxy to present a search engine optimised URL instead:

http://www.myexampleshop.com/products/1234/lunar-module

Aggregating Multiple Websites Into the Same URL Space

In a distributed architecture it’s desirable to have different pieces of functionality served by isolated components. A reverse proxy can route different branches of a single URL address space to different internal web servers.

For example, say I’ve got three internal web servers:

http://products.internal.net/
http://orders.internal.net/
http://stock-control.internal.net/

I can route these from a single external domain using my reverse proxy:

http://www.example.com/products/    -> http://products.internal.net/
http://www.example.com/orders/    -> http://orders.internal.net/
http://www.example.com/stock/    -> http://stock-control.internal.net/

To an external customer it appears that they are simply navigating a single website, but internally the organisation is maintaining three entirely separate sites. This approach can work extremely well for web service APIs where the reverse proxy provides a consistent single public facade to an internal distributed component oriented architecture.

So …

So, a reverse proxy can off load much of the infrastructure concerns of a high-volume distributed web application.

1 0

replied on March 9, 2016

Thank you for this informative article. I hope you can answer a couple of questions. Is there any reason this won't work with web access 9.1.1? Do I understand correctly that the certificate needs to be installed on the reverse proxy server only?

0 0

replied on March 10, 2016

None of this is specific to the web application(s) being proxied, so it should work with all versions of Web Access. Yes, the certificate is required on the machine that terminates the HTTPS connection, which is the proxy in this scenario.

1 0

awesome!

Sign in to reply to this post.

Posted February 26, 2016
Updated April 27, 2022
8311 views

0 of 3 Discussions resolved

0 of 1 Question answered

Discussion

Discussion

Web Access 10 in reverse proxy with IIS in DMZ

Comments 2

Follow-Ups 4

Web Access using a Read Only Domain Controller

LF Forms: Notification of task

Version 9.2

Thanks!

awesome!

Sign in to reply to this post.