XFF redirects here. For the aircraft, see Grumman FF

The X-Forwarded-For (XFF) HTTP header is a de facto standard for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer. This is a non-RFC-standard request header which was introduced by the Squid caching proxy server's developers.

In this context, the caching servers are most often those of large ISPs who either encourage or force their users to use proxy servers for access to the World Wide Web, something which is often done to reduce external bandwidth through caching. In some cases, these proxy servers are transparent proxies, and the user may be unaware that they are using them.

Without the use of XFF or another similar technique, any connection through the proxy would reveal only the originating IP address of the proxy server, effectively turning the proxy server into an anonymizing service, thus making the detection and prevention of abusive accesses significantly harder than if the originating IP address was available. The usefulness of XFF depends on the proxy server truthfully reporting the original host's IP address; for this reason, effective use of XFF requires knowledge of which proxies are trustworthy, for instance by looking them up in a whitelist of servers whose maintainers can be trusted.

[edit] Format

The general format of the header is:

X-Forwarded-For: client1, proxy1, proxy2

where the value is a comma+space separated list of IP addresses, the left-most being the farthest downstream client, and each successive proxy that passed the request adding the IP address where it received the request from. In this example, the request passed proxy1, proxy2 and proxy3 (proxy3 appears as remote address of the request).

Since it is easy to forge an X-Forwarded-For header the given information should be used with care. The last IP address is always the IP address that connects to the last proxy, which means it is the most reliable source of information. X-Forwarded-For data can be used in a forward or reverse proxy scenario.

In a forward proxy scenario you can track the real client IP on your network through an internal proxy chain and log that IP address on a gateway device. For security reasons, your gateway device should strip any X-Forwarded-For before sending the request to the Internet. You should be able to trust X-Forwarded-For information in this scenario as it is all generated within your network.

In a reverse proxy scenario you can track the real IP of a client on the Internet accessing your web server, even if your web server is not routable from the Internet - i.e. it is behind a layer 7 proxy device. You should NOT trust all X-Forwarded-For information in this scenario as you may have received bogus information from the Internet. As such a trust list should be used to make sure that proxy IP's in the X-Forwarded-For header are trusted by you.

Just logging the X-Forwarded-For header is not always enough as the last proxy IP in a chain is not contained within the X-Forwarded-For header, it is in the actual IP header. A web server should log BOTH the request's source IP and the X-Forwarded-For header information for completeness.

[edit] Proxy servers and caching engines

X-Forwarded-For header is supported by most proxy servers, including Squid,^[1] Apache mod_proxy,^[2] Pound,^[3]ha-proxy, ^[4] Varnish cache,^[5] IronPort Web Security Appliance,^[6],CAI Networks WebMux, Radware's Appdirector and Web Server Director, F5 Big-IP, ^[7] Blue Coat ProxySG ^[8], Cisco Cache Engine, Phion Airlock, Finjan's Vital Security, NetApp NetCache, jetNEXUS, Crescendo Networks' Maestro, and Microsoft ISA Server 2004/2006 with Winfrasoft X-Forwarded-For for ISA Server.^[9]

X-Forwarded-For header logging is supported by many web servers including Apache. Microsoft IIS 6.0 & 7.0 can use a third party ISAPI filter to accomplish this task.

[edit] Load balancers

Citrix Systems' NetScaler supports user-defined header tags such as X-Forwarded-For to insert the client IP address into a client request. ^[10]

Cisco Ace Load Balancing Modules can also insert this header, usually implemented when the load balancer is configured to perform source NAT, to allow the load balancer to exist in a one-armed configuration, while providing a mechanism that the real servers can use to account for client source IP. The reference mentions x-forward, however X-Forwarded-For can be substituted. ^[11]

CAI Networks load balancers support x-forwaded-for for one-armed single network configurations.

F5 Networks load balancers support x-forwaded-for for one-armed and multi-armed configurations.

KEMP Technologies LoadMaster supports X-Forwarded-For for non-transparent load balancing in both one-armed configuration and multi-armed configurations. ^[12]

Radware ODS devices support this Header as well.

Coyote Point Systems Equalizer supports X-Forwarded-For headers for load balancing in both one-armed configuration and multi-armed configurations. ^[13]

OpenBSD relayd can insert and/or alter this header. ^[14]

[edit] See also

• Internet privacy
• List of proxy software

[edit] References

1. ^ SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki
2. ^ mod_proxy - Apache HTTP Server
3. ^ ha-proxy configuration
4. ^ Pound proxy, under "Request Logging"
5. ^ Varnish FAQ regarding logging
6. ^ IronPort Web Security Appliances
7. ^ Using "X-Forwarded-For" in Apache or PHP
8. ^ Bluecoat Knowledge Base Article 2996
9. ^ Winfrasoft X-Forwarded-For for ISA Server, - supports logging, forward and reverse proxy.
10. ^ Citrix NetScaler Traffic Management Guide - Release 9.1
11. ^ Cisco ACE with Source NAT and Client IP Header
12. ^ LoadMaster Product Manual
13. ^ Equalizer User Guide
14. ^ relayd.conf manual page

[edit] External links

• Apache mod_extract_forwarded