Technical Forum
Ask questions. Discover Answers.
cancel
Showing results for 
Search instead for 
Did you mean: 

SSL Handshake Failure

LA_Medina_32319
Nimbostratus
Nimbostratus

Hi,

 

We are having trouble with one of our newly created VS. It cant seem to be able to 'communicate' to the backend server (NODEs).

 

We have reachability to the Node IP. We also have an existing VS with NODE IPs from the same subnet as the new one and it is working fine. The setting is identical as well from the working one.

 

When i did a curl check, i can see that there was an error on the SSL but i cant figure out where the issue is, whether it is on the F5 or on the server end. I don't have access/visibility on the server end so i'm unable to do some check and verification on server end.

 

We have configured a SSL Client and Server Profile in the VS.

 

Was wondering if someone can shed some light on this. Would appreciate it much!

 

Below is the error i get for the SSL.

 

[Active:In Sync] config curl -vk https://[Node IP] * About to connect() to [Node IP] port 443 (0) * Trying [Node IP]... connected * Connected to [Node IP] ([Node IP]) port 443 (0) * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv3, TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to [Node IP]:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to [Node IP]:443 [Active:In Sync] config

Below is the setting/config of the VS:

 

(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual [VS Name] all-properties ltm virtual [VS Name] { address-status yes app-service none auth none auto-lasthop default bwc-policy none clone-pools none cmp-enabled yes connection-limit 0 description none destination [VS IP]:https enabled fallback-persistence none flow-eviction-policy none gtm-score 0 ip-protocol tcp last-hop-pool none mask 255.255.255.255 metadata none mirror disabled mobile-app-tunnel disabled nat64 disabled partition Common per-flow-request-access-policy none persist { cookie { default yes } } policies none pool [Pool Name] profiles { [SSL Profile] { context clientside } http { context all } serverssl { context serverside } tcp { context all } } rate-class none rate-limit disabled rate-limit-dst-mask 0 rate-limit-mode object rate-limit-src-mask 0 related-rules none rules none security-log-profiles none source 0.0.0.0/0 source-address-translation { pool none type automap } source-port preserve syn-cookie-status not-activated traffic-classes none translate-address enabled translate-port enabled urldb-feed-policy none vlans none vlans-disabled vs-index 15

Below is the setting/config of a working VS that has a node ip from the same subnet.

 

ltm virtual [VS Name] { address-status yes app-service none auth none auto-lasthop default bwc-policy none clone-pools none cmp-enabled yes connection-limit 0 description "description" destination [VS IP]:https enabled fallback-persistence none flow-eviction-policy none gtm-score 0 ip-protocol tcp last-hop-pool none mask 255.255.255.255 metadata none mirror disabled mobile-app-tunnel disabled nat64 disabled partition Common per-flow-request-access-policy none persist { cookie { default yes } } policies none pool [Pool Name] profiles { [SSL Profile] { context clientside } http { context all } serverssl { context serverside } tcp { context all } } rate-class none rate-limit disabled rate-limit-dst-mask 0 rate-limit-mode object rate-limit-src-mask 0 related-rules none rules none security-log-profiles none source 0.0.0.0/0 source-address-translation { pool none type automap } source-port preserve syn-cookie-status not-activated traffic-classes none translate-address enabled translate-port enabled urldb-feed-policy none vlans none vlans-disabled vs-index 4
6 REPLIES 6

LA_Medina_32319
Nimbostratus
Nimbostratus

Forgot to mention HTTPS monitor doesn't work on the Pool. It is marking the node down which would explain the SSL failure. So right now i just used ICMP as a monitor first just to bring the Node up.

 

JG
Cumulonimbus
Cumulonimbus

Please share the output of:

 

openssl s_client -connect node_addr:port

 

.

 

Are you nodes ssl or non-ssl.

 

If they are non ssl nodes, there's no point of putting https monitor, it will fail. You gotta try putting http monitor.

 

Having node ip from the same subnet does not mean it is ssl server. Maybe the one working is having ssl enabled and thats why https monitor is put and like wise a serverssl profile.

 

But if your current non-working is non ssl, put http monitor and remove serverssl profile. Try http instead of https.

 

curl -vk http://[Node IP]

 

If your http/https monitor is marking it as up and still VS is inaccessible, we can troubleshoot further.

 

Stanislas_Piro2
Cumulonimbus
Cumulonimbus

Hi,

 

Does the server require SNI?

 

Try

 

openssl s_client -connect [node IP]:443 -servername app.company.com

App.company.com is the application fqdn for which you have a certificate.

 

LA_Medina_32319
Nimbostratus
Nimbostratus

Hi Guys,

 

I was just told by server team that it is actually for ADFS server.

 

Snl
Cirrostratus
Cirrostratus

to make it simple , use ADFS IApp iApp-Templates