I recently spent a very long time troubleshooting a View security server, documented in this post. As part of my sanity checking, I checked and rechecked all of the necessary settings for a security server paired up with a connection server. I didn’t find any helpfile or blog post that clearly spelled out what I needed to have configured, so I’m putting up a quick post.
This is the View connection broker that’s paired with the security server. The external URL and the PCoIP external URL are the private IPs of the connection broker itself. The security server in the DMZ must have access to these IPs. I won’t rewrite the firewall rules required, but check out KB1027217 for a detailed list of ports. The IP here is the IP that the security server sees for the connection broker. If you’re doing some kind of NAT from your DMZ to the inside, you’re going to have to key in the IP address on the DMZ side of the NAT.
This is the paired security server. Here we use public IP addresses. This IP must be NATed externally to the private IP of your security server… unless of course you use public IP addressing inside your DMZ (yikes).
It’s not easy to test your changes externally. You could work remotely with multiple computers, one on the VPN to make your configuration changes and another testing connectivity from the public internet. That’s not always a feasible option for a consultant. You will typically not have a good way to test externally while inside the client’s network. I do a lot of work in education and many schools are built like bunkers – no cellular signal at all, so a MiFi or tethering is out as well. One easy way to test communication from the DMZ to the inside is to put a temporary VM in your DMZ segment. Give it an IP in the same subnet as your security server, and install the View client. In View, configure the security server to use the private DMZ IP instead of the public IP for the external URL and the PCoIP external URL. You can then test from your temporary VM. Once you get it working, change the external URL and the PCoIP external URL back to the public IP. Then you can get the external NAT and external firewall rules working – this is not a complex configuration and won’t require much trial and error.
Bob Eadie
Thanks for this helpful post Patrick. I was confused by the Secure Gateway “EXTERNAL” IP address, as the example by VMWare, and shown in the screen shot in your post, is 10.0.0.1:4172 (and since 10.0.0.1 cannot be an ‘external’ IP, I assumed they meant the internal IP . . .
Do you think this works for users trying to use Security gateway internally as well as externally (through our firewall which I have set up, but not yet tested!).
Bob
pkremer
I found the VMware screenshots confusing as well.
The “External URL” fields on the connection broker need to be IP addresses that are visible to whatever device is making the connection. It’s not recommended security practice, but you could NAT your connection brokers directly to the internet. In that case, the connection broker External URL IP addreses would be public. But if you follow recommended security practice with a security server, the External URL on the connection broker needs to be the IP address that the security server can use to reach the connection broker.
For the security server in your public DMZ, the IP addresses in there have to be public. I don’t see how it could work any other way. But it’s possible in some environments to have internal DMZs. So you could have internal View infrastructure hidden behind an internal zone, and your Security servers in an internal DMZ. This protects the View infrastructure from any internal attack and forces an internal attacker to try breaching the Security servers. In this case, the External URLs would have *private* IP addresses because that’s how internal clients would be accessing the infrastructure.