kmcdole
Contributor
Contributor

problems with View and IP load-balancer

We're attempting to use an F5 BigIP load-balancer with View and having some problems. Does anyone have any insight or resources that might be of help?

We found a configuration doc from F5 We've configured the load-balancer according to this doc. This is for VDI version 2.x but assuming the requirements are similar.

If we connect to the URL of the load-balancer we consistently get the login page and can authenticate with no problem. However the next page fails to load and says server not found. If we refresh then we get a list of workstations that the account is entitled to. However the page lists the connection status as "not connected" and we can't connected to a virtual desktop. We get an error that the View server is not ready.

Here is what is very odd... If we login to the page the first time we can authenticate but the next page fails to load. If we hit refresh on the browser the View client will download and install. The connection will then work for this first time. But after logging out the subsequent visits fail to work. And If we remove the View Client and reinstall it works for the first visit but fails the next.

In the View Admin console we've disabled SSL connections (the load-balancer will handle SSL). We've also worked with several configuration settings for the View server connection. We've set the 'External URL' to refer to the load-balancer's URL. And also checked or un-checked 'Direct connection to desktop' but no difference.

If we connect directly to the load-balanced name using the View client, we connect with no problems.

If we connect directly to the name/IP of the View Connection server we can connect with no problems (this connection is straight http because SSL is disabled).

Only connecting to the load-balanced https URL gives us a problem.

I think it is a problem with creating the SSL tunneling. My assumption is the initial authentication is through port 443 but once we are on the View server or attempt to RDP to a workstation, then that port needs to be tunneled. But I thought if I enable the 'connect direct to host' and no 'redirect URL' the tunneling wasn't used.

We thought persistence might be a problem. We've reconfigured the load-balancer so only have one server in the pool and disabled persistence but still have the same problem.

What is very bizarre is that the connection works for the first visit and with the client. So don't believe it is a port being blocked. This also makes it a grey area because not sure if it is a VMWare problem or load-balancer.

Thanks for any ideas or suggestions...

0 Kudos
5 Replies
hwhitfield
Contributor
Contributor

Did you set the "External URL" for each Connection Server? We saw the same thing. After setting this, the problem went away.

0 Kudos
markbenson
VMware Employee
VMware Employee

Hi,

The first connection should be to the load balanced URL. This is for authentication and managing the interface for getting the list of desktop pools etc.

The View client then makes a second connection for the secure tunnel. This should either go direct to the appropriate Connection Server (or Security Server) or go to a different VIP on the load balancer so that it is guaranteed to go the appropriate Connection Server. This second tunnel connection is by default made to the FQDN of the Connection Server. In the situation where this is accessed from an external network such as the Internet it is usual to set up an "External URL" so that the name will resolve on the Internet to an IP that will get to that Connection Server. The important thing is that the secure tunnel connection must not be load balanced. It would fail if it went to the wrong Connection Server. The client must be able to use the external URL value to get the tunnel connection to the right Connection Server.

The symptoms you describe suggest that the tunnel connection from client to Connection Server (or Security Server) is failing and so it is likely to be caused by this.

Mark.

0 Kudos
TristanT
Contributor
Contributor

Mark,

We had the same problem with our F5 load balancer configuration and our security server. Turns out there is a setting for the F5 server entry that does not work well with View. Here is what we learned after working with VMware (Cale Fogel, awesome engineer!) and F5 tech support: "VIP on F5 for Security Server Failover Group must be set up as a Performance L4 Server NOT a Standard L4 Server!"

Talk to your networking group and see if you can try that setting change if it applies. Hope it helps!

0 Kudos
markbenson
VMware Employee
VMware Employee

Most problems associated with the symptom are either cause because "External URL" hasn't been set up properly or there is some network reason why the client can not use that "External URL" setting to connect to the specific Connection Server or Security Server. Fixing one of those usually solves this issue.

Mark.

0 Kudos
royboy1999
Contributor
Contributor

We had the same issue displaying "not connected" after login was successful. F5 support helped me identify the issue was the redirect not working correctly with the webclient.

Fix:

<![endif]><![if gte mso 9]>

<!--

/* Font Definitions */

@font-face

{font-family:Calibri;

panose-1:2 15 5 2 2 2 4 3 2 4;

mso-font-charset:0;

mso-generic-font-family:swiss;

mso-font-pitch:variable;

mso-font-signature:-520092929 1073786111 9 0 415 0;}

/* Style Definitions */

p.MsoNormal, li.MsoNormal, div.MsoNormal

{mso-style-unhide:no;

mso-style-qformat:yes;

mso-style-parent:"";

margin:0in;

margin-bottom:.0001pt;

mso-pagination:widow-orphan;

font-size:12.0pt;

font-family:"Times New Roman","serif";

mso-fareast-font-family:Calibri;

mso-fareast-theme-font:minor-latin;}

.MsoChpDefault

{mso-style-type:export-only;

mso-default-props:yes;

font-size:10.0pt;

mso-ansi-font-size:10.0pt;

mso-bidi-font-size:10.0pt;}

@page WordSection1

div.WordSection1

-->

The Redirect Rewrite Must be set to All on the http profile for it to work correctly with the web client. This also corrected an issue I was having with it redirecting me away from the admin page when I was trying to administer view-( ie. http://portal.com/admin)

0 Kudos