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:
- If you want to use clear-text communication in the LAN and SSL from the ouside you can terminate SSL at the reverse-proxy
- You can cache static (and sometimes non-static) content on the reverse-proxy
- 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:
- 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)
- Configuring a simple and complex reverse-proxy scenario using Apache’s HTTP server
- Configuring the J2EE Web AS to play nicely with the reverse-proxy
- Things to consider when configuring SSL termination at the reverse-proxy
- Design-time considerations — what you can do when planning a solution to make sure it’ll work well behind a reverse-proxy