Forum Discussion
f5gurunot
Cirrus
CirrusTCP Option 28 X-Forwarded-For Header
Using Akamai for DDOS mitigation and the requests sent to us show Akamai IP instead of the Client IP. I have enabled TCP Option 28 and trying to insert the Client IP into X-Forwarded-For header. I ...
when CLIENT_DATA {
set opt28 [TCP::option get 28]
if { [string length $opt28] == 4 } {
binary scan $opt28 H8 addr
scan $addr "%2x%2x%2x%2x" ip1 ip2 ip3 ip4
set optaddr "$ip1.$ip2.$ip3.$ip4"
log local0. "optaddr is $optaddr"
log local0. "ip addr parse result is [IP::addr parse -ipv4 $opt28]"
}
}
Paulius
MVP
MVPf5gurunot From my understanding Akamai is the one that would insert the true client-IP into the HTTP header because they are the source of the connection as far as your F5 is concerned. If the true client IP doesn't exist in the HTTP header that is squarly on Akamai. It is possible that Akamai has provided you the incorrect HTTP header field that they use to inject the client-IP into the HTTP header or it is possible that your pool members are not searching for the correct header field in the HTTP header. The only thing that inserting the client-IP into the HTTP header on the F5 will achieve would be to include the Akamai IP. Based on your virtual server configuration your pool members think the F5 is the source of the communication but should have an HTTP header inserted by Akamai and one inserted by the iRule named X-Forwarded-For. It is possible that you are overwriting the HTTP header field value with what is in the iRule if you all are using the same header field name.
f5gurunotCirrus
CirrusIf you are referring to the True-Client-IP header that Akamai uses instead of the X-Forwarded-For header that is not an option because our Akamai solution operates in TCP mode, not HTTP mode. It only supports the following methods of source IP forwarding: CIP, Option 28, Proxy Protocol v1 & v2. We have enabled Option 28.