I have a Security server that has two NIC's configured, one DMZ (Outside IP) and one Internal (Internal LAN IP). I can connect to the security server using the client at home (Comcast) but at the office we have a business Comcast line that does not allow me to connect to it. It will sit at the black screen for 20 seconds and then time out the connection. I have also had intermittent luck with ATT as well as Century Link ISP's. I have one primary firewall that is internal and all rules have been configured correctly. I understand it is not necessary to have two NIC's on a security server but that is how our third party consultant set it up originally.
The HTML feature works great, its just connecting from the outside internet to the security server using the view client, it does not work. I have external DNS entries setup for the outside IP address but no internal DNS entries for the internal IP of the security server.
Any ideas as to what could be causing it to work from my home ISP but not our backup ISP, which is just used for testing and has no restrictions.
There are quite a few things that can cause the infamous "black screen". The most common culprits seem to be DNS or firewall issues honestly but the reasons can be pretty varied. I'm going to assume you're on View 5.2 for the moment. The first thing I'd try is switching over to RDP vs PCOIP and see if you can isolate it to PCOIP. Also, here's a KB regarding the black screen issue, it's possible one of these reasons might match up: VMware KB: Black screen when logging into a VMware View virtual desktop using PCoIP
If it does work via RDP, it might not be a bad idea to re-visit your firewall setup and ensure there's nothing blocking anything on your internal ISP line at your company. If you need it, here's the reference for ports: https://pubs.vmware.com/view-52/topic/com.vmware.ICbase/PDF/horizon-view-52-security.pdf
I am running a 5.2 environment and I tested out RDP, it does work through that protocol. I have opened up all ports from the DMZ IP on the security server to go to the connection server as well as the entire subnet that all my VM desktops are running on. I have noticed though that I have two external hostname DNS entires for the same DMZ IP on my security server because it is using one External URL hostname for connecting through the view client and another for when connecting through HTML blast, would that make any difference?
The fact that RDP is working and PCOIP is not working most often (in my experience) points to losing that PCOIP traffic somewhere and since everything works all the way through from your home external network / ISP it seems unlikely that any issues exist at and/or past your Security Server. I would actually expect that if there was anything blocking it, that it would be on your internal business ISP network.
As for the DNS entries, if I'm understanding your setup right then I can't see why it would cause any issues offhand. Still, if you have the option to test using only one entry it wouldn't hurt.
I have nothing on the Comcast ISP in my office besides the gateway they provided me plugged into the cable and I logged into that gateway and there is nothing that would be blocking it. I had the same problems with an ATT network down at convention center in South Florida. Here is another thing I have noticed. If I disable the local LAN adapter on the security server, flush the DNS, and re enable that local LAN adapter, it will work (usually) connecting to it. If I disconnect from the desktop and try to reconnect, it will not work, so it works for the inital connection.
Of all the things I have read about this similar issue, people have said it was either a DNS or routing issue so I have no idea.
Next question would be for the DNS entry, do I delete the blast HTML entry or my original External URL entry?
Hmm, I thought of an idea over my energy drink break (it's like lunch but less filling) 😃 - If you haven't, could you try logging in via Security Server IP instead of DNS on the View Client? If that does work, it's definitely not a permanent solution since the SSL certificate check (even if it is current and valid) will come back invalid. You'll have to make sure you allow the client to connect regardless of cert to test it.
As for which to remove to test I'd drop the blast entry, but I still don't see any reason for that to cause an issue. The flip-side though is that I can't directly see the configs so I may be missing something in my head. Also I haven't played with blast much yet and can't wait to get my hands on it. I checked it out before release about 8 months ago but I'm locked in an environment with no View at the moment. Still, I think blast can be configured to use the same URL just a different port, which is 8443 by default (correct me if I'm wrong on the same URL thing).
Hopefully the IP test works.
Tried but no luck. Matched all entries DNS and still no luck. I already have an open call with engineers and they are not sure what the cause is so I am trying to get extra feedback if there is any idea to the cause of the issue. I am clueless now! I am leaning toward setting up a new security server but I would much rather avoid that if possible.
Too bad on the IP test but that helps narrow down the issue, and I'm glad to hear it's already opened with support (I assume those are the engineers you mentioned). That may be the best route considering, I'm not sure how easy resolving something like this remotely without accessing the system would be.
I am still curious about that business ISP, I've heard of things being blocked via the ISP itself before. Basically it would just surprise me a bit if the issue wasn't external to your environment. Could be an issue with the machine/client you're using to connect from work though but the intermittent part makes everything suspect.
Just to clarify, in all cases where it doesn't work you ARE able to log into the server via the client and it connects you to the desktop, you just then see a black screen right? If there are some situations where it doesn't connect you to the Security Server at all the distinction is important. The fact that you connect correctly after disabling, flushing dns on, and re-enabling the NIC is definitely strange, more so I feel like because the IP test didn't work and that you can connect from a different external network.
I'd focus on the network side of this equation given the evidence on hand, and I've had good experience with VMware support so hopefully they track it down for you. I can't obviously, but if I'm being honest I'd love to come work in that environment and check it out myself.
Connecting through the view client from home works but trying on my outside secondary ISP in the office does not. It did not work with an ATT network at a convention I attended but it does work with CenturyLink. I can't imagine any ISP blocking something like that so I can go ahead and rule that out. Everything that I have managed to read has either leaned toward DNS or routing problems, the only issue is they are not specific as to where they apply these changes.
I have started to create a new security server with just one NIC as a DMZ public IP and may try to start from scratch.
For others who come across this thread that have configured their security server(s) with 2 NICs (not recommended), just this week I was involved in troubleshooting the dreaded PCoIP black screen then disconnect issue for users connecting from the internet. This had been an intermittent issue for a very long time within a VDI at an Army datacenter on the East coast. After a good deal of troubleshooting, the realization was made that both security servers involved had been configured with 2 NICs (one external IP on DMZ and one internal IP) so the servers could be added to the domain and patch management could be handled just like with all of the internal servers. Unfortunately, the route priorities had not been configured on either security server so internal IP had priority over the external IP for the 0.0.0.0 routes. The internal IP was listed first and had a higher priority on both security servers which caused the black screen ~65 - 75% of the time. Of course, the firewall ports/rules were all configured to allow the PCoIP traffic over the external IP. Approximately 1 in 5 attempts the external IP route would be used and the user would not get the black screen. To get rid of the black screen, on both servers the external adapter was given a higher priority interface metric (lower number) than the internal adapter (Adapter settings -> TCP/IP properties -> Advanced -> Interface metric). Using the route command the internal IP route for 0.0.0.0 was also removed from the table. As soon as these changes were made no more black screens. Note: the decision was made by the responsible leadership to leave the servers dual-homed because of the red tape involved with managing a Windows server in a DMZ that is not part of the domain.
Having Security Server with dual NICs is quite common to separate out the external and internal traffic, but as you've seen it is vital that your routes are not misconfigured for the addressing on each. Misrouted IP packets will cause problems for any protocol, but as you've observed, a Black Screen is often how misconfigurations will show themselves for PCoIP.
Thanks for sharing your observations.