Forum Discussion
NimbostratusSSL Pass Through
Any help is very welcome...
Thanks
Mike
hoolioCirrostratus
Hi Mike,
If you don't have the default gateway of the web server set to the BIG-IP's floating self IP address or have source address translation enabled, the server will send the response back to the client via its default gateway or back directly to the client. Either way, it will be with a source address that the client didn't make the request to, so the client will ignore the packets. There are a few different options for resolving this: you can change the default gateway on the server or enable SNAT on the virtual server.
If neither option works for you, can you provide more detail on the problem?
Thanks,
Aaron
mike_gatti_6169Aaron, thanks for the reply
We don't use the LTM in band with the servers. The servers that are in the pool are on a different subnet. The VIP is configured with IP Translation = Enabled / SNAT = AUTONAT / Port Translation = Disabled. I can successfully telnet to the server in the pool on port 443 from the LTM to test connectivity.
When I try to connect to the vip:443 from my browser it stays in a connecting state and does not show the Web UI from the server in the pool. If I go straight to the server i get a error message "Can't verify the identity of the website", which is caused by the self signed cert that the server uses. I have to click ok to pass this error. Could LTM be hanging up on this error?- hoolioThat sounds like it should work...
If you don't have a server SSL profile on the VIP, the BIG-IP can't/won't try to validate the certificate that the pool member presents. Can you check the pool stats to see if there are any stats for the pool member? Or better, can you run another tcpdump on the BIG-IP checking for the client and server IP's to see what's happening at the TCP layer? You can listen on all switch interfaces using interface 0.0:
tcpdump -ni 0.0 host CLIENT_IP or host SERVER_IP
If you want to save the output to a binary file, you can use this:
tcpdump -ni 0.0 -s0 -w/var/tmp/`hostname`.ssl.dmp host CLIENT_IP or host SERVER_IP
Once you have a trace that includes both the client to VIP and SNAT to server traffic, you might be able to find clues at the TCP layer. Else, you can decrypt the trace using the web server's private key and ssldump (Click here).
Aaron - dennypayne
Employee
Also make sure you don't have the http profile enabled on the vip...that will break an SSL pass-through vip.
Denny- Abhijith_KS_302
Altostratus
Hi Denny: could you please let me know why the http profile would break the app, bcos it actually did. I removed and it worked. So I wanna understand how ?
- Simon_Blakely
Your virtual is passing SSL traffic without decrypting it (no client or server ssl profile). So the data passing through the virtual is just raw tcp containing SSL headers and encrypted HTTP.
The HTTP profile is looking for text HTTP (i.e decrypted data), and will fail on the raw SSL data. When it fails, it resets the connection.
If you wish to use an HTTP profile on the virtual, you need to add a client-side SSL profile (with the existing self-signed certificate and key, or an externally signed certificate/key/chain), and a server-side SSL profile (the default serverssl certificate should work). This will establish a client side connection that is encrypted using the F5 client-side ssl settings, and a server-side connection that is encrypted based on the application server settings, and in the LTM (where the HTTP profile sees the traffic) the traffic is decrypted plain-text.
This way, you can specify strong and secure client-side SSL options and not be restricted to whatever the SSL options the application server supports (which could be weak SSL).
One caveat: this will not work if the application server requires the client to present a certificate to the application server - there is a specific Proxy SSL option that can be used to enable this, but has very specific cipher requirements to allow observation/modification of the HTTP requests/responses, and the same certificate/key pair must be used on the LTM client-SSL profile as on the application server.
- Abhijith_KS_302
Blakely : Thanks a lot for the answer. Makes sense to me now, thank you :)
- Also make sure you don't have the http profile enabled on the vip...that will break an SSL pass-through vip.
Denny- Abhijith_KS_302
Hi Denny: could you please let me know why the http profile would break the app, bcos it actually did. I removed and it worked. So I wanna understand how ?
- Simon_Blakely
Your virtual is passing SSL traffic without decrypting it (no client or server ssl profile). So the data passing through the virtual is just raw tcp containing SSL headers and encrypted HTTP.
The HTTP profile is looking for text HTTP (i.e decrypted data), and will fail on the raw SSL data. When it fails, it resets the connection.
If you wish to use an HTTP profile on the virtual, you need to add a client-side SSL profile (with the existing self-signed certificate and key, or an externally signed certificate/key/chain), and a server-side SSL profile (the default serverssl certificate should work). This will establish a client side connection that is encrypted using the F5 client-side ssl settings, and a server-side connection that is encrypted based on the application server settings, and in the LTM (where the HTTP profile sees the traffic) the traffic is decrypted plain-text.
This way, you can specify strong and secure client-side SSL options and not be restricted to whatever the SSL options the application server supports (which could be weak SSL).
One caveat: this will not work if the application server requires the client to present a certificate to the application server - there is a specific Proxy SSL option that can be used to enable this, but has very specific cipher requirements to allow observation/modification of the HTTP requests/responses, and the same certificate/key pair must be used on the LTM client-SSL profile as on the application server.
- Abhijith_KS_302
Blakely : Thanks a lot for the answer. Makes sense to me now, thank you :)
