Security and Connection Server Config for PCoIP

[esnmb]

I'm kind of confused.  In the View admin console I have my two security servers, one for DMZ and one for internal.  I also have one internal connection server.

If I edit any of them they all have places for external URL and PCoIP external URL.  Should all my connection/security servers have the same thing?

[mittim12]

You shouldn't need a security server for the internal connections.    The external URL is used when clients that connect through a tunnel from outside of the network.   I don't use them at all on my internal connection brokers and only have it filled out on the security server.

Page 21 of the admin guide has more information on it.

http://www.vmware.com/support/pubs/view_pubs.html

[Camek]

I agree that you don't need an internal security server on your internal network.  However, in our system we have a public wireless for which we need to provide access to View clients and this wireless is limited on what it can see on the inside network.  So in this case I have second security server which is running on the public wireless network with holes to allow it to look inside.   The trick to make this work is on the secuirty server you can have the DNS name for the HTTPS side but PCOIP "REQUIRES" and IP address.  So in the PCOIP you need to provide the IP the client will connect on.... On the internet side it's the outside IP address, on our public wireless its a differnet IP address visable to clients so I end up having to have two secuirty servers to make this work well...

[markbenson]

The two external URLs ("External URL" and "PCoIP URL") on each server are used by clients who connect to that server (Security Server or Connection Server) when the appropriate Connection Server is configured for "Use secure tunnel connection to desktop" and "Use PCoIP Secure Gateway for PCoIP connections to desktop".

If in your environment users always connect to one or other of the Security Servers and users don't connect directly to Connection Servers, then there is no need to also set those External URLs on the Connection Servers. Just set them on each Security Server.

This is described in step 2 of the 3 step process. http://communities.vmware.com/docs/DOC-14974

Mark.

[esnmb]

Thanks everyone.  It's just strange why I still can't connect then via the internet. We have all ports required open to our DMZ security server, then from our View desktops to the DMZ security server as well. 

I am able to login select my desktop externally but the screen is just black, then says it times out....  I can access it with RDP selected.

We must be missing something.

[esnmb]

Again, on my connection server on my internal network, I have it's own fqdn and ip for the "External URL" and PCoIP External URL fields.  Clients don't actually ever hit that URL though.  They hit the URL provided by my internal security server no?  My internal security server has the correct URL used by clients while internal...

[esnmb]

Here is a crude Visio image of how I have everything configured.

[esnmb]

Another question, the DMZ security servers PCoIP address, should it be the actual external public ip or the servers dmz address?

[esnmb]

BTW, I got rid of the second internal security server since it wasn't doing anything...

[markbenson]

>>the DMZ security servers PCoIP address, should it be the actual external public ip or the servers dmz address?

Well yes - it has to be the actual external public ip address. The PCoIP External URL is used by the client out on the Internet so if it were set to the Security Server's internal IP address in the DMZ that wouldn't be able to connect. You'd get a black screen.

This is what step 2 says - http://communities.vmware.com/docs/DOC-14974 The worked example in the video (starting about 18 mins in) goes through all this.

Mark.

[Camek]

The PCoIP address must the actual external public IP that is open to outside NOT the interal IP that it is NATed to...

[esnmb]

Ahhh, ok.  I am watching the video you created about the new version and you were saying you can have a connection server for external access and another for internal.  It doesn't have to be that way correct?

[markbenson · Accepted solution]

Everything I say in the video is for a reason 🙂

[JayArr]

You can - but it would be a bad idea. The point of the connection server is to integrate with all of your internal systems like AD, vCenter, etc - it's also a domain member.

Your security server sits in the wasteland that is your DMZ. Not a member of the domain, just a simple locked down workgroup member. It runs the security server and links with an internal connection server. If it is compromised, you're not out any data - fix your security leak, pave it, and reinstall the security server.

On a side note, and more specific to our planned deployment of many external users, I purchased a new physical server for our security server that has a pair of Intel 5600 series processor because they offer AES-IN to offload AES encryption on the CPU. 12x faster PCoIP encryption. Well worth the money in benchmark results of on-the-fly AES encryption/decryption.

[esnmb]

So by changing the ip to the actual internet address and not the NAT'd DMZ address, it worked!! 

Mark,

In regards my other RSA question: So for my internal stuff I can setup a secondary connection server using the same URL as my internet facing security server but just not set it up or RSA...?

[markbenson]

I'm glad you've got it working. When those 3 setup steps are done properly, it works! 🙂

It is quite confusing and definately requires planning and a good understanding. There's been about 10 threads on this PCoIP connectivity poblem and one by one those people fixed it with one of the 3 steps. In your case it was step 2 that was wrong but some have been step 1 and step 3 as well. They're all needed.

In terms of your RSA question, yes, add another Connection Server CS2. Don't configure it for SecurID. Set your internal DNS so that the URL resolves to the IP of CS2. Also PCoIP should be direct (which is the default anyway). This same URL on the external Internet should resolve to the external IP of your Security Server. I assume you've done this part already in your working environment.

Mark.

[esnmb]

Step 2 we thought we had correctly since we figure the security server doesn't really know about that external internet facing ip address, but rather its own dmz address.

My network manager is still a little perplexed as to how/why it works since it doesn't seem to logical....

Thanks again though for all your assistance!

[markbenson]

It's because those External URLs you've configured for your Security Server are given to the View Client so that it can connect to the Security Server. That's what they're for.

If your network manager is still perplexed, you can always suggest watching the video. You don't need to watch it all (unless you have a spare 40 mins!)You can skip to about 18 mins in for a complete worked example which explains in greater detail.

I'm glad you have it working. There are two other threads that are slightly behind you, but I hope this community can help them out in the same way.

Thanks for letting us know what it was that fixed it for you. It'll help the others too.

Mark.

[esnmb]

Oh it's for the clients.  I gotcha. Of course I stopped the video at 10 min for lunch, but I did change the external ip setting and my network manager tested it again with success.

Now for my non-RSA connection server build.