VMware Horizon Community
MAPABVBA
Contributor
Contributor
Jump to solution

View Manager with Security Server in LAN

Hello,

I have some trouble with Security Server. Like other people have only black screen and after some time, I get the error message: "the connection to the remote computer has ended". But our company doesn't have DMZ. And I think it's possible to set up the Security Server in a LAN? If so, I can't get managed that...

In attachment you see our netwerk situation. Everything behind the firewall, the ipadresses has 192.168.1.x . In every installation guide or tutorial they always show the guide or tutorial for network with DMZ.

I'm really confused about this setup. Does the Security Server really need other IP-address even if the Security Server is setted up in LAN? If not, I don't get it why it won't work. Portforwarding is really good setted.

If you know something, I'll answer those question, but I really need help.

Thank you very much.

0 Kudos
30 Replies
DKatman
Enthusiast
Enthusiast
Jump to solution

I think this makes sense now.

You may not need the port open for PCOIP. I beleive from what you said you did do that. But you don't have a static translation for that external IP addresses (as evidenced by you saying you are using 443 for your exchange server). If you then explicitly port forward 4172 also to the Security Server, that may do the trick. I think everyone else dedicates an external IP to the security server, so we are port forwarding each port. Any port where you see us talking aobut allowing through the firewall should also need to be port forwarded by you to your security server.


Dave

0 Kudos
MAPABVBA
Contributor
Contributor
Jump to solution

I tried with 443 portforwarding to security server, and it doesn't resolve our problem. I did make a change in Connection Manager with the right ports.

But yet, doesn't work...

I really need some help...

0 Kudos
MAPABVBA
Contributor
Contributor
Jump to solution

I'm gonna fill all the setup in with all my information. Hopefully you can see if I've setupped wrong.


View Connection Manager:

View Connection Server:

HTTP(S) Secure Tunnel: https://URL-to-our-WAN-IP:4443

Checked "V" on in "Use Secure Tunnel connection to desktop

PCoIP Secure Gateway: internal-ip-address-to-View-Connection-Server:4172

Checked "V" on in "Use PCoIP Secure Gateway for PCoIP connection to desktop

Security Server:

HTTP(S) Secure Tunnel: https://URL-to-our-WAN-IP:4443

PCoIP External URL: internal-ip-address-to-View-Security-Server:4172

Portforwarding:

4443 TCP (mapped in firewall to 443) goes to View Security Server

4172 TCP goes to View Security Server

4172 UDP goes to View Security Server

4001 TCP goes to View Connection Server

8009 TCP goes to View Connection Server

Everything from inside to outside is allowed but except the SMTP-port.

Internal works like a charm via PCoIP, not on external. We don't have any DMZ.

If you need to know more or something, just ask and I'll try to answer.

Now it's really urgent, because my boss isn't happy anymore because this takes a bit too long. So, I really hope you all can help me.

Thank you very much.

0 Kudos
markbenson
VMware Employee
VMware Employee
Jump to solution

There may be other things wrong as well in your setup, but are you saying you still haven't done step 2 in the 3 step setup described here http://communities.vmware.com/docs/DOC-14974

Step 2 says "On every attached Security Server, set up the “External URL” and the new "PCoIP External URL". These URLs are used by the View Clients to connect to the particular View server. These names and addresses must be resolvable and usable by the clients."

If I'm understanding you correctly you're saying you have left the Security Server "PCoIP External URL" set to the internal IP of the Security Server not the external IP (you say PCoIP External URL: internal-ip-address-to-View-Security-Server:4172). Is that what you mean?

If you set this View Security Server "PCoIP External URL"" to the internal IP address of the Security Server then when the View Client uses it to make the PCoIP connection to the Security Server you'll just get a black screen. This must be usable by the client.

Go through the 3 steps again and also, for a more detailed description look at the linked video. Also look at some other threads on this community to see how others have resolved the black screen issue by following the 3 setup steps.

I'm also not sure why you are port forwarding 4001 and 8009.

Mark.

0 Kudos
MAPABVBA
Contributor
Contributor
Jump to solution

Yeah, I have left the Security Server "PCoIP External URL" set to the internal IP of the Security Server.

I'm gonna switch to external IP, that means I have to use the WAN-IP?

0 Kudos
MAPABVBA
Contributor
Contributor
Jump to solution

Setting the PCoIP External URL to WAN-IP was the resolution!

Thank you very much!! I think I was confused because of other situation (DMZ), and that's why I was wrong I think.

But anyway, you saved me! Thank you very much!!!

0 Kudos
markbenson
VMware Employee
VMware Employee
Jump to solution

You'd get the symptoms you had if any of the 3 steps were missed. In your case it was step 2.

I appreciate that it is quite confusing. There have been about 8 threads on this forum that reported this symptom when doing remote access (either the black screen from a Windows View Client, or "Your desktop is loading too slowly ..." followed by disconnect from View iPad) and the resolution in all cases was either step 1, step 2 or step 3.

Anyway, I'm glad yours is resolved too now, and thanks for letting us know which step it was in your case.

Mark.

0 Kudos
edawg
Enthusiast
Enthusiast
Jump to solution

Not to sound like a broken record but I have the same black screen issue and haven't fixed it yet.  I have all the settings you talk about configured on the connection and security server but my network team is confused over the firewall rule on our inside firewall, the one that says allow tcp and udp 4172 to the desktop client.  The reason they are not sure how to setup the rule is that our DMZ is a 172.x.x.x range and our internal clients are 10.x.x.x so when our security server checks in with our connection broker it is giving the security server a 10.x.x.x for the client IP.  When the security server sends this request to the internal firewall to try and broker the PCoIP connection between the view client and the view desktop the firewall is dropping the request because it doesn't understand how to handle a 10x.x.x. ip inside the dmz.  It can only talk 172.x.x.x.  Our firewall is a cisco asa.  I don't know how to tell them what rule they need to setup and they don't know what to put.  Does anyone have an example of the type of rule you would actually write to allow the 4172 tcp and udp beween the 172.x.x.x dmz and 10.x.x.x  internal clients????

I will buy anyone a dinner if they can help me with this final piece as I am starting to go crazy with it....

Regards,

Erik

0 Kudos
DKatman
Enthusiast
Enthusiast
Jump to solution

If the networks are established in the ASA, it can route it. You are finding the permissions are actually blocking it. It is properly set that the LAN 10.X.X.X is more secure than the DMZ 172.X.X.X.

I actually like to play with the GUI the ASA offers.

My line you speak about is basically:

access-list dmz_access_in extended permit object-group TCPUDP host ViewSec object-group DM_INLINE_NETWORK_16 eq 4172

Where Viewsec is previously translated to the IP address of my security server, such as 172.0.1.23 255.255.255.255.

My DM_Inline_network_16 translates to the IP of my View Connection server, such as 10.1.0.34 255.255.255.255 and my network for VDI, such as 10.1.5.0 255.255.255.0

But that is only talking about the security server getting to the desktop.

Good Luck,
Dave

0 Kudos
edawg
Enthusiast
Enthusiast
Jump to solution

Thank you. Very helpful info.  My network team is working on a fix, which leaves me hopeful I will be up very soon.

I owe you dinner....Smiley Happy

0 Kudos
DKatman
Enthusiast
Enthusiast
Jump to solution

Well, I think this gives you what you need at this point. We will see if this is just far enough for them to realize they need to also have a line on the inside interface to allow 4172 to the security server. I believe I also have a setting allowing the Virtual desktop IP range to send out UDP 4172 to any.

Dave

0 Kudos