SSL VPN 5.6.4 Issue - Unknown cipher error

Thought I would pass this along.  Today we upgraded from 5.4.5 to 5.6.4.  We have two 500Ds.  So earlier this week, we restored our 5.4.5 config from production to our standby unit.  We then followed the upgrade matrix to get it to 5.6.4.

After cleaning up App Control policies and some of the other changes from 5.4.x to 5.6.x, we determined it was ready to go.  Earlier we had pushed out a new ProxySSL cert to our clients via GPO as the old 5.4.5 one was SHA1 and was no longer supported in 5.6.x.

This AM I swapped the cables and all looked fine.  Registered it in our FAZ and logs were flowing.  Watched for unnecessary blocks and all looked good.  With one exception.  Connection attempts to our SSLVPN were failing with an "Unknown cipher error".  I assumed the cert was corrupted somehow so I rekeyed my cert with Digicert (that took an agonizingly long time to finish for some reason), and then loaded the new cert.  The problem persisted.  Both Qualys (https://www.ssllabs.com/ssltest/index.html) and Digicert (https://www.digicert.com/help/) were not able to scan the connection.  These links are invaluable when testing such things.

So I decided to dig into CLI before swapping back to my other Gate.  Here are my SSL settings (show full):

config vpn ssl settings set reqclientcert disable set tlsv1-0 disable set tlsv1-1 enable set tlsv1-2 enable unset banned-cipher set ssl-big-buffer disable set ssl-insert-empty-fragment enable set https-redirect enable [style="background-color: #ffff00;"]set ssl-client-renegotiation enable[/style] set force-two-factor-auth disable set servercert "SSLVPN-070618" [style="background-color: #ffff00;"]set algorithm medium[/style] set idle-timeout 7200 set auth-timeout 28800 set login-attempt-limit 2 set login-block-time 60 set login-timeout 30 set dtls-hello-timeout 10 set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1" set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1" set dns-suffix "company.local" set dns-server1 10.31.251.10 set dns-server2 10.31.252.10 set wins-server1 0.0.0.0 set wins-server2 0.0.0.0 set ipv6-dns-server1 :: set ipv6-dns-server2 :: set ipv6-wins-server1 :: set ipv6-wins-server2 :: set route-source-interface disable set url-obscuration enable set http-compression disable set http-only-cookie enable set port 443 set port-precedence enable set auto-tunnel-static-route enable set header-x-forwarded-for add set source-interface "port9" set source-address "all" set source-address-negate disable set source-address6 "all" set source-address6-negate disable set default-portal "SSL_VPN_TS" config authentication-rule edit 8 set groups "SSL_VPN_FULL" set portal "SSL_VPN_FULL" set realm '' set client-cert disable set cipher high set auth any next edit 10 set groups "SSL_VPN_SAS" set portal "SSL_VPN_SAS" set realm '' set client-cert disable set cipher high set auth any next edit 9 set groups "SSL_VPN_TS" set portal "SSL_VPN_TS" set realm '' set client-cert disable set cipher high set auth any next end set dtls-tunnel enable set check-referer enable set http-request-header-timeout 20 set http-request-body-timeout 30 set unsafe-legacy-renegotiation disable end

We traced the issue to one of the two highlighted settings.  The defaults were:

set ssl-client-renegotiation disable set algorithm high

For some reason, with these settings the session would not allow a handshake.  In testing I changed to this:

set ssl-client-renegotiation enable set algorithm low

Once I did that, the sessions started working again.  So I decided I didn't want "set algorithm low" and changed it back to the default (unset algorithm), but it again broke all incoming connections.

So I modified it to set alogrithm medium and it is again working.

I will open a ticket with the TAC to see what the issue was.

I hope this saves someone else some time.