Forum Discussion
Muhannad
Cirrus
CirrusF5 SSL Pass-through with Xforward.
Dear Experts,
I have a requirment to configure a virtual server that do support SSL passthrough proxy (Which has been configured and working fine) but i need to inject the xforward value in the header.
I have been able to make the configurations by using Cliet-side and server-Side certificate with SSL proxy enabled the i have added the http header but the xforward value is not injected, please let me know if we have any workarounds.
Regards,
Muhannad
- Lidev
MVP
Hi Muhannad,
A Virtual Server configured with SSL pass-trough prevents F5 BIG-IP from using application-layer features. (https://support.f5.com/csp/article/K72355246)
SteveMCAltostratus
When you say "SSL proxy" I cannot tell if you mean to say that you have it in an SSL Bridging configuration or that you have actually enabled "Proxy SSL" which is a different beast.
Either way, you did say that you have successfully applied a Client and Server SSL Profile. Now you will need to set "Insert X-Forwarded-For" to Enabled in an HTTP Profile and apply that HTTP Profile to the Virtual Server.
MuhannadDear Steve,
Thanks for your response.
I have enabled Proxy SSL in the SSL profile and then Enabled the X-Forwarded-For in the HTTP profile but this didnt insert the client IP in the HTTP header.
My setup as follows : Client request SSL---->LTM (doing the SSL Proxy) --> F5 WAF---> Server
I have configured SSL client side and SSL server Side with SSL proxy enabled in both profiles in the LTM, HTTP profile with X-Forward has been added as well but in the WAF events i am still unable to see the original client IP.
do i have any workarounds or this will not work as Lidev said A Virtual Server configured with SSL pass-trough prevents F5 BIG-IP from using application-layer features.
Regards,
Muhannad
- Muhannad
The beast did it when i have excluded DH, DHE..
- SteveMC
Yes, it is important here to understand exactly what Proxy SSL Passthrough is, and what it is doing in order to understand when the application-layer features (HTTP Profile, WAF, etc) are and are not applied.
Proxy SSL:
With the original version of Proxy SSL configured, the LTM has a copy of the server's private key and it uses that to perform what is essentially a Man in The Middle (MITM) attack on all traffic where those SSL Profiles are applied
Unfortunately, DH/DHE cipher suites are specifically designed to safeguard against MITM attacks. Proxy SSL also has several other incompatibilities, like TLS Session Tickets. If any of these are present, Proxy SSL will break and traffic will simply fail.
Because of this, F5 eventually added the Proxy SSL Passthrough mode.
Proxy SSL Passthrough:
Proxy SSL Passthrough is exactly the same as standard Proxy SSL, except that when incompatible (DH/DHE) ciphers are negotiated the LTM will bypass Proxy SSL completely (as if you had not configured any SSL Profiles) instead of dropping the traffic.
However, this is a problem if you are relying on being able to decrypt the traffic for any other purpose (HTTP Profile, iRules, APM Policies, ASM WAF inspection, etc).
My personal recommendation is to avoid Proxy SSL unless absolutely necessary. Is there any reason you can't use SSL Offloading or SSL Bridging configurations here?
- Muhannad
I am having an LTM which load balance the traffic to two WAF clusters, these clusters are located in differenct locations within the same enviorment (Kind of HA setup within the same site), we relay in the LTM to do the load balancing, noting that these WAF clusters are sperated by L3 firewalls, so i cant extend the IP addressing schema to both of them.
Please find the reasons for why i want to use the SSL-passthrough:
- The client want to maintain the SSL decryption in the WAF devices for security reasons, the LTM devices are not part of thier secure enviorment.
- We are having some issue with the CN of the certifcate when it is installed in these different in the WAF devices coz it is tighed with an IP address (it is an internal service), this is where SSL bridging is failing.
- Finally the client cant make routing changes and he need to see the client IP address, this why i need to insert the Xforward coz installing the LTM in routed mode is not an option.
This is it is a bit complex implentation, for this reason the only solution was for me to do the SSL passthrough.
I am still confused about a point if the SSL-Passtrhough is still performing any kind of SSL decryption when it is on the way between the SSL client and the SSL server?
i mean does the BIG-IP system to decrypt, optimize, and reencrypt the SSL traffic whith the SSL passthrough or not coz i think it impossible to insert the Xforward without doint this?
Thanks again for your help.
- SteveMC
Correct, the LTM has to decrypt the traffic to insert the x-forwarded-for header. There is no way around that.
If you have a requirement that the LTM does not decrypt the traffic, it will be impossible to insert an x-forwarded-for header. These two client requirements are mutually exclusive.
"Proxy SSL Passthrough" is not the same thing as simple "SSL Passthrough." Proxy SSL Passthrough does decrypt the traffic as long as a compatible cipher suite is negotiated between client and server, and falls back to SSL Passthrough when DH/DHE ciphers are negotiated.
- Muhannad
I think this is very clear for me now.
I will let the client take the decision, thanks Seteve for the help.
