Forum Discussion
X-FORWARDED header in WAF
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 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?
Hi,
which device would be the WAF and which the loadbalancer? Or is it an LTM + AWAF deployment?
In any case, inserting a X-Forwarded header would not do any harm.
Configuring LTM to insert such header and making the security policy in AWAF "aware" of this header is actually a very common scenario.
Does this answer your question?
KR
Daniel
- crodriguezRet. Employee
As Daniel indicated, you can have the BIG-IP system automatically insert an HTTP X-Forwarded-For header into the server-side request. It should be as simple as enabling the insert-xforwarded-for setting in the HTTP profile you use on the virtual server with the F5 Advanced WAF security policy assigned.
- THE_BLUECirrostratus
so if i have enabled insert-xforwarded-for setting in the HTTP profile i will be able to forward host IP, client IP, port information to load balancer (backend server)?
The X-Forwarded-For header will only contain the IP address of the client connecting to the WAF.
If you want to forward additional information like Virtual Server IP address, Virtual Server port or client port to the application, you can do this with an iRule.
You can either add all the information in single string and forward all of them as one additional header, or you can forward each as a separate header (for example, X-Client-IP, X-Client-Port, or similar).
I can help you with the iRule.
- THE_BLUECirrostratus
great .
so we have to add X-forwarded headers in BIGIP right? instatded of backed server ?
because the website is running over BIG-IP (LTM + ASM ) and the termination is happen in WAF .
Or we can configure it server itself without adding them in big-ip ?
If you do it on the servers that are after the F5 device you will lose the real client ip as if the F5 using SNAT to contact the servers and the client IP address is lost. The only way is to not use SNAT on the F5 device VIP and make the routing between F5 and servers to always return the reply to the F5 device:
https://support.f5.com/csp/article/K7820
If there is a forwarding proxy secure web gateway device before the F5 device that does source nat on the client IP address and inserts x-forward-for header then the F5 ASM can trust that header:
https://support.f5.com/csp/article/K12264
It all depends on your network environment and you need to see what works for you.
An issue I have seen is if there is a proxy before the F5 device that does client ip snat and inserts X-forward-for header and the F5 device is also using SNAT and inserting x-forward-for header how to mach the original ip address of the client after so many proxy devices. You can check:
https://support.f5.com/csp/article/K50499256
https://support.f5.com/csp/article/K15732009
https://devcentral.f5.com/s/question/0D51T00006i7gOP/remove-additional-ip-from-xff-http-header
Yes, you have to add the X-Forwarded-For header (and other info if you wish) on the BIG-IP. You cannot configure it on the backend server, since this information is only available on the BIG-IP.
- THE_BLUECirrostratus
Great , so kindly help me to add the below in WAF
X-FORWARDED-PROT
X-FORWARDED-HOST
X-FORWARDED-FOR
X-FORWARDED-PORT
- crodriguezRet. Employee
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?
- THE_BLUECirrostratus
the current setup is :
Source Address Translation : automap
Address Translation : enabled
Port Translation : enabled
HTTP Profile : enabled
For further fields you can find them here: Master list of iRule Commands
For example [IP::local_addr] would translate to the the IP address of the virtual server the client is connected to.
## Example code: HTTP::header insert X-Forwarded-Host [IP::local_addr]
Just start with the iRule from K4816 and follow the above pattern. In theory you can add whatever info you wish. But first answer yourself the important question asked by : does your application really need them or is the system already passing all the information your application/server needs?
Also keep in mind, that once you add the X-Forwarded-For header with an iRule, you must not add it with the http profile.
- JoadNimbostratus
Hi all,
is it also possibile to retrieve XFF in a SSL full-proxy, end-to-end configuration (aka bridging or Re-Encryption method)?
Thank you in advance
Recent Discussions
Related Content
* 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