Because the WAF do SSL Termination before forwarding the request to load balancer, the load balancer will see a request as coming from WAF not client ex WAF IP , so is it possible to add X-FORWARDED in WAF so that the request will reach load balancer with client IP /port etc? Is this techniques risky? and will have any bad effect ? or normal behavior ?

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 ConnectionSource: <client-ip>:<client-port>Destination: <virtual-server-ip>:<virtual-server-port> Server Side ConnectionSource: <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 ConnectionSource: <client-ip>:<client-port>Destination: <virtual-server-ip>:<virtual-server-port> Server Side ConnectionSource: <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?

X-FORWARDED header in WAF

Forum Discussion

DevCentral Quicklinks

* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com

Discover DevCentral Connects

* Podcasts
* Social Channels
* Video Streaming

GitHub Awesome-F5

Forum Discussion

SSO Login Update Coming to DevCentral

Kevin - June 2026 Featured F5er

Tyler - May 2026 Featured Member

Recent Discussions

ASM attack signatures not syncing between active and standby F5

simultaneous disabling / enabling of all LTM objects

rSeries: config changes in logs

qkview: revealing pool members & pools

Query on source IP preservation for syslog traffic through F5 virtual server

Related Content

X Forwarded For Single Header Insert

TCP Option 28 X-Forwarded-For Header

Bypass WAF for X-forwarder IP in XC

Restricting Access to Virtual from client IP address in X-Forwarder-For HTTP header

Extracting X-Forwarded-For in Node.js

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS