Connection Server Configuration

When external clients connect to View via the Security server, they must be able to resolve the FQDN of the Connection server.  This can present a problem because the FQDN of our Connection server is different on our inside network than what is advertised on the Internet.

For example, in our configuration thus far, our DMZ Security server has a FQDN of vdi-security-01.tcpdump.com and our internal Connection server has a FQDN of vdm-01.tcpdump.com.  However, in our external DNS, we advertise view.tcpdump.com with a NAT from the external IP address of view.tcpdump.com to vdi-security-01.tcpdump.com.  Additionally, we have no NAT in place for our Connection server as we want the Security server to act as a proxy for all external users.

We overcome this obstacle by configuring the Connection server with an external FQDN that matches the external FQDN of our Security server (https://view.tcpdump.com).

Using your web-browser, access your View Administrator Console (this is the IP address or hostname of your Connection server followed by '/admin'.  For example:

http://vdm-01.tcpdump.com/admin.

You may also access the administration console via the following URL from the console of your View Connection server:

http://localhost/admin

Log in with a domain user that has administrative privileges to the View Connection server.  By default, the domain administrator account will have the necessary privileges (unless previously configured otherwise).

After you have logged-in, click the "Configuration" icon from the navigation panel:

In the View Servers window, highlight your Connection server and click "Edit".  This will provide a configuration window that will allow you to enter the external FQDN of your Security server.

* Note: You must provide the full URL and protocol in the External URL field.  i.e. https://view.tcpdump.com:443

Click Ok to save your changes.

We must now restart the View Connection service for the changes to take affect.

Comments

Add New Search

Brian |13/07/2009 21:58:55 Great guide! Is there an alternative way to let RDP connections from the security server to an RDP broker server instead of virual PCs? Reply | Quote

thirt |15/07/2009 17:55:01 Hi Brian, I’m not exactly sure what you question is. Are you asking if you can use the security server to manage RDP connection to non VMware servers/workstations? Similar to Microsoft’s Small Business Servers Remote Web Workplace? If so, you cannot. However, you could use the security server to broker connections to a Terminal Services Desktop Pool. Let me know what you are trying to do and perhaps I can suggest a solution. Best, Tom Reply | Quote

Martin Zardecki  - Version differences? |20/08/2009 17:06:30 Hi, nice article. We implemented this as a trial using VMware View products version 3.1.1. Inside our firewall everything works nicely but we can't get it going outside our firewall. We've forwarded ports 80 and 443 to the View Connection server and there no longer appears to be a View Security server product (explicitly at least). When using View Client we can connect to the View Connection server and authenticate properly but whenever we try connecting to an actual desktop the process times out. We have a small office and are only using Active Directory, ESXi, and are now trying View. We do not have vCenter or any of those products nor could we afford them anyways. Any advice or tips? TIA. Martin mpzarde@truecool.com Reply | Quote

Martin Zardecki |20/08/2009 17:11:07 Shoot, I just found the security server deployment step, sorry. I guess is a security server required for Internet Access? Reply | Quote

thirt  - re: |21/08/2009 12:10:06 Hi Martin, I'm not sure I understand your question: Martin Zardecki wrote: I guess is a security server required for Internet Access? You don't have to have Internet access to use the security server. You might use a security server on the WAN/LAN to broker connections for your internal clients as well. The security server just adds another layer of security between your clients and the VI infrastructure/domain. Hope this answers your question! Best, Tom Reply | Quote

Martin Zardecki |21/08/2009 16:32:19 We're a small company and many of our people are on the road a lot. So the key advantage to us is if we can provided with some kind of desktop access remotely. So far we've been unable to provide access through View Connection Server to any desktops from outside our firewall (from the internet). So then is the Security server required to get access from the Internet? TIA. Reply | Quote

Anonymous |21/08/2009 17:13:12 I think I just answered my own question, I finished setting up as per your scenario and still no joy I can connect (using View Client to the View Server OR the Security Server) and control a desktop fine but only from inside our firewall. No joy from outside our firewall; I can connect and authenticate to Security Server or the View Server but then it times out trying to connect to a desktop. I have ports 80 and 443 forward to the Security Server but not sure what else to try on the Firewall. Any tips? Thanks. Reply | Quote

thirt  - Moved to the forums! |24/08/2009 11:37:28 Hi Martin, Lets use the forums to discuss this one further. I started a thread for us here: http://www.tcpdump.com/forums/virtualization/virtual-desktop/cant-connect-to-view-security-server-from-outside-firewall.html?p=1#p4 Thanks, Tom Reply | Quote

redmount |22/10/2009 13:06:32 Hi I am having similar issues did you manage to resolve this for Martin ? if so are there any details published or could you provide info ? If required I can provide a summary of the exact problem I am having. regards Redmount Reply | Quote

Scott  - Sr Systems Engineer |11/11/2009 13:27:32 We are looking at deploying View, but we are a Verisign shop (no direct VMware View integration). Can we use our existing F5/Verisign two factor authentication environment to bring our users inside our firewall, and then fro there connect directly to VMware View as an authenticated user? This would negate the need for Security servers right? One challenge we may have is the need to use a virtually "stateless" think client type device in the field. Something along the lines of HP Thin OS that runs a very limited Linux based OS. I am not sure if we can confiigure such a client to connect up via our F5/Verisgn environment and then connect to our View servers. Most of these devices are pre-configured to connect directly to a small number of VDO brokers only. Reply | Quote

thirt |12/11/2009 09:48:21 Hi Scott, I'm not familiar with the F5/Verisign environment you are using, but assuming this is a VPN of some sort, I don't see why you couldn't leverage it and by pass the use of the Security server. Remember the purpose of the Security Server is to handle remote access (WAN/Internet) into the environment. But if your users connect to your network via some sort of VPN, there would be no reason after they have authenticated and connected to your network that they wouldn't be able to then use the internal address of the View connection server. After your authenticated, so long as you can launch an application or web browser from the clients desktop that can connect to an internal address on your network (and of course the client system meets all the requirements for View) you should be just fine. -Tom Reply | Quote

visak  - virtual support eng |05/02/2010 04:37:50 I am using view 3.11 server with the security server,work fine at the movement I have requirment that I have two diffrent user login groups to same virtual desktop from extrenal connection ,But now I need to block one of the user group to login from extrenally but need to allow that group login internally.Can we achive this setup. Any advice will helpfull Reply | Quote

dgbf |28/11/2011 21:25:33 ngfxngn Reply | Quote

Write comment
Name:
Email:	do not notifynotify
Website:
Title:
UBBCode:	-color-aquablackbluefuchsiagraygreenlimemaroonnavyolivepurpleredsilvertealwhiteyellow -size-tinysmallmediumlargehuge
	Please input the anti-spam code that you can read in the image.

!joomlacomment 4.0 Copyright (C) 2009 Compojoom.com . All rights reserved."