Forum Discussion
Ryan_34424
Altostratus
AltostratusAPM :: VMware View :: Blast HTML5
I'm trying to get the APM functioning with VMware View Blast client - and I am having quite the time. I have tried the iApp (1.5) but haven't been able to get that to function either. At the moment, I have a manual configuration based-off of the deployment guide.
The deployment guide says to create a forwarding virtual server, and the iApp does the same thing. Neither of which seem to be working for me.
So with the forwarding VS above created…
I can log-in fine, the webtop displays, the RDP link I have works great... the Blast HTML5 link... not so much. If I click on the VMware View desktop shown above, it brings me to the following:
The error shown above is thrown-around a lot by View, so it’s hard to say what the real problem is. I’ve seen that error displayed for straight-up communications issues in the past… which I think this is. If I do a tcpdump on the BIG-IP, I can see it trying to connect to 8443, but it cannot connect (SYNs… no SYN/ACKs).
11:27:30.022625 IP x.x.x.10.28862 > x.x.x.252.8443: Flags [S], seq 2246191783, win 4140, options [mss 1380,sackOK,eol], length 0 out slot1/tmm0 lis=/Common/xxxxxxxxxxxxxxxxxxxx-https
Source is the floating IP, destination is the VS.
I know 8443 is listening on the VMware View server because I can connect to it locally. And I know the VMware View server knows how to get back to the F5 because it populates the webtop with my available desktop(s) shown above.
I tried converting the forwarding VS to standard, assigned a pool, etc… and it still did the same thing. SYNs… no SYN/ACKs.
What might be telling though is the
lis=That makes me think though… Why is it trying to connect to that VS and not the forwarding VS? The forwarding virtual server is a better match no? In any event, yeah if the virtual server isn’t listening on 8443, of course it won’t reply back (my thought-process anyway).
So I figure… welp, why not just try an “any” port VS… yeah not so much.
If I manually remove the :0 and submit, it loads the same error about the certificate. Nothing shows-up in tcpdump trying to connect to 8443 either - so, a step back.
If anybody happen to have any ideas for me, I would be really appreciative.
Thanks!
Ryan77777Altocumulus
VMware version is 6.1.1
- Matt_Mabis
Employee
Hey Ryan What build/version of BigIP are you using?
only reason i ask is to make sure you are running at minimum v12.0 HF1 as per the deployment guide.
BIG-IP APM v12.0 requires HF1 to support the Horizon View HTML5 client in Horizon View 6.1.1 or later.
Also can you send a screenshot of the Connection Server Instance APM is utilizing are any of the tunnel boxes ticked?
Thanks Matt
- Ryan77777
I'm using BIG-IP 12.1.1 Build 1.0.196 Hotfix HF1 on a vCMP instance (if that matters).
Connection Server screenshot:
- Ryan77777
- Matt_Mabis
Hey Ryan,
The boxes for the Tunneling should be all unchecked when using APM, could you try unchecking all of the boxes and try again?
Just out of curiosity as well, your locked.properties file, are you using a lot of mixed clients? just trying to understand why you have all of those protocols enabled...
Also if you didnt know F5 and VMware have collaborated to showing this kind of configuration in a lab environment, these configurations might be useful to your implementation.
HOL-MBL-1759 Module 3 for APM and PCoIP Proxy http://labs.hol.vmware.com/HOL/catalogs/lab/2792
Also you can just goto the manual section as per this link http://docs.hol.vmware.com/HOL-2017/hol-1759-use-3_html_en/l531442
- Ryan77777
I don't have access to the VMware stuff, so I have to rely on another group to tell me what they have configured (unfortunately). They originally had these checked, so I had them un-check them:
I attempted to connect again, and I received the same certificate error I did originally. My packet capture on the BIG-IP no longer showed port 8443 attempts either.
If I attempt to click on the link displayed in the error message, I just get a connection reset.
- Ryan77777
I'm not sure if this is cosmetic or not...
Nov 14 12:58:06 10.1.41.190 debug vdi[5564]: 01490000: {2c.C.abb9a0d7} [HandleResult][68] 17SetSessionDBValue result 'tmm.session.abb9a0d7.session.vmware_view.connection_server.a875c6c9-2020-4590-a978-2e34a3b9587b' = 'x.x.x.91%0:443'... but it's showing a route domain of zero?
I'm configured for a route domain of 134:
Also, my desktop is assigned a route domain of 0 as well:
Nov 14 12:58:06 10.1.41.190 debug vdi[5564]: 01490000: {2c.C.abb9a0d7} [HandleResult][68] 17SetSessionDBValue result 'tmm.session.abb9a0d7.session.vmware_view.desktop.a875c6c9-2020-4590-a978-2e34a3b9587b' = 'x.x.x.10%0:22443'If this isn't just cosmetic, then that's probably my problem. Which I don't understand because I assign it to the proper RD in the VPE.
Nov 14 12:58:05 10.1.41.190 debug vdi[5564]: 01490000: {2c.C.abb9a0d7} [HandleResult][68] 17GetSessionDBValue result 'tmm.session.abb9a0d7.session.assigned.route_domain' = '134' - Ryan77777
Ok - I figured it out.
That route domain of zero must just be cosmetic... because now it's working once I allowed port 22443 out of RD 134 on the network firewall.
So with a combination of those tunnel checkboxes (or lack thereof) and the firewall rule for TCP/22443 - that seems to have resolved my issue.
Thanks Matt for your help.
- Ryan77777
Resolved by removing the checkboxes on the VMware View server, and allowing port TCP/22443 through the firewall. Thank-you Matt again for your assistance.
- Matt_Mabis
No Problem, glad it worked out just keep in mind if using these brokers internally for HTML5 blast they might experience now issues with SSL errors as they are not tunneling that HTML5 internally 2 ways to resolve this
1) use APM internally
2) setup separate connection brokers with the HTML5 blast box ticked to resolve.
Hope this helps!
