Forum Discussion

Scott123456789's avatar
Scott123456789
Icon for Cirrus rankCirrus
Mar 23, 2017

X-Forwarded-For through proxy and F5

My organization recently got the ASM module when they purchased a pair of 5250Vs. I've never used ASM before and we don't have anyone in our organization that has either, so I'm learning on the fly. ...
ASM Advanced WAF
security
x-forwarded-for
Soda_Cup_148395's avatar
Soda_Cup_148395
Icon for Nimbostratus rankNimbostratus

Hi,

Okay, I think that might be because that is from one of your proxies that already inserts XFF, correct? I hinted earlier that you might need to adjust the behavior per client(or proxy) IP. I might have some bad indentation here but this is something to the idea-

when HTTP_REQUEST {

 if { [IP::addr [IP::client_addr] equals IP_PROXY_THAT_ALREADY_INSERT_XFF/CIDR] } { 
   we know this proxy already inserts XFF, so dont do anything but load balancer
   pool [LB::server pool]

} else {
    insert client IP to add visibility after f5 SNAT
     set XFF [IP::remote_addr]
     HTTP::header replace "X-Forwarded-For" $XFF

     }

}

also if the proxies are sending multiple http requests per connection you may need to enable oneconnect to get your iRule to work correctly.

Let me know how your ssldump goes...

Scott123456789's avatar
Scott123456789
Icon for Cirrus rankCirrus
Mar 27, 2017

I'm sorry, but I don't follow the logic here. I'm new to this, so I'm sure it's me, but the traffic sourcing from a proxy is the traffic I can't see the client IP on. If that proxy is inserting an XFF and it is giving me the proxy IP in that XFF, why would I do nothing to that? I'd think I'd want to determine if there is a second XFF value that I'd expect to be the original client IP.