Xenserver 7.0 not working

We're currently implementing v7.0 support, please bear with us.

Thank you, any estimated date?

Since we have yet to find out what exactly changed in the API, this may take some time. Usually, we don't give any estimates, but I hope we'll be done in about 1-2 months.

I also upgraded a XenServer pool from 6.5 to 7.0. The 'Citrix XenServer Virtual Machine' sensors are working, however the 'Citrix XenServer Host' sensors are not. I'm unclear if this behaviour is different from tom234679.

Two additional issues discovered are;

1. The VM sensors only ever use HTTP, even though 'VMware Protocol' is configured for HTTPS in settings. Blocking port 80 on XenServer through iptables, all VM sensors went Red.

2. Following initial upgrade Host sensors (using HTTPS) failed 'Could not find any data for the host with the uuid: xxx-xxx-etc' as reported.

After hardening XenServer SSL to TLS1.2 the error changed to 'The underlying connection was closed: An unexpected error occurred on a send.'

For hardening I followed Citrix 'xenserver-7-0-release-notes.pdf' page 9 : Advisories and Known Issues -> Security.

Resulting 'etc/xensource/xapi-ssl.conf',
...
[xapi] accept = :::443
connect = 80
cert = /etc/xensource/xapi-ssl.pem
ciphers = !SSLv2:RSA+AES128-SHA256
TIMEOUTclose = 0
options = NO_SSLv2
options = NO_SSLv3
sslVersion = TLSv1.2

Logging '/var/log/secure',
Aug 15 15:50:29 xen1 stunnel: LOG3[25192:139624009754368]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number

For me neither work. I'm on the latest patch level of 7.0

7.0 is working again in the Canary build of PRTG - it will take some time until it reaches the stable build, probably early September. Thanks for your patience on this!

I switched from Preview to Canary v16.3.26.5718. Host sensors are working again to fully patched XenServer (including XS70E010 Toolstack). Many Thanks for resolving this problem.

HTTP/HTTPS problems 1 and 2 above are still apparent, is it planned to resolve these ? do I need to log a separate KB number ?

Please let me know when this goes in either your Preview or Canary build. Would be willing to test.

I just tried in 16.3.26.5718 and I am still unable to add the hosts.

What specific error do you get and what patchlevel are you on? As it seems to work for Android256, apart from the HTTPS problem...

The message i receive is:"The request was aborted: Could not create SSL/TLS secure channel." My Current 7.0 Patches are XS70E002 through XS70E010 Xenserver build date:2016-07-26 XenServer build number:125380c DBV:2016.0520

Could you run sslscan (https://github.com/rbsec/sslscan/releases) against this URL: https://<xenserver>:<xenport>/rrd_updates

We need the complete output of it to determine the supported SSL protocols. Thanks!

I wasn't sure who the request was meant for so I went ahead and made some tests.

Using TestSSLServer4 diagnostics tool (http://www.bolet.org/TestSSLServer/) to XenServer I get the following list of ciphers supported when in TLSv1.2 enforcing mode,

3-- (key:  RSA)  RSA_WITH_AES_128_CBC_SHA256 \\
3-- (key:  RSA)  RSA_WITH_AES_256_CBC_SHA256 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_128_CBC_SHA256 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_256_CBC_SHA256 \\
3-- (key:  RSA)  RSA_WITH_AES_128_GCM_SHA256 \\
3-- (key:  RSA)  RSA_WITH_AES_256_GCM_SHA384 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_128_GCM_SHA256 \\
3f- (key:  RSA)  DHE_RSA_WITH_AES_256_GCM_SHA384 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_CBC_SHA256 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_CBC_SHA384 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_128_GCM_SHA256 \\
3f- (key:  RSA)  ECDHE_RSA_WITH_AES_256_GCM_SHA384 \\

Using Wireshark to discover the ciphers proposed by PRTG I decoded the request as,

Secure Sockets Layer \\
TLSv1 Record Layer: Handshake Protocol: Client Hello \\
Content Type: Handshake (22) \\
Version: TLS 1.0 (0x0301) \\
Handshake Protocol: Client Hello \\
Handshake Type: Client Hello (1) \\
Version: TLS 1.0 (0x0301) \\
Cipher Suites (12 suites) \\
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) \\
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) \\
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) \\
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) \\
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) \\
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) \\
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) \\
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) \\
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) \\
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) \\
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) \\
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) \\

The response from XenServer is,                    
                    
Secure Sockets Layer \\
TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) \\
Content Type: Alert (21) \\
Version: TLS 1.0 (0x0301) \\
Alert Message \\
Level: Fatal (2) \\
Description: Protocol Version (70) \\

The obvious problem is that PRTG is making the request using TLS v1.0 and XenServer rejects that when in TLS v1.2 enforcing mode.

Please consider including a TLS version selection (1.0, 1.1, 1.2 etc) for "VMware Protocol = HTTPS". I guess that other hardware manufactures will start to enforce TLSv1.2 breaking monitoring...

Also, is there any news if the VM sensors will use HTTPS instead of incorrect HTTP, item 1 ?

Currently on 16.3.28.6626 after switching from Canary to Preview a while ago.

Thanks Andrew

I'll forward it to the developer, so he can take a look at it and do the necessary code changes, if needed :)

I just saw that we already have a bug ticket for that, thanks for the additional info. Certainly helpful! :)

That is good news.

Please ask developer to optomize XenServerRRDSensor.exe if possible as it consumes a lot of CPU cycles...

Btw, I notice that PRTG 16.3.28.6626 is using XenServer.dll v6.0.0.1 which is several years out of date, SDK 7.0.0 is available from Xenserver.org which supports TLS1.2 as below code extract suggests,

public static Stream ConnectStream(Uri uri, IWebProxy proxy, bool nodelay, int timeout_ms)
......
sslStream.AuthenticateAsClient("", null, SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, true); ......

Forwarded as well, thank you very much for making PRTG more awesome and the life of our devs easier :)

Sorry, fell off the map due to being slammed with other stuff at work. I use xenserver for my home lab. Thank you for supplying the info Android256.