Skip Headers
Oracle® Real User Experience Insight User's Guide
Release 5.1 for Linux x86-64

Part Number E14821-03
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

I Monitoring NATed Traffic

This appendix provides information about how accurate network traffic reporting can be obtained if the RUEI system is placed after a Network Address Translation (NAT) device.

I.1 Placement Before NAT Devices

As explained in the Oracle Real User Experience Insight Installation Guide, it is critically important that RUEI can see a copy of the network traffic. This can be obtained by using a copy/SPAN port or a TAP device.

Figure I-1 outlines a typical configuration of cascaded devices. While the number of devices can vary from that shown, the sequence is typically that indicated. Sometimes, the firewall, SSL offloader (in the case of SSL encrypted traffic), and load balancer functions are combined into one or two components.

Figure I-1 Placement of Monitoring Device

Description of Figure I-1 follows
Description of "Figure I-1 Placement of Monitoring Device"

In most networks, there are three potential monitoring positions: directly behind (or in front of) the firewall, directly behind the SSL offloader, and directly behind the load balancer. These are indicated in Figure I-1. The implications of the three candidate monitoring positions is outlined in Table I-1.

Table I-1 Monitoring Position Characteristics

Position Server info available Client info available SSL certificates required


Only if in header reply


YesFoot 1 


Only if in header reply





Only if delivered from NAT device in request header


Footnote 1 Note any deployment in front of an SSL offloading point will require the uploading of the SSL keys to the RUEI Collector system(s). This is necessary for RUEI to be able to decrypt the SSL traffic.

For Internet services, the load balancer is listening on the port where external clients connect to access services. It forwards requests to one of the back-end servers, which usually replies to the load balancer. This allows the load balancer to reply to the client without the client ever knowing about the internal separation of functions. It also prevents clients from contacting back-end servers directly, which may have security benefits by hiding the structure of the internal network.

It is recommended a RUEI system is placed in front of any Network Address Translation (NAT) devices. This ensures RUEI is immediately apply to see the originating IP address of the end user on TCP level. While the configuration shown in Figure I-1 can differ between different networks, it is typically the load balancer device that performs NAT.

If RUEI is deployed in a network segment where end-user IP address translation has already taken place, and the configuration procedure described in the following section is not implemented, then the only reported end-user IP address will be the single IP address of the NAT device. While this does not negatively effect the accurancy of the reported data, it does mean that geographic and ISP client information is not available.


Be aware the RUEI monitoring position should always be after any VPN/decompression devices. This is because RUEI cannot read non-HTTP traffic between the encryption and decryption devices.

I.2 Obtaining the End-User IP Address

As explained earlier, obtaining the original end-user IP address is necessary for accurate geographical and ISP client reporting. Within RUEI, the IP address is normally obtained from the IP header packet sent from the client. The header of each IP packet contains, among other things, the numerical source and destination address of the packet. However, if RUEI has been placed after a NAT device, this IP packet will contain the IP address of the NAT device, and not the end-user IP address.

Fortunately, the original (end-user) IP address is normally preserved in the HTTP header sent from the NAT device to the Web server. In this case, you can specify that RUEI should look in this header for the IP address, rather than the IP packet.

To specify the use of an HTTP header, instead of the TCP packet, do the following:

  1. For each required application, select Configuration, then Applications, then Applications, and then the application to which you want to apply the custom setting. The application overview (similar to the one shown in Figure 6-1 appears).

  2. Click the current Client IP address setting. The equivalent menu structure should be followed for suites and Web services. The dialog shown in Figure I-2 appears.

    Figure I-2 Edit Client IP Source

    Description of Figure I-2 follows
    Description of "Figure I-2 Edit Client IP Source"

  3. Use this dialog to specify how the client IP address should be retrieved. If the IP address should be retrieved from the HTTP header you must specify from which element in the header it should be fetched. When ready, click Save.

Any change you make to this setting will become visible in RUEI after five to 10 minutes. In addition, this change only applies to currently collected data, and not to historical data.If RUEI is deployed behind a NAT device, you are strongly recommended to check and verify with both application and infrastructure management teams the appropriate manner to collect the End-User IP address from an HTTP header.

I.3 Obtaining the IP Address of the Replying Web Server

Sometimes, it is also useful to see the replying server's IP address. For example, if an issue with slow or failing pages develops on a server farm, it is much quicker to resolve the issue if the relevant server's IP address is immediately visible.

This can be achieved inserting the replying server's IP address (or other identification information) into the header sent back to the load balancer.

Figure I-3 shows an example of an HTTP header. It is taken from Mozilla Firefox's Live HTTP Headers plug-in, and shows how the original Web server identification (www236) has been moved into the HTTP header.

Figure I-3 Example HTTP Header

Description of Figure I-3 follows
Description of "Figure I-3 Example HTTP Header"

In this example, the header element is called xserver. It can be captured through the use of a custom dimension. This is fully described in Section 3.8, "Defining Custom Dimensions".