Skip to Content

The Reverse Proxy Series — Part 1: Introduction

The term “proxy server” usually refers to a forward proxy, like the ones people use to connect to the Internet in corporate networks. A forward proxy is (usually) simply a gateway between end-users and the Internet. Besides forwarding requests it might also provide other functionalities, such as content caching and filtering. Most commonly a forward-proxy will be a gateway from a LAN to a WAN.

A reverse-proxy (as its name implies…) works the other way around – it’s a gateway between a WAN and a LAN. One key difference is that if you connect to a host via a forward-proxy you are aware that you’re using a forward-proxy (you can simply look at your browser’s proxy settings, or use a network-sniffer to see that the request is sent to the forward-proxy and not to the host itself). On the other hand if you connected to a site in which a reverse-proxy has been installed you’ll never know it. As far as you’re concerned the reverse-proxy is the site.

What do we need this for? Say you have a SAP EP installed in your LAN and you want to make it available through the Internet. While technically you could enable direct access from the Internet to the portal server inside the LAN, you’ll have to be bordering on lunacy to do that due to the security implications of such a move. One might suggest putting the portal server in the DMZ and allow direct access to it – while that’s a better scenario then allowing direct access to the LAN from the outside it still puts the portal server in harm’s way since people can directly access it.

The preferable solution would be to put a reverse-proxy in the DMZ and all the rest of the components in the LAN. This means that external users can only connect to the reverse-proxy (using the standard HTTP port 80, so no additional or non-standard ports need to be open in the firewall), and the reverse-proxy will take care of forwarding the requests and (transparently) sending them back as if it was the content server itself. Aside from the security benefits other reasons to install a reverse-proxy are:

  1. If you want to use clear-text communication in the LAN and SSL from the ouside you can terminate SSL at the reverse-proxy
  2. You can cache static (and sometimes non-static) content on the reverse-proxy
  3. To enable special authentication methods (such as Integrated Windows Authentication)

A reverse-proxy can be implemented using software (SAP Web Dispatcher, Apache, Squid, IIS with extensions) or hardware (such as Novell iChain). In the following sections I’ll discuss only software solutions, although the general concepts usually apply to hardware solution as well.

Things I’ll discuss in this series:

  1. Configuring a reverse-proxy using IIS with SAP’s IISProxy extension, for IIS 5 and IIS 6 (The Reverse Proxy Series — Part 2: IIS as a reverse-proxy)
  2. Configuring a simple and complex reverse-proxy scenario using Apache’s HTTP server
  3. Configuring the J2EE Web AS to play nicely with the reverse-proxy
  4. Things to consider when configuring SSL termination at the reverse-proxy
  5. Design-time considerations — what you can do when planning a solution to make sure it’ll work well behind a reverse-proxy
You must be Logged on to comment or reply to a post.
  • Hi Alon,
      Will your series include using web dispatcher as a reverse proxy?

    Plz do include the following:
      If there is a webdispatcher (with SSL termination) installed and configured. what additional configurations are to be made to make it a proxy/reverse proxy?

    Sai Krishna.

    • Hello Megha.

      As far as I know the SAP Web Dispatcher does not provide full reverse-proxy capabilities — it’s more of a load-balancer. I don’t have much experience with it. This question has been asked several times   — there is a blog in SDN showing how to make the SAP WD work. I’ll look into it when I have some free time, though I don’t think it’s a reverse-proxy solution at this moment.


    • Hello Piyush.

      I don’t have access to IBM WebSeal to learn how to configure it. You can take the configuration ideas from IIS and Apache and apply them there, shouldn’t be that different.

      Good luck!

  • Alon, we’re looking for some help with a hardware based reverse proxy solution from F5 Networks called BigIP.  We’ve worked out the kinks to get our DEV enviornment working through it but our PROD environment has a lot of failover built into it and we could use an expert like you.  The project is located near Washington DC USA… any chance we can get you over here for a week?  Send an email to me if you can and we’ll discuss details.  bkibbey [at]
  • Hi Alon,

    I have going through your blogs.
    We have a scenario where a application would be trying to access the ECC server for some details and their request URL will contain Dynamic parameters.
    The uRL will be like
    where opid and cli values will be diffrent for each request.
    So far we have gathered that its not feasible using SAP Web dispatcher.
    Please let me know if you have idea on handling this with APache reverse proxy or even SAP Web dispatcher.