Forum Discussion
NimbostratusXFF for retaining client's Original IP
CirrusHi,
Keep in mind that a.) XFF will only work for HTTP traffic, b.) the VS needs to have the HTTP profile assigned to it, c.) the application (or device) receiving the traffic must correctly interpret the XFF HTTP Header.
You can search the system's connection table to find associated client-side & server-side flows. This way you can i.e. see all server-side connections for a specific client IP address; or find out which real client IP addresses are connected to a particular node or pool member.
Please refer to the following for more info on working with the connection table:
K53851362: Displaying and deleting BIG-IP connection table entries from the command line
https://support.f5.com/csp/article/K53851362
K40033505: Explaining the output of tmsh show sys connection
https://support.f5.com/csp/article/K40033505
NimbostratusHello Nützmann,
Thank you for your reply, really appreciate that. I'm actually looking for logs which are a week older or 10 days older and has the information about the client's original IP address or the client's true IP address. Is there a way we can do some customization or configuration on F5 to store those logs in var/log folder or to send it to some external syslog server? I know XFF work for only HTTP VS and then we need to configure the web server to extract the IP address from the HTTP header, but need to check the older logs which has the true client IP address.
can we tune F5 settings to send the logs which have the client True IP address to any syslog server or to store the logs on f5 itself in var/log for auditing or troubleshooting. Any further help on this would really help me. Thank you again for your kind support. Have a good day sir!
StephanMantheyNacreous
You may want to configure a remote syslog server in System >> Logs : Remote Server
Now you can use an iRule to log each incoming http-request:
when HTTP_REQUEST { log local0. "method=[HTTP::method];path=[HTTP::path];client_ip=[IP::client_addr]" }Log facility local0. writes into the /var/log/ltm and logs will be replicated to the remote syslog server as well.
The logs on the BIG-IP are rotated each day around 3 AM, compressed and removed on the 10th day or earlier, if they are too large.
- mohammed5370
ok Thanks Stephan, does that mean I dont have to configure XFF if I use this irule. will this irule send the client's original or true IP address to syslog server instead of SNAT IP address? Appreciate any help on this.
- StephanManthey
The iRule will send the original client IP along with the HTTP method and requested path to the local syslog, which is writing into /var/log/ltm. In case you also have configured a remote syslog server, it will show up there as well.
In most environments its the preferred method to insert the X-Forwarded-For on the load balancer and to consolidate the server logs. On the servers its required to change the logging directive so its tracking the IP address provided in the X-Forwarded-For header instead of the IP address of the IP header (which is the serverside SNAT inserted by the BIG-IP).
If you lookup server logs, you will notice, that a log entry contains information both of the request and the response (i.e. status code), this can be accomplished as well.
This would require to store request information of your choise (i.e. the clients original IP address) in a variable in the context of the HTTP_REQUEST event and to write this information in the context of the HTTP_RESPONSE event along with i.e. status code, content type, content length to the logs.
