dyeltonDC
Contributor
Contributor

Security Server port help...

Jump to solution

I've setup a virtual VMware View Security Server in our environment.  I setup a second vSwitch for DMZ use on the host and gave it a new port group for DMZ use.  The Security Server VM is using the new DMZ port group.  I have that going to a dedicated switch for DMZ and then back to the DMZ port on our firewall.

Our firewall is managed by our ISP (I'm a one man IT department in a large (for one IT person anyway) environment so it helps me cope with other tasks).  After speaking with them on several occasions they assure me that everything is setup appropriately so there must be an issue with my VMware setup that I'm not seeing.

I have an external IP dedicated for the Security Server that I had them route to an internal IP on a dedicated DMZ subnet per the first paragraph.  I had them open UDP and TCP ports 80, 553, and 4172 for the Security Server and also pass those same ports on to our View Connection Server that sits on our private network.  (I changed the default 443 port to 553 as my original thought was that something must be blocking 443 on VMware's side)

I'm with them in that the port rules are straight forward in setting up firewall side so I'm sure there is no issue, especially after speaking with four different techs that all looked at the setup and confirmed it was accurate.

If I do a port scan from the outside, port 4172 show up as being open, but when I scan port 553 it is closed.  This is driving me batty as there doesn't seem to be much to screw-up in terms of setting this up.

I am also curious how to go about requiring the use of RSA devices only for clients connecting throug the Security Server.  If I setup a replica Connection Server, won't the same configuration be used on both servers meaning that I couldn't enable RSA on one without having to have it on the other?

Thanks!

0 Kudos
1 Solution

Accepted Solutions
npeter
Expert
Expert

Hi dyeltonDC,

I guess you made lot of misconfigurations including a ExternalURL.

Please go through this doc and video http://communities.vmware.com/docs/DOC-14974

This article clearly explains how to setup PCoIP Secure Gateway and other components to access desktop using PCoIP protocol from external network.

Have alook at www.vmware.com/pdf/view-46-architecture-planning.pdf page 60 for detailed firewall rules for entire view deployment using DMZ

Everything should work properly once you configure View as per these guidlines.

-Noble

-nObLe

View solution in original post

0 Kudos
8 Replies
marvinms
Enthusiast
Enthusiast

I am in the middle of a Proof of Concept and working with a Security Server as well. I also requested the Network team open 80, 443, and 4172 between the SS and the internal management server. The connection failed until I had they go to Any-Any for the entire PoC vlan (including the desktops, management server and vcenter). We will try to figure out specifically what the additional required ports are.

Currently my Win7 boxes connect but not the XP from my Brighthouse connection...go figure.

Good luck,

0 Kudos
npeter
Expert
Expert

RSA configurations are per conncetion server, which means you can have RSA configured in the connection server which is paired with security server for external users and the other servers without RSA for internal users.

Reagrding security server port i didn't get what probelm you are facing. Are you not able to connect and launch desktop from external network?

-noble

-nObLe
0 Kudos
dyeltonDC
Contributor
Contributor

I realize that RSA is per connection server, but the users need to connect to the same desktop externally as they do internally, so how can we have two connection servers with the same config EXCEPT for one being configured to use RSA and one that isn't (and it still keep additions/changes made to the primary connection server).

This is of course a moot point if I'm unable to get the security server working...no, I'm unable to connect to my view desktop(s) externally.  When doing a port check, 4172 comes back as being open and 80/443 come back as being closed.  I'm of course trying to connect via 443 so if it's closed it obviously isn't going to work.  443 is definitely open to the security server and from there to the connection server on the firewall, so what's the deal?

0 Kudos
npeter
Expert
Expert

>I realize that RSA is per connection server, but the users need to  connect to the same desktop externally as they do internally, so how can  we have two connection servers with the same config EXCEPT for one  being configured to use RSA and one that isn't (and it still keep  additions/changes made to the primary connection server).

When a view setup is created with multiple connection Servers (standard and replicas) every server in that group shares all the information such as  Pools, global settings and policies except for few options such as Authentication options which are seperate to each connection server.

So in your scenario, you can have CS1(standard, with RSA configured), CS2 (Replica). SS1 paired with CS1.

Since they are Standard and Replica, both CS1 and CS2 share the same Desktop Pools. ie, users connecting to either of these can access their Desktops.

Users can access desktop using SS when they are in external network which inturn requires use of RSA.

Users can access same desktop using CS2 when they are in internal network which doesn't require RSA.

Regarding connection issue, Are you checking the ports on external firewall? From what you said it looks like a firewall configuration issue. Are you able to launcg desktop from internal network?

-noble

-nObLe
dyeltonDC
Contributor
Contributor

No, I cannot access from my internal network, but why should I be able to?  I don't have a route in the firewall setup to go from internal connections to the security server.  I did setup a replica server as mentioned.

CS1 (internal use only) is running on a Win2k8 server

RS1 (replica server that's paired with the security server) is running on Win2k3

SS1 is running on Win2k8 R2 of course

I have again obtained confirmation that ports 80, 443, and 4172 are open for both UDP and TCP in both directions (via separate rules even) from SS1 to RS1.  Turning off the Windows firewall makes no difference, which I don't see why it wouldn't because I double checked and the appropriate rules were installed correctly during the install of the SS.

It can't be this difficult to get this up and running.  I'm about ready to just direct external traffic to the RS1 server and use the Windows firewall to manage the security to/from our internal network.

0 Kudos
dyeltonDC
Contributor
Contributor

Alright, I had the firewall guys open up all traffic between our SS server and our internal network that the RS1 sits on.

Interestingly I am able to connect via the SS on port 80 when SSL is turned off on RS1, but it gets stuck "establishing secure connection" when trying to connect via SSL.  This re-iterates that port 443 is blocked somehow, even though a firewall rule of ANY is setup between our internal network and the SS (DMZ).  Keep in mind that while I can connect to the SS on port 80 internally, I am still unable to do so externally, even though port 80 shows as being open externally on the SS.

This is thoroughly confusing me.

0 Kudos
npeter
Expert
Expert

Hi dyeltonDC,

I guess you made lot of misconfigurations including a ExternalURL.

Please go through this doc and video http://communities.vmware.com/docs/DOC-14974

This article clearly explains how to setup PCoIP Secure Gateway and other components to access desktop using PCoIP protocol from external network.

Have alook at www.vmware.com/pdf/view-46-architecture-planning.pdf page 60 for detailed firewall rules for entire view deployment using DMZ

Everything should work properly once you configure View as per these guidlines.

-Noble

-nObLe
0 Kudos
dyeltonDC
Contributor
Contributor

Thanks for the assistance.  I got it working, but it wasn't because I had it configured incorrectly, it was because the firewall guys had a miscommunication with me and failed to have TCP open for port 443.  I had them quadrupal check this, but in the end it really was the firewall which is frustrating considering how much time was wasted thinking it was on my end of things.

Again, I appreciate your assistance here.

0 Kudos