Jump to content
Welcome to our new Citrix community!

Backend Monitor - Failure - Time out during SSL handshake stage


Recommended Posts

I've got this error when I create a Monitor HTTPS-ECV: 

 

Failure - Time out during SSL handshake stage

 

Service Group Config.

 

ProtocolSSL

State ENABLED

Effective StateDOWN

Traffic Domain0

Comment

Cache TypeSERVER

Cacheable NO

Health Monitoring YES

AppFlow Logging DISABLED

Monitoring Connection Close Bit NONE

Number of Active Connections 0

AutoScale Mode DISABLED

 

 

Cipher Used: TLS v1.2 ECDHE-RSA-AES128-GCM-SHA256

 

I have another set of NetScaler that is able to connect to the Server with the same configuration (SSL Ciphers, IP, Port, etc) but for an unknown reason this set of NetScaler do not want to connect.

 

I've read pretty much every bit of documentation and forums and was not able to find a cue about how to fix this. 


Thanks for your help.


JF

 

 

Link to comment
Share on other sites

as you get "Failure - Time out during SSL handshake stage"

 

first you should try to validate that there are no  routing issues between the these vpx's and the servers.

If possible try to create a http service on the netscalers if the servers are listening  for http request as well, or any other port/service they are listening on.

 

 

 

 

 

Link to comment
Share on other sites

Hi,


The security of the network will not permit the HTTP protocol on the network, so I was not able to do the Test.


TCP-ECV is working tho.


Is there any way that I can use a SNIP (VIP) of the NetScaler to test HTTPS URL from the command line to confirm that the network is working properly ?


Thanks,


JF

Link to comment
Share on other sites

if TCP monitor(i am guessing that it is on the same port) works than i guess it should be fine. Also make sure there are no firewalls to block the traffic between the SNIP and the servers.

 

On the Netscaler, under shell there is telnet and it has an option [-s src_addr]. but it did not work for me.

 

Based on the routes it has ,your Netscaler will pick the SNIP address that it will use to sent the data to the server.

 

 

Maybe it might be useful to do a tcpdump (/nstrace on a  netscaler) or on the server.

 

 

Link to comment
Share on other sites

if you remove all the monitors it will use teh default one : tcp-default.

Using this it will only check if the port is listening, so it does not care of certificates.

 

So probably your https monitor is not set up ok.

 

Can you share your monitor config?

 

it should look like this : 

add lb monitor <monitorName> <type> -secure  YES 

 

Also be aware that when the netscaler is connecting to the server it will us a default profile : ns_default_ssl_profile_backend, if you have not create a custom one. 

 

 

 

 

Link to comment
Share on other sites

you said tcp-ecv is working "TCP-ECV is working tho." 

then the default tcp monitor should work also.

 

can you share the dump, screenshot of the dump?

 

Do you see any packets coming from the servers? if you say that this monitor (TCP-ECV ) works that it is not an issue with routing.

Also make sure there are no ip conflicts in your network.

Link to comment
Share on other sites

1 minute ago, Mihai Cziraki1709160741 said:

Do you see any packets coming from the servers? if you say that this monitor (TCP-ECV ) works that it is not an issue with routing.

 

 

Hi, No it does't seems to be a routing issue, the server is responding to the request.

 

I see packet from SRC -> DST and DST -> SRC so the netscaler is able to communicate with the server.


At that point it is either the NetScaler backend that is not able to talk with the https server or our firewall IPS is doing something very wrong with the https request.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...