Forum Discussion

OTS02's avatar
OTS02
Icon for Cirrus rankCirrus
Dec 04, 2015

server-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.

 

application delivery
LTM

11 Replies

Sort By
  • Arnaud_Lemaire's avatar
    Arnaud_Lemaire
    Icon for Employee rankEmployee
    Dec 08, 2015

    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.

     

  • OTS02's avatar
    OTS02
    Icon for Cirrus rankCirrus
    Dec 08, 2015

    Hi 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's avatar
    OTS02
    Icon for Cirrus rankCirrus
    Dec 08, 2015

    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_139's avatar
    Brad_Parker_139
    Icon for Nacreous rankNacreous
    Dec 08, 2015

    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.

     

    • OTS02's avatar
      OTS02
      Icon for Cirrus rankCirrus
      Dec 08, 2015
      But 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_139's avatar
      Brad_Parker_139
      Icon for Nacreous rankNacreous
      Dec 08, 2015
      A browser will retry the whole connection and has a different SSL stack than BigIP so the client behavior can be different.
    • OTS02's avatar
      OTS02
      Icon for Cirrus rankCirrus
      Dec 08, 2015
      OK. 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_Parker's avatar
    Brad_Parker
    Icon for Cirrus rankCirrus
    Dec 08, 2015

    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.

     

    • OTS02's avatar
      OTS02
      Icon for Cirrus rankCirrus
      Dec 08, 2015
      But 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's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      Dec 08, 2015
      A browser will retry the whole connection and has a different SSL stack than BigIP so the client behavior can be different.
    • OTS02's avatar
      OTS02
      Icon for Cirrus rankCirrus
      Dec 08, 2015
      OK. I think the Windows 2008 server is kind of lame, but just the same, I'm pretty stinkin happy the goofy thing is working.