Enter X-Forwarded-For (XFF). This article explores how A10 handles this critical header, how to configure it, and the security pitfalls that come with it. The X-Forwarded-For header is a de facto standard (defined in RFC 7239, though superseded by Forwarded ). Its syntax is a simple comma-separated list:

In the modern data center, the Application Delivery Controller (ADC) sits as the gatekeeper. A10 Networks’ Thunder series is a market leader in this space, performing tasks from server load balancing (SLB) and SSL offload to advanced L7 inspection.

If your backend server reads only the first IP (leftmost) as the client, it will believe the request is coming from 127.0.0.1 (localhost)—bypassing all ACLs.

A10 provides a configuration option to prevent this. Instead of appending, you can configure the ADC to or replace the XFF header.

X-Forwarded-For: <client>, <proxy1>, <proxy2>

Unlike XFF, which is HTTP-specific, PROXY Protocol prepends a binary header at the transport layer. It preserves the original client IP for any protocol—HTTP, HTTPS, SMTP, or raw TCP. If your backend server supports PROXY Protocol (e.g., HAProxy, Nginx, Apache 2.4.30+), this is a more robust solution than XFF. X-Forwarded-For on A10 Networks devices is a powerful but subtle tool. When configured correctly—preferably with replace mode to block spoofing—it restores end-to-end visibility. However, it shifts responsibility to the backend developer to parse headers securely.

A malicious client sends an HTTP request directly to your A10 with a forged header: GET /admin HTTP/1.1 X-Forwarded-For: 127.0.0.1