Horizon View "This Page is Not Secure"

Hey Veato,

Based on what im readinn the connection is a LTM connection to your VDI servers for authentication and the IP address that you listed is the ip address of the desktop your client directly connecting to the HTML5 Blast connection.

When using LTM we do not tunnel sessions unless the tunnel boxes are turned on via the connection servers, and even then you would have to configure the F5 to route the PCoIP and Blast traffic through the BigIP via the IAPP or manual configurations.

Another Alternative to deal with this is to use our APM Proxy which allows us to tunnel all of the session activity and doesnt do the direct connection.

The Certificate error is expected behavior when doing direct connections, the rewrite on the URL that happens after the acceptance of the certificate is more for the framework around the HTML5 connection allowing multiple connections.

One thing to note if you do decide to tunnel the traffic through he brokers for the HTML5 (checking the box for the Blast Extreme gateway on the brokers) any reboot of these servers could cause user disconnects, but would remove the certificate error. Also that Blast (HTML5) and Blast Extreme Traffic (Native Client) would be routed through the connection servers.

Hope this helps

Hi Matt,

Thanks for the lengthy answer. I'm still no completely understanding how I can stop the behaviour though. I can confirm I am not using any of the gateway/tunnel options on the connection server(s)- they are all unticked - and when building the iApp I nominated two IPs for clients; one trusted, which I believe uses LTM, and one untrusted, which I believe uses APM.

My understanding is that the ssl certificate that you have used for the VIP configuration for https, is not trusted by the OS on your desktop. It's a common behavior. When we try to access the GUI of the cisco tools, we get similar error. It's not browser specific but OS specific. There's no getting away, unless you get the SSL certificates configured from a renowned Certificate Authority, like Verisign, etc.

My understanding is that the ssl certificate that you have used for the VIP configuration for https, is not trusted by the OS on your desktop. It's a common behavior. When we try to access the GUI of the cisco tools, we get similar error. It's not browser specific but OS specific. There's no getting away, unless you get the SSL certificates configured from a renowned Certificate Authority, like Verisign, etc.

My understanding is that the ssl certificate that you have used for the VIP configuration for https, is not trusted by the OS on your desktop. It's a common behavior. When we try to access the GUI of the cisco tools, we get similar error. It's not browser specific but OS specific. There's no getting away, unless you get the SSL certificates configured from a renowned Certificate Authority, like Verisign, etc.

Thanks again Matt. So from what I can tell the options are:

1. Leave the options unticked and continue with direct connection but get a certificate error.
2. Use the blast secure gateway with my broker - possibly with additional connection servers.
3. Put everyone through APM.

Option one isn't doable as this is a business system and I can't have certificate errors.

Option two is possible.

Option three I'd need to consider as the APM for externals has 2FA which I wouldn't want for internals.

With regards option two can I sanity check this with you?

• Internals - LTM - connection server A with blast gateway in use
• Externals - APM - connection server B with blast gateway unticked

Does that look right?

Hey Veato,

Keep in mind a VIP is a VIP you could always create an APM internally and not have it be 2FA enabled, i.e. you create a second iAPP with APM for Internal use. You would just point DNS as the internal APM instead of the External APM.

With the Options On Options 2 If it were me i would recommend having at minimum 2 Connection servers per VIP Internal vs External. how you stated it is correct i would do LTM connection Servers with the box checked and the External APM servers with the boxes unchecked. The only downside i need to reiterate is that all blast connections wether it be HTML5 or blast extreme would be tunneled through the connection servers in this choice. This means if you need to power off connection servers or reboot them it has a highly likely hood of disconnecting user sessions that use Blast Extreme or HTML5 Blast. However this does get rid of the certificate issue.

I would however recommend instead of using the single iAPP deployment for deploying an internal and external vip i would separate them by using the iAPP twice and creating an LTM app for Internal and an APM app for External (just don't fill in the internal lan vip section on APM iAPP)

Just curious are you using Instant Clones or Linked Clones? a long time ago when i was working for VMware PSO i thought about creating a Powershell type script that would do the following

1) generate a new blast certificate from an internally trusted CA. 2) modify the registry point instead of showing IP would use DNS when using blast HTML5 protocol 3) swap the thumbprints from the self sign to the newly generated cert 4) restart the blast services to accept the new certificate.

I never did follow up on doing this but this would be the approximate way of doing this fix without the tunneling, the thing i would mention was based on the amount of certs created and depending on the type of VDI i would set the expiration of the cert to be a fixed date rather than the long lengthy 1-2 year approach. In this case i would also setup another subordinate CA behind the root to just handle these workloads.

This was just another thought of how one could resolve this issue as well, the key of doing this would be creating a script having it in like c:\tools\script.whatever and having it run as a Post Sync Script on the instant/linked clones. Don't know if this approach would really fit your bill but it is something i thought of a long time ago that could resolve this issue, and i i wouldn't recommend the wildcard approach as its too dangerous b/c the key has to be exportable IIR.

Does that help?

Thanks Matt. I'll look at creating seperate iApps for my internal LTM and external APM users. The start of this excercise was to attempt to tidy my old config up and bring everything under a single iApp (currently I have 3!). Whilst this is now looking unlikely even bringing this down to two (relatively simple) configs is going to be an improvement. I'll sleep on it over the weekend and revist on Monday. Cheers.