Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’.
Short Description
As mentioned in article https://my.f5.com/manage/s/article/K73304774 (K73304774: AFM + IP Intelligence does not block requests using X-Forwarded-For header value) the AFM can't work with XFF headers unless decrypting traffic and using the IP Intelligence i in a irule, which is comlex but there is an easier way and I will show you how! 😎
If the XFF has multiple values better also see article https://my.f5.com/manage/s/article/K70310105 (K70310105: ASM with IP-intelligence cannot reject request based on x-forwarded-for) that if for the ASM/AWAF but the same principle applies here.
Problem solved by this Code Snippet
The iRule below is attached on a virtual server that decrypts the HTTPS traffic, then the traffic is forwarded to another second virtual server where the IP Intelligence policy is assigned.
How to use this Code Snippet
Make 2 virtial servers as the first VS will decrypt the traffic (you also attach the iRule to the first VS) and will lead to the second VS and the second VS will have an LTM pool and the IPI policy attached to it. Keep in mind that if the traffic is too high there could be a bottleneck because of the internal channel between the two VS.
Code Snippet Meta Information
Version: 16.1.3.4
Coding Language: TCL/iRule
Full Code Snippet
when HTTP_REQUEST {
if { [HTTP::header exists "X-Forwarded-For"] } {
snat [HTTP::header "X-Forwarded-For"]
log local0. "Client IP changed from [IP::client_addr] to [HTTP::header "X-Forwarded-For"]"
At Agility we've regularly done a lab on this solution for AFM. And you can get really creative and apply a different firewall policy for the URI as well. e.g. /login and /admin can have different firewall policies as the virtual forwarding creates a whole new TCP connection between the two virtual servers.
