XFF and the ASM module

So, we believe we have the solution to the issue.

I only found out yesterday that there is another piece of kit between the BigIp and the financial monitoring app.

So, what I believe is happening is, because of the legacy root domains set up on the system before I was an eye in my father's twinkle, there is an additional two characters added to the ip address %1 or %2

So, we have 17 chars. The "new" piece of kit is configured to only accept the standard 15. So, we need to reconfigure this piece of kit to strip off the %1 or %2 and then pass it to the financial monitoring package.

This is the way it was done before on the other network. Obviously me asking the customer for the full topology multiple times and asking the question "is there anything else in the route" was not understandable!!

For the forum's information, the iRule that was put into place was one that is published on the F5 website here K4816: Using the X-Forwarded-For HTTP header to preserve the original client IP address for traffic translated by a SNAT

when HTTP_REQUEST {
HTTP::header insert X-Forwarded-For [IP::remote_addr]
}

So, in summary Verisign added XFF BigIp added its XFF (but also added root domain %1 or %2) SAS interpreted 15 chars not 17 Financial package dropped packets.

Plan Adjust SAS to read 17 chars and then strip off the %1 or %2 Financial package will read 15 and accept multiple XFF

Big thank you to all who contributed.

haha, always a nice conclusion, thanks for reporting back.

Sorry for the late answer.

The ASM must be configured to trust the XFF header in the policy configuration. Once this is done you can configure name of the XFF header to look for if it is non-standard.

If there are multiple XFF headers with the configured name ASM will use only the last one for reporting and inspection.

The unexpected behavior that many users run into is that if the HTTP profile is configured to insert an XFF header this becomes the last one in the list and ASM will use this. Essentially if there is an upstream SNAT the ASM will only see that address in the XFF header and effectively it is functionally identical to NOT using the XFF as the source IP will match what was received at layer3.

I hope this helps as a general guideline. I see you found an issue with the XFF iRule inserting the route domain suffix.