In a network that includes proxies (servers that connect to backend origins on behalf of clients), there is a good chance that the original TCP connection parameters, such as client IP addresses, will be lost at the proxies. Additional challenges will occur when you try to apply security and access-control policies (for example, adding a client IP address for IP allowing/blocking lists on the origin server or performing analytics based on client IP addresses).
How to preserve client IP addresses?
CDNetworks’ High-speed Data Transmission (HDT) accelerates data transmissions through the tunnels built on proxies to address these problems. HDT provides several ways to send client information to the origin server:
X-Forwarded-For (XFF) HTTP Header
The X-Forwarded-For (XFF) HTTP header field is a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy. Consequently, HDT inserts the XFF header in client requests by default to include the original client IP addresses for HTTP traffic.
The general format of XFF field resembles the following:
X-Forwarded-For: client, proxy1, proxy2
Elements are comma separated, with optional whitespace surrounding the commas. The leftmost IP address is the original client IP address followed by the IP addresses for each successive proxy that passed the request (the IP address is added from the proxy where it received the request).
Examples:[3]
X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
X-Forwarded-For: 203.0.113.195
X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348
PROXY Protocol
Unlike HTTP, other protocols may not adopt the same fix. In these cases, the Proxy Protocol, which operates at the Transmission Control Protocol (TCP) layer fills this gap by expanding coverage to any protocols over TCP/IP (for example, SMTP, IMAP, FTP, and proprietary database protocols).
The PROXY protocol adds to the beginning of a TCP connection a header that contains the client’s IP address. The proxy sends a short header after the connection is established, and the receiver parses it when accepted.
PROXY protocol Version 1 focused on keeping IP addresses human-readable to facilitate debugging. Version 2 adds support for a binary encoding of the header, which is more efficient to produce and to parse, especially when dealing with IPv6 addresses that are costly to send in ASCII form and to parse.
HDT has the ability to send both versions of the PROXY protocol header. However, the origin server must be able to accept it, since both sending and receiving ends must support the protocol.
TCP Options field
Another way to preserve the client IP address in the TCP layer is to use the TCP Header Options field. TCP has provisions for optional header fields identified by an option kind field. HDT can add client details in the TCP option 78 field and send it to the back-end server. To retrieve the client information, the back-end server must be configured to accommodate the option field when parsing. For information about how to access the TCP options for TCP traffic through an F5 device, see the article Accessing TCP Options from iRules.
How to enable it on the HDT platform?
Other than XFF for HTTP/HTTPs traffic, which HDT supports by default, you can contact the HDT support team to enable preserving of client IP addresses. The experts of the HDT support team will investigate your concerns and complete the configuration with the best solution for you. By applying a customized configuration, you can get everything done in just a few minutes. It’s that simple!
