Horizon 8.2 / F5 iApp + Connection Server HTML5 Tunnelling

[mrstorey303]

Anyone out there using the Horizon F5 iApp to front multiple connection servers?

Since upgrading from Horizon 7.12 to Horizon 8.2 our F5’s don’t seem to work with selective tunnelling to HTML5 clients anymore, so this naturally throws a cert warning because the URL offered is that of the remote desktop IP rather than the blast external URL (so, basically not tunnelled).

We’re running the v1.5.9 of the Horizon iApp, and we have “Use Blast Secure Gateway for only HTML Access Connections to machine” set on the connection servers. The iApp has ‘No, Blast connections should not go through the BIG-IP system’. But I’ve also tried with ‘Yes - blast should go through BIG-IP + Yes, Blast proxied by UAGs’ which has the same non-tunnelling result.

External HTML5 client connections via a UAG work fine (and associated F5 LTM), Not sure what’s changed since the upgrade re: selective HTML5 tunnelling for load balanced connection servers.

Anyone with similar setups experienced this?

Thanks in advance

[SurajRoy]

As per the release notes of Horizon 8.2:

The forwarding rules for HTTP requests received by Connection Server instances have changed at this release. If you have defined custom frontMapping entries in locked.properties, you should remove them before upgrading. If you wish to disallow administrator connections to certain Connection Server instances, then instead of defining custom frontMapping entries, add this entry to locked.properties:
frontServiceWhitelist = tunnel|ajp:broker|ajp:portal|ajp:misc|moved:*|file:docroot

Also you can use the KB: https://kb.vmware.com/s/article/2088354 

•  

[mrstorey303]

Thanks for your reply - I'm aware of the KB but that config is something I'd like to avoid - using wildcard certificates for desktops and configuring view to access agents via DNS name isn't really palatable - I'd just like to get 8.2 to behave in the same way 7.12 was in terms of connection server html5 tunnelling and F5 LTMs.

I saw the release notes, and admittedly reading 'the forwarding rules for HTTP requests.....have changed..' certainly seems relevant, but the frontServiceWhitelist config just disables the admin console on a connection server, it doesn't seem related to html5 blast tunnelling.

[wing523 · Accepted solution]

Disabling inserting x-forwarded-for HTTP header (if it's ok to do it) on F5 may solve it.

[VMHero4Ever]

Hi mrstorey303

we have exactly the same issue since upgrading from horizon 7.12 to 8.2.
We also using an F5 loadbalancer for our internal connection broker.

I already opened at ticket at VMware but the support guy didn't told me that there was any change regarding the html access.
He told me that “Use Blast Secure Gateway for only HTML Access Connections to machine" is not supported over a loadbalancer.

To be honest we don't have deeper knowledge in F5 loadbalancer. But we followed the official documentation about VMware Horizon loadbalancing. We using 1.5.9 iApp template.

Did you find an solution? 

Thanks and Regards,
VMHero4Ever

[mrstorey303]

Sorry for the delay with this - I retried disabling this on the http client profile (the one the iApp creates), and also setting the client profile to 'none' on the LTM, but I still get the cert warnings.

Trying to follow up with F5 support now - will report back if I find anything useful.

[VMHero4Ever]

Hi,

we tested it on our environment and it works for us!
We only had to switch "insert x-forwarded-for" to disabled (see the screenshot attached). No certificate issue anymore via html access.

But with these change we don't see the correct "ViewClient_Broker_Remote_IP_Address" anymore. 


I don't understand what VMware changed in this release why the html access ist not working as it was before.
I hope the F5 support can find something on your site. 

Look forwar to hear from you.

[mrstorey303]

My bad!  Looks like someone disabled tunnelling on one of the connection servers in the pair in between testing.

Just went back to double check the config and it works!

Thanks to all involved.  Will reach out to F5 to see if they'll consider updating their iApp to reflect these changes - doesn't look like it's been updated in a while.

[mrstorey303]

Reopening this for discussion if possible - while I follow up with F5 re: iApp configuration - anyone know from within VMware why disabling this feature would allow the connection servers to start correctly / selectively tunnelling for html5 again?  And why this is a change in Horizon 8.x ?

Not an expert, but I all I thought x-forwarded-for did was just send the client IP to the web server, for logging / auditing purposes etc.  Why would the connection servers break tunnelling if F5 sent this info?

[VMHero4Ever]

Hi mrstorey303,

I had open a ticket by vmware SR 21229591306 but they weren't aware about any changes in Horizon 8 with HTML access.

I got this answer...

1, When horizon view connection server is in use for direction connection , Horizon view Client to VDI traffic is going through Horizon view server . As per vmware documentation, HTML gateway configuration will be works only when connecting directly to Horizon view connection server. On this scenario, Horizon view server presents certificate to view client.

2. When Traffic is using F5 , Horizon view html client should receive certificate from F5 and not from view VDI desktop.  Horizon view connection servers html gateway will not  be used when connecting to VDI using load balancer. We may need engage F5  support on issue to see , why horizon view client is not receiving certificate from F5 when VDI session using f5

------------------
Why does nobody else run in this issue after upgrading/installing Horizon 8?
I don't think that this is only an F5 loadbalancing issue.

[Go0oSeR]

I actually have this issue in Horizon 7.13.1 using iApp version 1.5.9.  The fix mentioned above also fixes the issue for me.  

[mrstorey303]

Reply from F5 support:

re: x-forwarded-for:

- This is an application requirement and depends on the application itself. The BigIP unit only inserts the client's IP address as a header for the application to be aware of source of connectivity and requests.

re: why would disabling x-forward-for make a difference anyway?

- This is something that VMWare team will have to explain. Browsers identify themselves with "agent data", so application should have no problems identifying them as such.

re: are F5 going to fix / update the iApp

- If there is an issue with new Horizon version that needs to be fixed, VMWare will provide a fix/patch/workaround.

@wing523 - do you have any detail on why disabling x-forwarded-for is actually required for selective tunnelling to work on recent horizon versions?  Appears there is a bit of finger-pointed regarding why the issue occurs, and who's responsibility it is to fix.

Thanks

[mrstorey303]

To further this - we're also finding that having x-forwarded-for enabled on the our F5 also prevents DEM smart policies from being able to detect the gateway location (ie internal / external).

This is preventing policy based cut / paste operations from working, ie we want 'internal' users to have inbound+outbound cut and paste, and disabled for external.

Anyone else seeing this?

[VMHero4Ever]

Hi,

I have to check this in our environment.
But what I could see that the "ViewClient_Broker_Remote_IP_Address" is not our thinclient anymore. It's not always the load balancer IP.
I don't need at the moment a smart DEM policy to check internal/external access.

But everyone who is using VMware vIDM/Workspace should have trouble if they can't decide between internal an external access.

Maybe I will try to contact our VMware TAM. It's funny that VMware will not fix it and blames F5 for fixing the issue.

[VMHero4Ever]

Hi,

we upgraded yesterday our enviroment from Horizon 2103 to 2111. 
Now the Horizon HTML access works via F5 loadbalancer and Connection Server tunneling without certificate issue anymore!

We changed nothing on the Loadbalancer. Thanks VMware for fixing it!