X-FORWARDED header in WAF

Perhaps it would help here to take a step back and discuss some fundamental BIG-IP behaviors so that you can better understand the solutions presented by Nikoolayy1 and Daniel.

You can use the BIG-IP system to insert all sorts of information from the client-side connection (client to virtual server) into the server-side connection (BIG-IP to pool member), if that information might be lost as part of the connection being proxied. But first you need to know what information is normally passed during default BIG-IP proxy behavior.

By default, when a connection to a virtual server is load balanced to a pool member, the destination IP address and port are translated to that of the pool member selected by the load balancing decision. (This behavior is controlled by the virtual server's Address Translation and Port Translation settings, which are enabled by default.) So, the full proxied connection for a default standard host virtual server looks something like this:

Client Side Connection

Source: <client-ip>:<client-port>

Destination: <virtual-server-ip>:<virtual-server-port>

Server Side Connection

Source: <client-ip>:<client-port>

Destination: <pool-member-ip>:<pool-member-port>

In this default scenario, the pool member (server) sees the connection as originating from the client. No need for an X-Forwarded-For header insert (at least not on the BIG-IP system) as the source address and port are not translated on the server-side connection. Also, by default, the HTTP headers from the client-side request, such as the HTTP Host header, are sent unchanged in the server-side request. The back end application has access to all of this information without doing anything else on the BIG-IP system.

As Nikoolayy1 indicated though, the only requirement is that the server's response must traverse the BIG-IP system so that the destination address and port translation can be "undone" before sending the response back to the client. This can be accomplished by adjusting the routing from the server or by using some sort of source address translation (or SNAT) on the BIG-IP system. One common method is to set Source Address Translation to Automap on the virtual server. If you do so, the full proxied connection now looks like this:

Client Side Connection

Source: <client-ip>:<client-port>

Destination: <virtual-server-ip>:<virtual-server-port>

Server Side Connection

Source: <BIG-IP-self-ip>:<ephemeral-port>*

Destination: <pool-member-ip>:<pool-member-port>

* Source port is preserved, if possible, by default

If you do configure the system to SNAT the traffic, the pool member (server) might have a problem as all traffic appears to originate from a single client (the BIG-IP system), not from the full range of clients the server might normally expect. To compensate for this, if the traffic is HTTP, you can enable the Insert X-Forwarded-For setting in the HTTP profile assigned to the virtual server. This causes the system to insert an X-Forwarded-For header with the client's IP address and port (as presented to the BIG-IP system on the client-side connection) on the server-side connection. (It is disabled by default.) You can also use the HTTP profile to insert a single header of your choice (name and value) into the server-side request. (Request Header Insert) if there is any other information you want to send to the server that is only available on the BIG-IP system.

Note that these translation functions and HTTP header manipulations are not impacted by SSL termination or the assignment of a BIG-IP ASM (AdvWAF) security policy on the virtual server. They happen outside of the scope of these functions, with or without them. Therefore, it does not matter in your case that you are terminating SSL on the BIG-IP system so that ASM can examine the HTTP payload to look for possible malicious traffic. If ASM finds something you have configured it to block via the WAF security policy, the server-side request never occurs. If not, the request continues to be processed and all the solutions described earlier will work. The question is does your application really need them or is the system already passing all the information your application/server needs?