O 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.

O.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 O-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 O-1 Placement of Monitoring Device

Description of "Figure O-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 O-1. The implications of the three candidate monitoring positions is outlined in Table O-1.

Table O-1 Monitoring Position Characteristics

Position	Server info available	Client info available	SSL certificates required
1	Only if in header reply	Yes	Yes^Foot 1
2	Only if in header reply	Yes	No
3	Yes	Only if delivered from NAT device in request header	No

^Footnote 1Note 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 O-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.

Note:

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.

O.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 IP packet, do the following:

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. Select the Advanced section, and click the Miscellaneous tab.
Click the current Client IP address setting. The equivalent menu structure should be followed for suites and Web services. The dialog shown in Figure O-2 appears.

Figure O-2 Edit Client IP Source

Description of "Figure O-2 Edit Client IP Source"
Use this dialog to specify how the client IP address should be retrieved. If the IP address should be retrieved from the HTTP header, then 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.

O.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 O-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 O-3 Example HTTP Header

Description of "Figure O-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.9, "Working With Custom Dimensions".