APM :: 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= above. It lists my main virtual server with the APM policy assigned. 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!
VMware HTML5 RDSH / remote app support
Hi Just wanted to get some clarification around support for RDSH apps using HTML 5. Is the functionality supported by F5 APM? In the v12.1 APM compatibility matrix it mentions RDSH app via HTML wasn't supported, that statement isn't in the v13.1 APM compatibility matrix. The iApp deployment guide (https://www.f5.com/pdf/deployment-guides/vmware-horizon-view-dg.pdf) doesn't mention it at all. Cheers, Simon
HTML5 WebSocket rewriting
I am having an issue with rewriting my WebSocket connection. Let me explain my scenario, and then I will explain the issue I am experiencing. On my Internal network (192.168.252.x) I have a HTML5 gateway device(252.100), that is used to establish an HTML5 RDP session. This component is setup correctly, from the internal network I am able to log into the web based interface and successfully establish an HTML5 based RDP connection from my HTML5 gateway device (252.100) to my target machine 252.101. What I am trying to accomplish is to do this HTML5 RDP connection going through the F5. From the webtop, my user will click on a portal access link. This portal access link takes the user to the web based front-end of my HTML5 gateway device via and https webpage. My user is able to successfully go through the webtop, and log into my web front end. The issue occurs when starting the HTML5 RDP session from the webtop. My HTML5 proxy machine is throwing an error saying Websocket closed. Tracing the network traffic between all components, there is no traffic flow from the HTML gateway and the Target machine, and no traffic flows into the HTML gateway. This is due to the fact that the Websocket is not being rewritten by the F5. I will try to attach an image with the Chrome dev console that shows this websocket address: In short: when a new websocket is created I get the following: WebSocket connection to 'wss://192.168.252.100/myservice?mypage.hsl_mode=DIRECT&servicename_name=encodedlinkname failed: Error in connection establishment net::ERR_CONNECTION_TIMED_OUT. What I would expect to see is not the direct Internal IP address of the HTML5 gateway but some External IP from the F5 since the websocket should be rewritten by F5. My External net address is 192.168.210.x. I am testing from 192.168.210.100 and my F5 External self IP is 192.168.210.22. So I would expect to see that the websocket address would the External SelfIP. I have attempted playing around with the HTTP profile, Redirect Rewrite settings (None, All, Matching, and Nodes). But this didn't seem to help. I have also tried creating a WebSocket profile and tested all the Masking settings, (Preserve, Unmask, Selective, and Remmask) Also no dice. I have tested quite a few settings on the other profiles as well without any luck. Any suggestions would be helpful. As a side note: I was able to get this successfully running on Big-ip 11.4. With the same configuration, I am not able to get this working on our newer 12.1 implementation. I am also currently unable to observe the 11.4 websocket creation behavior as this VE install has eaten itself while trying to do a version update.. But that is another story.APM SSO with Atlassian Jira, Confluence and Sharepoint
Hi, For one of our clients we are trying to realize a single sign on solution on our F5 for Atlassian Jira, Confluence, Stash and Sharepoint. To this end we have created a virtual server with an APM policy of type LTM-APM. All websites are published through one and the same Virtual Server. We filter host-headers (HTTP::host) in order to decide which backend server traffic needs to be forwarded to and use different SSO Configurations for connecting to the backend. In addition we used a community iRule to provide for Sharepoint-office integration SSO (as provided here: https://devcentral.f5.com/codeshare/apm-sharepoint-authentication) with some tweaks. Although SSO works we're still struggling with issues that we've not yet been able to resolve and we think are related to the fact that especially Jira and Confluence are stateful HTML5 applications with ajax. This in combination with the fact that there is no integration between the F5 and the backend webservers. These problems are giving me a headache. I've already searched devcentral but have been unable to find a solution for our problems. Amongst others the following problems are encountered: When a logged on user is inactive for some time he runs into an APM session inactivity timeout (F5 side) and the session is deleted from the session table; This shouldn't be a problem in a normal situation, but the webapplication clientside does not signal the user that the session expired. Now when the user comes back again and clicks somewhere on the webpage 1 of 2 things may happen: a. The user clicks a link which fires a javascript/ajax/restapi-call; this script may perform a call to the backend server, is blocked by the F5 and redirected to a login page in the background. For the user this means an unresponsive webapplication with a doughnut or an error on the screen (without the F5 in between the user would also get an 'error', but with a possibility to copy data that will be lost and a link to the logon page). For the user the webapplication is broken at this point. b. The user clicks a link that will actively fire a redirect to the F5 login page. This is desirable behaviour from our point of view, but... In comes the next issue... After a re-login via APM the user is redirected back to the landing-page that initiated the APM_SESSION_STARTED event. Because the webapplication fires all kinds of requests from the client to the server more often than not this process erroneously redirects the user to some page belonging to the rest api or a javascript on the webserver. When redirected to javascript the user sees javascript, when to the rest api it's even more jibberish. There some other issues too but my post is getting too long i guess so i'll leave them for a different post. We thought of several solutions but up until now none of them really seem to work satisfactory: Javascript injection (something like this: https://devcentral.f5.com/questions/ltm-apm-session-expired-detection) to detect APM session timeout and actively redirect the user. This however would not solve incorrect redirect behaviour mentioned in my second statement; in addition Auto redirect on inactivity would eventually also timeout on the APM loginform after which the original landing page is no longer available; Auto logout on serverside; This is a problem however if user is still working in different browser-tab in another application and the application timing out redirects the user to the logon page, which in turn is being detected by the F5, hereby unintentionally killing the APM session altogether and requiring an 'active' user to re-login and potentially losing work; Redirect to a default page (for the second issue); this solution is not acceptable to our client; Sending heartbeats to always keep the session alive; this would however circumvent active security policies and therefore is not acceptable; Using Client Initiated forms based auth and only enable APM for login pages; this seems to work somewhat (inactivity timeout on the serverside provides for the desired behaviour), however, after the first login APM is never being hit again causing an inactivity timeout in no time. The main goal is to provide a seamless SSO-experience for the users. Any thoughts to resolve these issues would really be appreciated. Thanks, Mark
HTML5 Remote Desktop client for APM Webtop?
We're currently running BIG-IP 11.4 Hotfix 3. I'm trying to publish a Remote Desktop via a Webtop (RDP) and it either needs a browser plugin (no good for Internet Explorer 10+) or when I turn on Java it is very fussy with the versions. Has the later versions of BIG-IP included a HTML5 viewer? Updating the F5 environment here is not an easy task so I can't update to find out.
