Citrix Virtual Apps and Desktops deployments typically focus on Citrix technologies and the underlying feature sets. However, when completing a public cloud design or deployment, network architecture plays a significant role in your success. This post is the second in a series on Citrix Consulting lessons learned from the field and outlines a handful of Azure network design considerations. Make sure you check out our first post on scaling Citrix Gateway for business continuity from my colleague Nicholas Czabaranek.
Traffic Security Options
One key item to consider when designing the traffic flow is securing and inspecting the traffic from the client network(s) to the cloud provider and within the cloud deployment. A few key options are available for securing traffic within an Azure subscription, including leveraging the built-in Azure Network Security Groups (NSGs) and deploying an Azure/third-party firewall solution.
- Azure NSGs: Network Security Groups allow for a simple deployment (straightforward configuration of inbound/outbound traffic requirements) and are a built-in Azure service with no added cost. This service does not have the robust logging and actions that a third-party firewall appliance provides.
- Firewall: The firewall solution generally provides a greater feature set and more granular scalability options. However, there’s an added cost of licensing (both for Azure or third-party firewalls) and design/deployment requirements for firewall appliances. The use case for firewalls is well known, and any design should extend network protection to your Azure subscriptions. At a minimum, firewalls are typically leveraged to secure traffic between on-prem networks and Azure VNets, even if an ExpressRoute is in place.
Please note, these options are not mutually exclusive and complement each other.
Firewall Design
Our field experience has shown that pushing large quantities of traffic through a firewall appliance, especially virtual appliances (think ADC VPXs), can cause performance degradation. An example case involves a customer who deployed a hub-and-spoke model, with the firewall serving as a hub and all other components (including Active Directory) segmented into different spokes. The firewall appliances experienced a performance bottleneck, which was resolved by moving components that frequently communicated into the same VNets, and then leveraging NSGs to secure communication between these components. VNet-to-VNet traffic still passed through firewall appliances to align with security standards. However the overhead was drastically reduced.
VNet peering is another key tool that may be used to bridge networks that must communicate regularly without having to traverse a network appliance (e.g. VDAs and backend applications). Here are some tips to help you avoid design flaws that may affect environment performance.
- Be aware of firewall scaling technology and the process to scale, if needed. Architecture decisions that may be design risks include single points of failure during steady state (including a single active node), undefined/untested scaling process, and undersized appliances or appliance resources. Leverage reference architectures if available, such as the Palo Alto on Azure guide.
- Consider deploying separate appliances for North/South traffic versus East/West traffic to limit the total traffic that must traverse a single firewall deployment.
NSG Design
If you are unsure about the port requirements to or from a certain virtual machine or subnet, first configure an “Allow All” rule as the highest priority rule to avoid an impact on functionality. From here, configure flow logging to capture the inbound and outbound traffic during normal operations, and use this data to lock down the NSG. Unless a specific VM needs to be restricted, applying NSGs to subnets instead of individual NICs typically makes sense to limit work effort and the potential for misconfiguration.
Additional Performance Considerations
Some additional network design aspects include:
- Data: Determine where user and application data are located. Consider migrating on-prem data to the same location as the VMs (consistent with an on-premises deployment) to improve user experience and reduce the consumption of costly ExpressRoute throughput.
- Accelerated Networking: Accelerated Networking enables VMs to communicate more directly and efficiently by removing the physical host from the data path. This optimization is available free of charge and reduces latency, jitter, and CPU utilization. This feature is available for Windows Server and Linux VMs only and must be enabled on VM creation.
- Enlightened Data Transport (EDT): To configure EDT through a Citrix Gateway, note that you may need to reduce the default ICA MTU size to align with the Azure limit of 1,400. Additionally, customers often do not allow UDP 443 traffic externally, which you can address by mapping UDP 443 to another port on firewall appliances.
- Microsoft Documentation: The content in this post may be used as a supplement to the general Microsoft-recommended design principles outlined in Best practices to set up networking for workloads migrated to Azure.
Key Takeaways
To sum up the recommendations and considerations covered here:
- Understanding the options available for securing Azure networks can help drive a more robust and resilient architecture, while removing potential bottlenecks.
- Azure Network Security Groups and firewalls both play a role in securing and inspecting network traffic and are often deployed in parallel as complementary infrastructure components.
- Be aware of public cloud-specific considerations that may be designed to enhance user experience (Accelerated Networking, configuration changes to leverage EDT through a Citrix Gateway).
Citrix deployments on public cloud have become commonplace in recent years and are only going to continue growing. If you need assistance with the implementation of your cloud-hosted platform, contact our Professional Services team to take advantage of many more leading practices and a plethora of field experience.
