No Reply from VMWare View broker...

Hamish,

It definitely should work. Have you provided vdi debug log to F5 support? vdi debugging is turned up from tmsh:

tmsh modify sys db log.vdi.level value debug

Don't forget to turn it back to notice after you're done troubleshooting.

Also, what version of VMware View are you testing with?

If you upload qkview with debug log information to iHealth, message me the link and I will take a look - have not seen that issue before at all.

yeah. It's a weird one...

F5 Support have all the debugs. but they seem as stumped as me... I'd like to blame the VMWare itself. But hard to when it looks like bigip is closing the connection and resetting it. Plus curl manages to get a response...

I think they're running 5.0? (The broker Version reported in the XML from the response curl gets is 7.0, but I don't know how that relates to VMWare View version)

I'll upload a qkview (Need to generate a new one, I've just put 11.5.0 on there. Not sure I like it... I know they won't let me use 11.5 in production until at least 1 HF rollup comes out :) )

H

Hamish,

Actually, it's extremely important to find out what version of View they are running, because only View 5.2 or later is supported - 5.0 is not supported and does not work.

v5.3 on ESXi5.5

Yeah. Any browser, any OS...

MacOSX 10.9.2 and Safari MacOSX 10.9.1 and Safari

• Also Firefox, and Chrome with the above two OS's

Plus Windows. XP and 7. Using IE, Firefox & Chrome.

Pretty much a full house...

haven't tried a direct VMWare View Client. It's all browser access at the moment.

This is the SSLDump info...

POST /broker/xml HTTP/1.1
Host: 10.21.16.20
Content-Type: text/xml
Cookie:
Content-Length: 649

windows-passwordusernamehamish.marsonpasswordXXXXXXXXXXXXXdomainDOM1PCOIPBLASTtrue

13    0.0015 (0.0000)  S>C  TCP FIN
13    0.0025 (0.0009)  C>S  TCP FIN

Which APM log reports as an Error 500... Even though there's no actual return from the broker... (The SSL dump was taken at the layered VS we're using for fronting the broker).

A curl request using the exact same body (Only diff is the headers which look like

> POST /broker/xml HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/1.0.1e     zlib/1.2.3 libidn/0.6.5
> Host: 10.21.16.20
> Accept: */*
> Content-Length: 649
> Content-Type: application/x-www-form-urlencoded

Works fine. Response comes back. It's reasonably obvious that the view server doesn't like something in the headers... Which if I get really annoyed tomorrow I may use an iRule to re-write and see if I can discover what...

Sigh... Using openssl s_client doesn't work with the curl pasted headers & query... SSL version used perhaps? Does that get passed through on an SSL Offloaded VS to the poolmember? Not sure it does... They should be independent...

H

Today we get further. The VMWare guys enabled debugging on the logs. It seemed to be complaing about invalid client certs...

We aren't using client certs...

So I added one to the serverssl of the VS at APM (Not the layered on mind you). And it sprang into life via the layered VS (Not direct). It's not got the desktop. But gets weirder, because I have NO idea why the layered stuff now works, but direct doesn't when it's VMWare Broker that's complaining about clientside certs...

It's all very strange... The VMWare VDI daemon seems to ignore the SNAT settign on the APM VirtualServer too. It uses the APM's inside IP address to connect to the brokers... Always... So why would changing the serverssl profile of that VS change anything? Very weird... Seems inconsistent to me (Especially since the whitepapers all say to enable AutoSNAT. But it doesn't seem to matter WHAT you set SNAT too. It always seem to us auto (I use a pool by preference to separate different VS's), which works for the citrix stuff. Just not vmware).

And we get further..

VMWare View seems to be pretty sensitive to the backend encryption... Some changes required there to make it work. Including adding in certs to the serverssl config.

After that, and opening up port 22443 (not documented in the deployment guide that i can find) HMTL5 access works. yay!

Horizon view is still a bit of a pain. it starts, and a connection is established from APM to the VDI (tcp/4172) but after about 150ms the VDI resets the tcp connection. No explanation why...

But at least we're now getting somewhere... Sort of... Slowly...

Hi Hamish,

Let me double check your findings. Are you saying that:

1. You're using 5.3 backend, right?
2. You're using HTML5 client from APM Webtop, right? Have you tried native client from APM Webtop?
3. SNAT pool does not work for you while AutoMap works, right?
4. Client cert is required on the serverssl profile. What kind of client cert? Is View Connection Server configured to check client certs?

P.S. the fact that VDI closes the tcp/4172 connection after 60s is according to the PCoIP protocol specification. We close the connection if we have not received any data from the backend within that time slot. Let me ask you - have you configured serverssl profile to use SNI "pcoip-default-sni"?