Unsolved
This post is more than 5 years old
34 Posts
0
25919
Show stopper: VDI that needs to run SSL VPN client...
I have a ticket open on this with support, and I am sure that's the best way to get up to the minute information on this, but I am posting here to see how other users who have this issue have worked around it, if it's possible, and also to make my disappointment clear to the Quest folks who watch these forums.
I have the issue outlined in Quest KB article 68168. Our VDI desktops are not multi-homed in the sense that they have physical NICs, but they do have an SSL VPN client that has its own IP, which is used to connect to one of our client's intranets. This has resulted in all manner of connectivity issues. Users who get disconnected cannot reconnect to their sessions if they are using the VPN client, because the broker is looking to connected the client to an IP it cannot see (the VPN adapter). The broker is also unable to manage the VDI machines. It's a nightmare. I have partners in our firm who are using this solution, and are wondering why I chose it.
Support tells me they've been aware of the problem for a while now, but that there is still no resolution or even a workaround. I'd be the guy with a handful of licenses who probably does not carry much weight, but we will need to go elsewhere if there is no solution to this issue in the very near term.
Frankly, I am a little stunned that you don't take this into account in the world of B2B interaction...
I'd be thrilled if there was at least a way to force the adapter used for vWorkspace with a registry hack or something, at least for now.
Help!!
DELL-Andrew W1
378 Posts
0
February 15th, 2011 17:00
My suggestion did seem a little too easy
I'll let you know if I come up with any other ideas.
DELL-Andrew W1
378 Posts
0
February 15th, 2011 17:00
Hi Steve,
The Broker should get the IP from the first Network Adapter.
By this, I mean the first in the list when you look at the Binding Order.
To test this just now,
In VMware, on a Win7 Linked Clone, I added a 2nd Network Adapter.
This picked up a DHCP address so I could still connect.
I then RDP'd in and changed my new adapter to an IP that I couldn't reach from either my machine or the broker.
At this point, I was kicked off the RDP session.
I reconnected using VIC and swapped the Binding order so my Adapter with the DHCP address was the top of the binding order.
Now, vWorkspace and normal RDP can connect without any issues.
Have you tried making sure your reachable Adapter is always the top of the binding order? I think this might solve the issue for you
Kind Regards, Andrew
sgravel
34 Posts
0
February 15th, 2011 17:00
Hi Andrew,
Just tried your suggestion, but I ended up with different results.
I chose a user who has this issue, and whose entry in the vWorkspace console had the IP of the VPN adapter listed. I looked at the bindings, and sure enough, the VPN adapter was listed first. I clicked the LAN adapter to the top, and within a few seconds, the vWorkspace console was reporting the correct IP.
I had the user disconnect the session and then reconnect to it. All good.
Then, I closed the VPN session and re-established it. This caused the IP reported in the vWorkspace console to be that of the VPN adapter. I opened the list of bindings again, and the LAN adapter was still at the top, with the VPN adapter beneath it. I opened the listing completely from scratch (Control Panel>Network and Sharing Center, etc.), so I am pretty sure I was not looking at a stale binding list.
This is all consistent with what support told me. They stated that they had experimented with binding order, but it did not produce a permanent improvement. Windows remembers and respects the binding order you specify, even if you have adapters that are dynamically added and removed from the system, it would seem. Unfortunately, the WMI query you are doing to get the IP address for the VDI desktop does not appear to get an IP from the first adapter in the binding list, at least every time.
Thanks for the suggestion, though.
sgravel
34 Posts
0
February 15th, 2011 18:00
Just looking at the KB article, and wondering (emphasis added):
The way I read that, WMI returns several IP addresses to the Data Collector's query, i.e. 10.10.1.24, 10.120.149.12, 192.168.1.43. Then, the DC refers to "the first available one". Would it not be better, in almost every case, for the DC to parse the list and choose the one on the same subnet as the broker? If there is a scenario I am not considering, could this not at least be made an option?
It sounds like WMI is returning choices, and DC is essentially choosing one at random. From my experience, being the first IP address on the list does not mean anything. Being an IP address on the same subnet as the broker means everything. If WMI is returning a list, and I can pick out the right one, DC should be able to as well, yes?
markh21
98 Posts
0
February 15th, 2011 18:00
Here is a question just for compeletness...when the users use the SSL VPN...does it allow split tunneling (ie, on a normal desktop you can still access the local resources as well as the remote resources?)
sgravel
34 Posts
0
February 15th, 2011 18:00
Hi Mark,
Yes - split tunneling is allowed.
sgravel
34 Posts
0
February 17th, 2011 12:00
Hi again,
I appreciate the workaround that Andrew suggested, even though it didn't pan out, but I've gotta say - I expected someone to throw out some more information as to the roadmap on this issue. It's been a problem for vWorkspace for a while from what I understand, and with my case as an example, I would think you would run up against this fairly frequently in the business world. To say that "you just can't do that" (as the KB article does) is not an acceptable answer. In the real world, clients and business partners have very specific allowable modes of access for their outside vendors. I've gotta believe that client based SSL VPN is fairly common. I'd love to put a device on our network that can terminate the end of the tunnel somewhere other than on the client, but given our client's policy, that will not be possible. That means that by Quest's definition, the machines are "multi-homed".
If Quest is about to do something about this, and just has not responded, please do, either here or in my support ticket. If not, I have no idea why a problem that potentially has a simple solution has been allowed to linger for so long. There is a lot of information delivered by WMI along with an IP address, just poking around technet. Seems like there would be clues in there as to what the right adapter to choose would be. I am assuming you are looking here:
Win32_NetworkAdapterConfiguration Class
http://msdn.microsoft.com/en-us/library/aa394217(v=vs.85).aspx
Please let me know what I should expect from Quest in the way of assistance with this, and when. If there is nothing that can be done soon, I need to cut my losses with this product and find another solution.
Thanks,
Steve
markh21
98 Posts
0
February 23rd, 2011 23:00
Well..that won’t always work either….you’d need a way to have defined a list of valid IP ranges for the VDI systems for it to compare against.
Most network security designs use separate vlan’s for desktops vs DC’s vs databases,etc
sgravel
34 Posts
0
March 22nd, 2011 13:00
I was told by support that there would be an enhancement forthcoming to address this issue before 4/24/11, but my efforts to contact Quest directly to get an update on this have met with no response. Meanwhile, this continues to be a daily nightmare for our support team and our users. I recognize that 4/24 is still a month away, but trying to be optimistic, they did say "before" 4/24. Even a couple weeks at this point might mean a difference in our course of action regarding vWorkspace.
Quest - can you respond as to the status of this issue?
Thanks
sgravel
34 Posts
0
March 22nd, 2011 13:00
I'll buy that. How about as a second step after retrieving the list of IP addresses from WMI, the Data Collector does a quick check and chooses the IP address from which it can actually connect to the configured broker? If I can "ping -S" from a specific address on my machine, surely the Data Collector could perform some similar function. If not, maybe it could look at the routing table on the client machine and pick a better choice than the first one on the list?
Michel Roth
173 Posts
0
March 22nd, 2011 15:00
Hi Steve,
Since we really can't publicly disclose timelines of when what functionality will become available in vWorkspace, I'll email you directly.
Thanks,
Michel Roth.