Forum Discussion
Cirrusserver-side ssl not negotiating
I have a standard Virtual Server (443) that terminates ssl on the client side, and re-encrypts on the server side. Just as I have done many times.
LTM logs (ssl debug) yields:
01260013 SSL Handshake failed for TCP from 10.xxx.x.218:6914 to 10.yyy.yyy.51:443
I can https into any of the single servers (Firefox says - TLS_RSA_WITH_AES_128_CBC_SHA TLS1.2)
from command prompt:
openssl s_client -connect 10.yyy.yyy.51:443
SSL handshake has read 3988 bytes and written 465 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit
The built in LTM monitors, based on the f5 pre-canned https, pass no problem.
Yet when I try going through the VS, it's a no-go on the server side.
I pulled in another server serving up the default IIS page on 443, and it works OK.
Any suggestions would be greatly appreciated. I have tried all kinds of cipher strings, eliminating SSLv3.
The problem server's IOS is Windows 2008.
11 Replies
Arnaud_LemaireEmployee
Can you have a look to a pcap with wireshark to see any usefull debug info ? as well you have some statistics in SSL profiles on the big-ip which could help to understand the type of error.
OTS02Hi Arnaud,
Wiresharks show that when the server is accessed through the VS, it immediately responds to the ssl handshake with a TCP reset. The server logs (Windows 2008) show the same thing. Unfortunately, I do not know how to find the reason for the reset. The odd thing is, you can go directly to the server no problem. Also https monitors are having no problem. I have set the server-side ssl profile cipher list to 'ALL'.
If you could point me in the right direction, I will look at the SSL profile statistics. In the GUI, I have found the Server SSL statistics, but have not yet discovered how to narrow it down to the SSL profile of interest.
At first I thought this looked like an asymmetrical routing issue, but I have ruled that out. BTW, I can put other HTTPS servers in this pool, and they work just fine. So I think that there is something with this set of servers that is the problem. Just knowing the reason for the handshake refection would be a tremendous step forward. Thanks you for your help.
- OTS02
I found the individual server ssl stats in TMSH. Unfortunately, it only tallies the handshake failures - does not give any clue as to the reason.
Brad_Parker_139Nacreous
I made the server-side SSL profile cipher string = 'TLSv1' only and that made it work.
This is because Windows 2008 no R2 doesn't understand TLSv1.2 handshake initiation and it never allows it to negotiate down to TLSv1.
- OTS02But when examining the ssldump of a browser going directly to the server, the browser first offers 1.2, and they negotiate down to 1.0.
- Brad_Parker_139A browser will retry the whole connection and has a different SSL stack than BigIP so the client behavior can be different.
- OTS02OK. I think the Windows 2008 server is kind of lame, but just the same, I'm pretty stinkin happy the goofy thing is working.
Brad_ParkerI made the server-side SSL profile cipher string = 'TLSv1' only and that made it work.
This is because Windows 2008 no R2 doesn't understand TLSv1.2 handshake initiation and it never allows it to negotiate down to TLSv1.
- OTS02But when examining the ssldump of a browser going directly to the server, the browser first offers 1.2, and they negotiate down to 1.0.
- Brad_ParkerA browser will retry the whole connection and has a different SSL stack than BigIP so the client behavior can be different.
- OTS02OK. I think the Windows 2008 server is kind of lame, but just the same, I'm pretty stinkin happy the goofy thing is working.
