Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

No Reply from VMWare View broker...

Has anyone out there experienced a similar issue? I'm testing 11.4.1HF3 and 11.5.0 for a replacement APM installation. The APM works fine for Citrix (No web interface, the webtop is configured for citrix remote desktops).

When I put VMWare View remote desktops on the webtop, the citrix still works, but the VMWare View ones showup as a broken icon. Looking at the traffic between APM and the VMWare brokers, we see the request sent, and then the connection closes... Using the exact same request via curl (From the APM server) results in the XML response coming back correctly...

Anyone got any idea what the VMWare View broker is expecting? Literally the only thing different between curl (Working) and APM (Not working, is the User Agent, accepts and Content-Type headers... But I can't believe I'm the only one as F5 Supporta re yet to find any errors in my config... (And it's not like the deployment guides for VMWare View are any more involved than Citrix or ahave anythign ultra special in them).

This isn't a problem with the PCoIP traffic. We can't even get that far. It's the initial request from Client to Broker that's failing..

H

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 28-Feb-2014 by Hamish 3414
Tomorrow I'm also going to try HTTP (Requires firewall change). And get the VMWare guy to enable SSL Offload. See if that makes a diff... Currently it's all HTTPS (Which makes it slightly difficult to see what's actually going to the Broker)
0
Comment made 28-Feb-2014 by Hamish 3414
It's horizon view 5.3 running on esxi 5.5
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

v5.3 on ESXi5.5

0
Comments on this Answer
Comment made 28-Feb-2014 by Greg Crosby
Do you know what client and client version is being used when you see this behavior?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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...

0
Comments on this Answer
Comment made 28-Feb-2014 by Hamish 3414
Doh! Even in quoted code this site doesn't like embedded tags! ARGH!!!!
0
Comment made 28-Feb-2014 by Michael Koyfman 2088
Can you specify an actual View Connection Broker note as the APM View Resource instead of the layered virtual?
0
Comment made 28-Feb-2014 by Hamish 3414
Tried that... No change... Going to try HTTP only tomorrow...
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 28-Feb-2014 by Hamish 3414
Time to think on it... Need to go pick up my bike before the shop closes... Mmm... Time for a ride...
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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).

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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...

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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"?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
  1. Yes
  2. Not exactly. I have a webtop. Up till friday the view connection broker wouldn't respond. By adding in client certs to a new the server_ssl profile it started to respond. Might have been VMWare config perhaps (We got strange cert auth errors until I did that. Maybe it was SSL level negs. Same request worked fine with curl, UNLESS you disabled TLS (i.e. would;t work with SSLv2 or SSLv3). Since Saturday (Change of server_ssl profile), the broker works. HOWEVER it only works for HTML5 client. Not for Horizon View from web top (Connection opens and the VDI RESETS (tcp reset) the connection to APM after about 150ms.
  3. That's correct. A SNAT pool doesn't work. It doesn't matter WHAT I specify for SNAT. The BigIP's selfip is ALWAYS used (There is no floating selfip the APM is stand-alone currently. Will be 3 of them load-balanced by GTM eventually).
  4. Any cert. I'm going to play more. It may be tied to versions of SSL enabled on the profile. But VMWare doesn't log WHY it closes connections. It just does... Grr..

Note. I don't believe this is an APM problem now (Except in as far as a config error at APM could be causing it, but the lack of logs from VMWare explaining WHY it's closing the connection is... annoying...

We're getting closer... Different connections closing now... But the connection broker works...

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Thanks for this information.

It looks like there are several problems here:

  1. SNAT pool is not working
  2. Horizon View client time outs establishing connection from APM Webtop
  3. HTML5 client uses port 22443. I assume you mean the connection from APM to View Desktop. This should be documented by VMware.
  4. There is some mysterious problem on SSL layer.

I wonder if (4) is caused by configuration on View Connection Server? I only have 5.2 environment and I can't recall any such certificate option in GUI except for SmartCard auth which APM does not support at the moment. I assume it's something else - but still worth checking. Also, there are a bunch of options that VCS does not expose to GUI - they are configured via "locked.properties" file somewhere under VCS installation folder. Maybe you have something there?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
  1. Agreed.
  2. Not timeouts. You can see the connections made. VMWare RESETS (tcp reset) the connections AFTER they're established.
  3. HTML5 works. No issues with that. Yes, over tcp/22443
  4. Well, there was an issue. I need to do some more investigation to find out WHAT was wrong with the server_ssl profile. Probably a setting in VMWare somewhere. But we haven't found out what yet...

H

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hamish,

It appears we are having a similar issue with the F5 timeout when connecting to a VMware View 5.3 connection server. The strange part is I can authenticate to APM and from the APM logs the connection was sent down the correct allowed branch but then I receive a connection with the server was terminated abnormally View error. Just curious if you ever found a solution.

Thanks, Scott

0
Comments on this Answer
Comment made 07-Sep-2016 by Saadat 1

too late to response by may be it will help someone going through this. I found issue with my routing when getting connect reset to VDI. Changed gateway which was pointing towards external vlan to internal vlan and it worked.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Umm... yeah. There's a couple of other postings around here on what we had to do. I keep meaning to try & have words with the devs about making sure that the logs from APM mean something and provide meaningful info when you're trying to debug things. There's a few places where the logs are just a wee bit too subtle.

The biggest things I found were

  1. Missing the server name being set in the PCOIP ssl profile used for connecting to the server
  2. Adding either an AVR or logging profile to the VS (Silent failures)

2 is more likely... It just breaks. I added a custom iRule to log the info. I suspect that when the PCoIP stream is started the AVR/Log profile isn't disabled, and they abort the stream because they can't interpret the traffic (I still dislike that feature/bug).

Hamish

0