F5 – Leveraging the X-Forwarded-For HTTP Header to Preserve Original Client IP Address in SNAT Traffic

When managing web servers, especially in situations where monitoring or logging is vital, accurately recording the original client IP address of incoming traffic can be crucial. In network setups involving a Source Network Address Translation (SNAT) object, the actual client IP address is typically replaced by the SNAT address. While this is the intended behavior for ensuring network address translation, it presents a challenge for administrators needing to record the client’s IP address. However, a practical solution exists to navigate this challenge – using the X-Forwarded-For HTTP header.

Problem

A SNAT object maps the original client IP address to a translation address in a BIG-IP system. Consequently, when the BIG-IP system receives a request from a client IP address defined in a SNAT, it translates the source IP address of the incoming packet to the SNAT address.

For web servers, this translation results in the server perceiving the request as originating from the SNAT address, not the original client IP address. This behavior becomes problematic when the web server needs to log the client’s IP address for requests.

Solution: X-Forwarded-For HTTP Header

The X-Forwarded-For HTTP header allows insertion of the original client IP address. By configuring the BIG-IP system to insert the client IP address into the X-Forwarded-For HTTP header, web servers can be further configured to log the client IP address from the header instead of the SNAT address.

It is important to note that the BIG-IP system inserts only a single X-Forwarded-For header. If the header already exists in the request, the system appends the client IP address to the end.

Implementation: Two Methods

There are two methods available for configuring the BIG-IP system to insert the original client IP address into the X-Forwarded-For HTTP header:

1. Enabling the Insert X-Forwarded-For option in the HTTP profile: This is done through the Configuration utility, navigating to Local Traffic > Profiles > HTTP, and selecting the Insert X-Forwarded-For checkbox.

2. Using an iRule to insert the original client IP address into the X-Forwarded-For HTTP header: This involves creating a new iRule with the Configuration utility, navigating to Local Traffic > iRules, and using the following iRule as the definition:

when HTTP_REQUEST {
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}

Configuring the Web Server to Extract IP Address from HTTP Header

After configuring the BIG-IP system to insert the original client IP address into the X-Forwarded-For HTTP header, the next step involves configuring the webserver to extract the IP address from the HTTP header and then log this IP address to the server log file. Different webservers require different configuration directives, some of which are briefly mentioned here:

1. NGINX: The configuration involves adding the `set_real_ip_from` and `real_ip_header` directives to the relevant configuration files. The former directive takes the SNAT IP or floating self IP address used by the BIG-IP system when sending the request to the NGINX server, while the latter directive uses the X-Forwarded-For header.

2. Apache/Apache2: The configuration involves adding logging directives to the main Apache configuration file (typically named httpd.conf) or to the relevant virtual host configuration files.

3. Microsoft IIS: See below.

Conclusion

By configuring the X-Forwarded-For HTTP header to include the original client IP address, administrators can ensure that web servers log the correct client IP address, regardless of SNAT address translation. This provides valuable data for analytics, monitoring, and other log-related tasks.

IIS Configuration:

1. Launch IIS Manager UI (alternately, On an elevated command prompt, type inetmgr.exe)
2. Double-click “Logging
3. Click “Select Fields
4. Click “Add Field
5. In the Add Custom Field window, type as follows

iis10-xforward.png