Forum Discussion
Kevin_Stewart
May 13, 2013Employee
Ah, so it's:
Client -> 443 (SSL) VIP with client SSL and server SSL profiles -> 8443 pool -> 8443 (SSL) VIP with client (and server) SSL profile -> application
I'm also assuming these are standard virtual servers with port and address translation enabled, and SNAT enabled (you've confirmed this piece). We know based on the TCPDUMP that the two LBs can talk to each other, so routing isn't an issue. Is there any reason to believe that the second LB would not be accepting the SSL from the first? Do you have any unique settings in the second LB's client SSL profile?
Just for giggles, try an SSLDUMP between the two.
ssldump -k -i 0.0 -AdNn port 443
-k - you need the physical location of the private (*.key) file that is specified in the client SSL profile
-i 0.0 - this means use all interfaces, but you can narrow it down to a single VLAN/interface
-AdNn - this esentially means decrypt the traffic if possible and clean up the capture
port 443 - this is your filter. SSLDUMP absolutely requires a filter string. You can narrow this down to an IP address or anything else as long as the filter string is present.
What you're looking for is anything in the SSL traffic that would indicate a failure to negotiate.