Ok cool, So i think there is your answer, XFF is a HTTP Header, the f5 needs to have the SSL profiles on the front f5 to be able to decrypt add the XFF HTTP Header and then re-encypt it to pass it out back to your waf.
If you do move the SSL offload to the front f5 you could techincally not reencypt the traffic and just pass it back to the WAF unencrypted but that'll depend on your applicaiton.
OK, so your problem is that you cannot insert an XFF header into TLS encrypted traffic. The easy solution is to terminate TLS on the DNS virtual server, insert the XFF header using an HTTP profile, re-encrypt on the server-side and then send to the WAF. This is the recommended approach.
There is a harder approach, which is a technique used by Akamai for encrypted traffic that is redirected to an origin server. They insert the original client IP into a TCP option (option 28) because it is rarely used. The option gets extracted at the destination server and inserted into the request as an XFF header using an irule. I have an irule to extract an IP address inserted into a TCP Option 28 header - I just need to write an additional irule that could insert it on the server-side of the DNS. I can provide the irules tomorrow. However, the first option above is the preferred option.
Do you mean DNS? - if you have a LTM with a virtual server configured with a HTTP profile passing your traffic, you can turn on XFF inside the HTTP profile with a simple tick box.
ok, so did you find the xff variable and enable it? - did that fix your issue? If not, can you explain your config slightly more? DNS isn't http and they work in different ways.
What i think you're trying to do is pass back the client IP from the front f5 to the back one with the WAF on it so the WAF can see the client IP. Is that correct? One thing to just ask, is this traffic encrypted? so https? and are the SSL profiles all configured correctly?
What i think you're trying to do is pass back the client IP from the front f5 to the back one with the WAF on it so the WAF can see the client IP. Is that correct? Yes that is the required
The traffic is encrypted and no SSL profile is assigned on the F5 DNS, SSL is offloaded on the F5 WAF.
Ok cool, So i think there is your answer, XFF is a HTTP Header, the f5 needs to have the SSL profiles on the front f5 to be able to decrypt add the XFF HTTP Header and then re-encypt it to pass it out back to your waf.
If you do move the SSL offload to the front f5 you could techincally not reencypt the traffic and just pass it back to the WAF unencrypted but that'll depend on your applicaiton.
OK, so your problem is that you cannot insert an XFF header into TLS encrypted traffic. The easy solution is to terminate TLS on the DNS virtual server, insert the XFF header using an HTTP profile, re-encrypt on the server-side and then send to the WAF. This is the recommended approach.
There is a harder approach, which is a technique used by Akamai for encrypted traffic that is redirected to an origin server. They insert the original client IP into a TCP option (option 28) because it is rarely used. The option gets extracted at the destination server and inserted into the request as an XFF header using an irule. I have an irule to extract an IP address inserted into a TCP Option 28 header - I just need to write an additional irule that could insert it on the server-side of the DNS. I can provide the irules tomorrow. However, the first option above is the preferred option.
