FWIW, it is also good to check if there are any issues with the MTU. Assuming 
the interface MTU on CPVM is set to 1500 bytes, please see if you can get 
responses using the below command by executing inside of the CPVM

# ping -M do -s 1472 <public_ip_gateway>

If the above works properly, could you also get your cert signed by a different 
CA like ZeroSSL and then try testing? We'll see if this makes any difference (I 
don't think it does, but let's try).

Thanks,
Jayanth

Sent on the move

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Fariborz Navidan <[email protected]>
Sent: Sunday, August 4, 2024 5:13:23 am
To: [email protected] <[email protected]>
Subject: Re: Long time to load noVNC

Hi,

I have double checked resources and network status on both the host and
CPVM. The host's CPU/RAM utilisation is under 20% and CPU usage of console
VM during the long response time is around 0.3%.

I just reverted the "'consoleproxy.sslEnabled" setting back to false and
then restarted console VM and it responds immediately. In other hand, when
above setting is set to true, CPVM struggled with SSL connection.

The uploaded cert is a valid Let's Encrypt one along with unencrypted PKCS8
private key.

Any idea on what's happening?

Regards.

On Sat, 3 Aug 2024, 18:13 Jayanth Babu A, <[email protected]>
wrote:

> Hi,
> It may indicate a resource or network issue. Just in case, have you
> already checked the CPU & memory utilization on the CPVM & on the host?
> The below trace shows that the TLS handshake is taking time.
>
>
> $ curl -vIL --trace-time https://console.r9host.com
>
> 14:37:46.203639 *   Trying 149.50.127.131:443...
>
> 14:37:46.203710 * TCP_NODELAY set
>
> 14:37:46.464621 * Connected to console.r9host.com (149.50.127.131) port
> 443 (#0)
>
> 14:37:46.465004 * ALPN, offering h2
>
> 14:37:46.465165 * ALPN, offering http/1.1
>
> 14:37:46.470305 * successfully set certificate verify locations:
>
> 14:37:46.470389 *   CAfile: /etc/ssl/certs/ca-certificates.crt
>
>   CApath: /etc/ssl/certs
>
> 14:37:46.470604 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
>
> 14:38:14.752752 * TLSv1.3 (IN), TLS handshake, Server hello (2):
>
> 14:38:14.752950 * TLSv1.2 (IN), TLS handshake, Certificate (11):
>
> 14:38:14.754551 * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
>
> 14:38:14.754989 * TLSv1.2 (IN), TLS handshake, Server finished (14):
>
> 14:38:14.755663 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
>
> 14:38:14.756040 * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
>
> 14:38:14.756446 * TLSv1.2 (OUT), TLS handshake, Finished (20):
>
> 14:38:15.279001 * TLSv1.2 (IN), TLS handshake, Finished (20):
>
> 14:38:15.279063 * SSL connection using TLSv1.2 /
> ECDHE-RSA-AES256-GCM-SHA384
>
> 14:38:15.279096 * ALPN, server did not agree to a protocol
>
> 14:38:15.279131 * Server certificate:
>
> 14:38:15.279177 *  subject: CN=console.r9host.com
>
> 14:38:15.279227 *  start date: Aug  3 07:42:27 2024 GMT
>
> 14:38:15.279270 *  expire date: Nov  1 07:42:26 2024 GMT
>
> 14:38:15.279312 *  subjectAltName: host "console.r9host.com" matched
> cert's "console.r9host.com"
>
> 14:38:15.279349 *  issuer: C=US; O=Let's Encrypt; CN=R10
>
> 14:38:15.279396 *  SSL certificate verify ok.
>
> 14:38:15.279499 > HEAD / HTTP/1.1
>
> 14:38:15.279499 > Host: console.r9host.com
>
> 14:38:15.279499 > User-Agent: curl/7.68.0
>
> 14:38:15.279499 > Accept: */*
>
> 14:38:15.279499 >
>
> 14:38:15.540409 * Mark bundle as not supporting multiuse
>
> 14:38:15.540539 < HTTP/1.1 404 Not Found
>
> HTTP/1.1 404 Not Found
>
> 14:38:15.540631 < Content-Length: 50
>
> Content-Length: 50
>
> 14:38:15.540671 < Content-Type: text/html
>
> Content-Type: text/html
>
>
>
> 14:38:15.540706 <
>
> 14:38:15.540738 * Excess found: excess = 50 url = / (zero-length body)
>
> 14:38:15.540809 * Connection #0 to host console.r9host.com left intact
>
>
> Regards,
> Jayanth Reddy
>
> From: Fariborz Navidan <[email protected]>
> Date: Saturday, 3 August 2024 at 3:06 PM
> To: [email protected] <[email protected]>
> Subject: Long time to load noVNC
> Hello Everyone.
>
> I have a strange problem with console proxy after enabling SSL. I have got
> a valid certificate and uploaded into CS (v4.18.2.1). Afterward, the
> console proxy takes a long time to load. For example when I browse to
> https://console.mycompany.com, it take a few minutes to send response and
> when I click the "view console" button in a VM view page, it takes a few
> minutes to load noVNC at
>
> https://console.r9host.com/resource/noVNC/vnc.html?autoconnect=true&port=8443&token=
> .
> ..
>
> Any idea why console provy VM is such slow?
>
> Thanks in advance.
> Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL
> INFORMATION intended solely for the use of the addressee(s). If you are not
> the intended recipient, please notify the sender by e-mail and delete the
> original message. Further, you are not authorised to copy, disclose, or
> distribute this e-mail or its contents to any other person and any such
> actions are unlawful and strictly prohibited. This e-mail may contain
> viruses. NxtGen Datacenter & Cloud Technologies Private Ltd (“NxtGen”) has
> taken every reasonable precaution to minimize this risk but is not liable
> for any damage you may sustain as a result of any virus in this e-mail. You
> should carry out your own virus checks before opening the e-mail or
> attachment. NxtGen reserves the right to monitor and review the content of
> all messages sent to or from this e-mail address. Messages sent to or from
> this e-mail address may be stored on the NxtGen e-mail system. *** End of
> Disclaimer ***NXTGEN***
>

Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
intended solely for the use of the addressee(s). If you are not the intended 
recipient, please notify the sender by e-mail and delete the original message. 
Further, you are not authorised to copy, disclose, or distribute this e-mail or 
its contents to any other person and any such actions are unlawful and strictly 
prohibited. This e-mail may contain viruses. NxtGen Datacenter & Cloud 
Technologies Private Ltd (“NxtGen”) has taken every reasonable precaution to 
minimize this risk but is not liable for any damage you may sustain as a result 
of any virus in this e-mail. You should carry out your own virus checks before 
opening the e-mail or attachment. NxtGen reserves the right to monitor and 
review the content of all messages sent to or from this e-mail address. 
Messages sent to or from this e-mail address may be stored on the NxtGen e-mail 
system. *** End of Disclaimer ***NXTGEN***

Reply via email to