Windows View Client - FQDN Issue

[PeterWright2011]

I wondered if anyone else had come across this before?

I have a small test network running Horizon View 5.3.1. I have 1 connection server and 1 security server paired. I have no issues with my security server sitting in my DMZ for use with remote access. The issues start when I try to connect to the connection server when I'm on the internal network. When using the latest version of the Windows View client (running on Windows 8.1 x64) and tryping in the FQDN of the connection server, I simply get an error right away saying 'Couldn't connect to server'. If I use the IP address then it works fine, but obviously is of no use as I can't verify the cert.

I've come accross issues in the past with using DNS shortnames (which also doesn't work) but I'm not concerened as I want to use FQDNs anyway.

I've checked DNS and everything seems fine. If I ping the connection server's FQDN I get a reply, all other servers are accessible via their FQDN and HTML access works fine using the FQDN and my certs check out OK.

This only seems an issue in the Windows View client. If anyone has any ideas I'd be very grateful.

Thanks

Pete

[childebrandt]

If you open up the view admin site and go to view config, then to servers and look at your connection server settings. Is your HTTPS Secure tunnel set correctly.

[PeterWright2011]

Thanks for your reply. I have set them to what I believe to be correct...which is probably the reason it does not work

I have set the connection server https secure tunnel as the hostname of the windows server itself (FQDN with port numbers as in the example). Likewise for the Blast secure gateway.

The security server is set to the public URL I use to connect in from externally. Should the connection server be set this way as well?

I would imagine I've made a noob mistake here somewhere.

[childebrandt · Accepted solution]

This really depends on the set up. But we use the Same URL for both. So ours are set the same.

Example

HTTPS://view.domain.com:port

And we set the same for HTTPS, Blast Gateway for both the connection and security servers.

then when you pull up your client. For the connection server just type in view.domain.com and it should work if you have the DNS entries set on the DNS server on your domain.

[PeterWright2011]

Thanks for your advice. I think I can see where I'm going wrong here. I've added an A record to my public domain name and an alias to point 'view.domainname.com' to the internal connection server so the names should match and resolve internally and externally. I'll then change the settings for both servers accordingly and post how it goes.

Many Thanks

[PeterWright2011]

I'm assuming the IP addresses should be set as the internal IP on the connection server and the public IP on the security server in the settings and therefore be different?

[childebrandt]

Yes they should be that way.

[PeterWright2011]

That's great thanks. I've set it all up accordingly and it seems to be working internally now using the Windows client. I'll give it a try externally tommorow from work.

Last stupid question I promise... I'll need to redo the certs on the security and connection server to view/domainname.com. I'm assuming I can use the same cert for both servers as they're both going to resolve to the same name?

Sorry, as you can probably tell I'm new to configuring View.

[childebrandt]

Yes use the same cert. We use a wildcard cert for them. If you have any more questions shoot me a message.

[PeterWright2011]

Thanks for your patience.

I've changed the settings on the connection and security server so that they all point to https://view.domainname.com. I've setup an internal alias so view.domainname.com points to connectionserver.com. I've also set an A record on my public domain and external access now works fine.

I'm getting further trying to access view internally but am still having issues. Now if I type view.domainname.com into the client, I now get as far as being able to put in my username and password, but it then hangs on 'authenticating' and never reaches the pools. However, this works fine externally.

Another weird issue is that if I turn off my pfSense firewall to stop internet access, it all works fine internally. I'm wondering if it's trying to go out externally somehow when trying to use the connection server internally. One other observation is if the security server is offline, I cannot even get as far as entering my credentials in the view client. I'm not sure if this is normal.

I've checked DNS and the CNAME record 'view' resolves to my connection server correctly. Running a ping on the machine with the view client shows it's resolving internally rather thn going out to the internet first.

Hope this makes sense. I feel I'm at the final hurdle now :-). I also created a wildcard cert and added that to the connection and security server, but that seems to be behaving.

[childebrandt]

External works fine. But yesterday you said internal worked. Or did it only seem to work?

Is it giving a error when you try to enter your credentials?

I guess first thing to check is to make sure your client has no proxy.

The second thing would be to check the HTTPS secure tunnel setting and make sure it has the :443 at the end.

Does it work if you change your connection method to RDP instead of PCOIP?

[PeterWright2011]

It all seems to be working now having shutdown my lab network and laptop yesterday and started it all up again now I'm back from work! Thanks for your help. having matching URLS on the connection and security server settings ultimately has done the trick I think. I think the other strangeness is just my dev laptop.

Thanks again!

Pete