Applies To:
Show VersionsBIG-IP AAM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP APM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP GTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP Link Controller
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP Analytics
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP LTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP AFM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP PEM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
BIG-IP ASM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Configuring the BIG-IP System as a Reverse Proxy Server
Overview: URI translation and HTML content modification
For environments that use web servers, you might want your websites to appear differently on the external network than on the internal network. For example, you might want the BIG-IP® system to send traffic destined for http://www.siterequest.com/ to the internal server http://appserver1.siterequest.com/ instead. Normally, this translation could cause some issues, such as the web server expecting to see a certain host name (such as for name-based virtual hosting) or the web server using the internal host name and/or path when sending a redirect to client systems. Fortunately, you can configure the BIG-IP system to solve these problems.
You can also configure the BIG-IP system to modify HTML content as needed after the system has performed the URI translation.
This implementation describes an example of URI translation and HTML content modification and then provides the tasks to implement this example.
About URI translation
You can configure the BIG-IP® system to perform URI translation on HTTP requests. Suppose that a company named Siterequest has a website www.siterequest.com, which has a public IP address and a registered DNS entry, and therefore can be accessed from anywhere on the Internet.
Furthermore, suppose that Siterequest has two application servers with private IP addresses and unregistered DNS entries, inside the company's firewall. The application servers are visible within the internal network as appserver1.siterequest.com and appserver2.siterequest.com.
Because these servers have no public DNS entries, any client system that tries to access one of these servers from outside the company network receives a no such host error.
As the illustration shows, you can prevent this problem by configuring the BIG-IP system to act as a reverse proxy server:
The BIG-IP system as a reverse proxy server for URI translation
In the example, the company Siterequest has decided to enable Web access to the internal application servers, without exposing them to the Internet directly. Instead, the company has integrated the servers with the web server siterequest.com so that http://www.siterequest.com/sales is mapped internally to http://appserver1.siterequest.com/sales, and http://siterequest.com/marketing is mapped internally to http://appserver2.example.com/marketing. This is a typical reverse-proxy configuration.
To configure the BIG-IP system to perform this translation, you create a Rewrite profile and configure one or more URI rules. A URI rule specifies the particular URI translation that you want the BIG-IP system to perform. Specifically, a URI rule translates the scheme, host, port, or path of any client URI, server URI, or both. A URI rule also translates any domain and path information in the Set-Cookie header of the response when that header information matches the information in the URI rule.
Rules for matching requests to URI rules
The BIG-IP® system follows these rules when attempting to match a request to a URI rule:
- A request does not need to match any entry. That is, if no entries match and there is no catch-all entry, then the Rewrite profile has no effect.
- Each request matches one entry only, which is the entry with the most specific host and path.
- If multiple entries match, then the BIG-IP system uses the entry with the deepest path name on the left side of the specified mapping.
- The BIG-IP system matches those requests that contain host names in URIs before matching requests that do not contain host names in URIs.
- The BIG-IP system processes the specified entries in the mapping from most-specific to least-specific, regardless of the order specified in the actual Rewrite profile.
About URI Rules
When creating a URI rule, you must specify the client and server URIs in these ways:
- When the URI is a path prefix only, the path must be preceded by and followed by a /, for example, /sales/.
- When the URI contains more than the path prefix (such as, a host), the URI must also contain a scheme and must be followed by a /, for example, http://www.siterequest/sales/.
Introduction to HTML content modification
When you configure an HTML profile on the BIG-IP® system, the system can modify HTML content that passes through the system, according to your specifications. For example, if you want the BIG-IP system to detect all content of type text/html and then remove all instances of the HTML img tag with the src attribute, you can configure an HTML profile accordingly, and assign it to the virtual server. The HTML profile ensures that the BIG-IP system removes those instances of the tag from any HTML content that passes through the virtual server.
Or, you can configure an HTML profile to match on a certain tag and attribute in HTML content when a particular iRule event is triggered, and then create an iRule that includes a command to replace the value of the matched attribute with a different attribute. The BIG-IP system includes several iRule commands that you can use when the Raise Event on Comment or Raise Event on Tag events are triggered. For more information on iRule commands related to HTML content modification, see the F5 Networks web site http://devcentral.f5.com.
HTML tag removal and replacement are just two of several HTML rules that you can configure to manipulate HTML content. An HTML rule defines the specific actions that you want the BIG-IP system to perform on a specified type HTML content.
Task summary
The first step to configuring the BIG-IP® system to act as a reverse proxy server is to create a Rewrite type of profile on the BIG-IP system and associate it with a virtual server. Note that each virtual server must have an HTTP profile. The Rewrite profile is designed for HTTP sites, as well as HTTPS sites where SSL is terminated on the BIG-IP system (that is, the virtual server references a Client SSL profile).
Task List
Creating a Rewrite profile to specify URI rules
To configure the BIG-IP® system to perform URI translation, you create a Rewrite profile, specifying one or more URI rules that associate a client-side path with a server-side URI. You also specify whether you want the URI translation to pertain to HTTP requests, responses, or both.
Creating an HTML profile for tag removal
You create an HTML profile when you want the BIG-IP® system to act on certain types of HTML content.
Creating pools for processing HTTP traffic
Creating a local traffic policy
Creating a virtual server
Implementation results
After you perform the tasks in this implementation, the BIG-IP® system can:
- Translate URIs according to the URI rules specified in the Rewrite profile.
- Modify specified HTML content according to the HTML rule specified in the HTML profile.
- Forward HTTP traffic to two different non-default pools according to a local traffic policy.