Horizon Cloud on Azure Next-Gen doesn't lend itself very well to Azure Best practice Hub and spoke topologies, but there is a design that can make it work. Read more to find out. But first I will explain the problem.
Next-Gen Horizon Cloud on Azure has the concept of Primary Providers and Secondary Providers which can be used to scale the environment into manageable blocks, each essentially with a max number of users because of Azure API limits.
The Primary provider can be configured as dedicated for infrastructure only, i.e. the Edge Gateway AKS Cluster and the UAG's.
This helps somewhat in segregating the internet facing components from the VDI workloads but there is still a VNET peering between the Primary Provider VNET and the secondary provider VNET where the VDI reside, and only NSG controls in between which essentially stateless security filtering.
Organisations will typically deploy an Firewall between the VDI machines and the corporate VNET but this does not offer the highest level of protection and may not conform to Azure Hub and spoke topology.
If we adjust the above layout to a hub and spoke architecture, using UDR's to funnel traffic through managed firewalls we can get the routing to work between the Primary Provider and the secondary provider.
Note that if using an AKS cluster the next hop default route on the management subnet UDR needs to be an NVA such as Azure Firewall or an Azure Virtual Network Gateway.
The challenge here is even with the above setup, certain operations within Horizon Cloud on Azure, such as provisioning, editing or expanding pools, will fail because the code does a peering check to see that the Primary Provider VNET in the DMZ subscription and the Secondary Provider VNET in the LAN subscription are not directly peered.
Well, there is a solution. Peer the networks directly. It might sound counterintuitive, but if you've got your UDR routing set up correctly, you will see all the traffic traversing through the firewall as expected.
This is because UDR's override VNET peering if configured with same or narrower address scopes than the VNET address space.
It might set off alarm bells with the security team but explain and demonstrate that the peering is not being used and you will have a solution to move forward.
Add comment
Comments