Network connections

Introduction

This article provides details about several deployment scenarios when using a Citrix Managed Azure subscription.

When creating a catalog, you indicate if and how users access locations and resources on their corporate on-premises network from their Citrix DaaS Standard for Azure (formerly Citrix Virtual Apps and Desktops Standard for Azure) desktops and apps.

When using a Citrix Managed Azure subscription, the choices are:

• No connectivity
• Azure VNet peering
• SD-WAN

When using one of your own customer-managed Azure subscriptions, there is no need to create a connection to Citrix DaaS for Azure. You just add the Azure subscription to Citrix DaaS for Azure.

You cannot change a catalog’s connection type after the catalog is created.

Requirements for all network connections

• When creating a connection, you must have valid DNS server entries.
• When using Secure DNS or a third-party DNS provider, you must add the address range that is allocated for use by Citrix DaaS for Azure to the DNS provider’s IP addresses on the allow list. That address range is specified when you create a connection.
• All service resources that use the connection (domain-joined machines) must be able to reach your Network Time Protocol (NTP) server, to ensure time synchronization.

No connectivity

When a catalog is configured with No connectivity, users cannot access resources on their on-premises or other networks. This is the only choice when creating a catalog using quick create.

About Azure VNet peering connections

Virtual network peering seamlessly connects two Azure virtual networks (VNets): yours and the Citrix DaaS for Azure VNet. Peering also helps enable users to access files and other items from your on-premises networks.

As shown in the following graphic, you create a connection using Azure VNet peering from the Citrix Managed Azure subscription to the VNet in your company’s Azure subscription.

Here’s another illustration of VNet peering.

Users can access their on-premises network resources (such as file servers) by joining the local domain when you create a catalog. (That is, you join the AD domain where file shares and other needed resources reside.) Your Azure subscription connects to those resources (in the graphics, using a VPN or Azure ExpressRoute). When creating the catalog, you provide the domain, OU, and account credentials.

IMPORTANT:

• Learn about VNet peering before using it in Citrix DaaS for Azure.
• Create a VNet peering connection before creating a catalog that uses it.

Azure VNet peering custom routes

Custom, or user-defined, routes override Azure’s default system routes for directing traffic between virtual machines in a VNet peering, on-premises networks, and the Internet. You might use custom routes if there are networks that Citrix DaaS for Azure resources are expected to access but aren’t directly connected through VNet peering. For example, you might create a custom route that forces traffic through a network appliance to the Internet or to an on-premises network subnet.

To use custom routes:

• You must have an existing Azure virtual network gateway or a network appliance such as Citrix SD-WAN in your Citrix DaaS for Azure environment.
• When you add custom routes, you must update your company’s route tables with the Citrix DaaS for Azure destination VNet information to ensure end-to-end connectivity.
• Custom routes are displayed in Citrix DaaS for Azure in the order in which they are entered. This display order does not affect the order in which Azure selects routes.

Before using custom routes, review the Microsoft article Virtual network traffic routing to learn about using custom routes, next hop types, and how Azure selects routes for outbound traffic.

You can add custom routes when you create an Azure VNet peering connection or to existing ones in your Citrix DaaS for Azure environment. When you’re ready to use custom routes with your VNet peering, refer to the following sections in this article:

• For custom routes with new Azure VNet peerings: Create an Azure VNet peering connection
• For custom routes with existing Azure VNet peerings: Manage custom routes for existing Azure VNet peer connections

Azure VNet peering requirements and preparation

• Credentials for an Azure Resource Manager subscription owner. This must be an Azure Active Directory account. Citrix DaaS for Azure does not support other account types, such as live.com or external Azure AD accounts (in a different tenant).
• An Azure subscription, resource group, and virtual network (VNet).
• Set up the Azure network routes so that VDAs in the Citrix Managed Azure subscription can communicate with your network locations.
• Open Azure network security groups from your VNet to the specified IP range.

• Active Directory: For domain-joined scenarios, we recommend that you have some form of Active Directory services running in the peered VNet. This takes advantage of the low latency characteristics of the Azure VNet peering technology.

  For example, the configuration might include Azure Active Directory Domain Services (AADDS), a domain controller VM in the VNet, or Azure AD Connect to your on-premises Active Directory.

  After you enable AADDS, you cannot move your managed domain to a different VNet without deleting the managed domain. So, it’s important to select the correct VNet to enable your managed domain. Before proceeding, review the Microsoft article Networking considerations for Azure AD Domain Services.

• VNet IP range: When creating the connection, you must provide an available CIDR address space (IP address and network prefix) that is unique among the network resources and the Azure VNets being connected. This is the IP range assigned to the VMs within the Citrix DaaS for Azure peered VNet.

  Ensure that you specify an IP range that does not overlap any addresses that you use in your Azure and on-premises networks.

  • For example if your Azure VNet has an address space of 10.0.0.0 /16, create the VNet peering connection in Citrix DaaS for Azure as something such as 192.168.0.0 /24.

  • In this example, creating a peering connection with a 10.0.0.0 /24 IP range would be considered an overlapping address range.

  If addresses overlap, the VNet peering connection might not be created successfully. It also does not work correctly for site administration tasks.

To learn about VNet peering, see the following Microsoft articles.

• Virtual network peering
• Azure VPN Gateway
• Create a Site-to-Site connection in the Azure portal
• VPN Gateway FAQ (search for “overlap”)

Create an Azure VNet peering connection

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right. If you have already set up connections, they’re listed.

   

2. Click Add Connection.

3. Click anywhere in the Add Azure VNet Peering box.

   

4. Click Authenticate Azure Account.

   

5. Citrix DaaS for Azure automatically takes you to the Azure sign-in page to authenticate your Azure subscriptions. After you sign in to Azure (with the global administrator account credentials) and accept the terms, you are returned to the connection creation details dialog.

   

6. Type a name for the Azure VNet peer.
7. Select the Azure subscription, resource group, and the VNet to peer.
8. Indicate whether the selected VNet uses an Azure Virtual Network Gateway. For information, see the Microsoft article Azure VPN Gateway.

9. If you answered Yes in the previous step (the selected VNet uses an Azure virtual network gateway), indicate whether you want to enable virtual network gateway route propagation. When enabled, Azure automatically learns (adds) all routes through the gateway.

   You can change this setting later on the connection’s Details page. However, changing it can cause route pattern changes and VDA traffic interruptions. Also, if you disable it later, you must manually add routes to networks that VDAs will use.

10. Type an IP address and select a network mask. The address range to be used is displayed, plus how many addresses that the range supports. Ensure that the IP range does not overlap any addresses that you use in your Azure and on-premises networks.

    • For example, if your Azure VNet has an address space of 10.0.0.0 /16, create the VNet peering connection in Citrix Virtual Apps and Desktops Standard as something such as 192.168.0.0 /24.
    • In this example, creating a VNet peering connection with a 10.0.0.0 /24 IP range would be considered an overlapping address range.

    If addresses overlap, the VNet peering connection might not be created successfully. It also won’t work correctly for site administration tasks.

11. Indicate whether you want to add custom routes to the VNet peering connection. If you select Yes, enter the following information:
    1. Type a friendly name for the custom route.
    2. Enter the destination IP address and network prefix. The network prefix must be between 16 and 24.

    3. Select a next hop type for where you want traffic to be routed. If you select Virtual appliance, enter the internal IP address of the appliance.

       

       For more information about next hop types, see Custom routes in the Microsoft article Virtual network traffic routing.

    4. Click Add route to create another custom route for the connection.
12. Click Add VNet Peering.

After the connection is created, it is listed under Network Connections > Azure VNet Peers on the right side of the Manage > Azure Quick Deploy dashboard. When you create a catalog, this connection is included in the available network connections list.

View Azure VNet peering connection details

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right.
2. Select the Azure VNet peering connection you want to display.

Details include:

• The number of catalogs, machines, images, and bastions that use this connection.
• The region, allocated network space, and peered VNets.
• The routes currently configured for the VNet peering connection.

Manage custom routes for existing Azure VNet peer connections

You can add new custom routes to an existing connection or modify existing custom routes, including disabling or deleting custom routes.

IMPORTANT:

Modifying, disabling, or deleting custom routes changes the traffic flow of the connection and might disrupt any user sessions that might be active.

To add a custom route:

1. From the VNet peering connection details, select Routes and then click Add Route.
2. Enter a friendly name, the destination IP address and prefix, and the next hop type you want to use. If you select Virtual Appliance as the next hop type, enter the internal IP address of the appliance.
3. Indicate whether you want to enable the custom route. By default, the custom route is enabled.
4. Click Add Route.

To modify or disable a custom route:

1. From the VNet peering connection details, select Routes and then locate the custom route you want to manage.

2. From the ellipsis menu, select Edit.

   

3. Make any needed changes to the destination IP address and prefix or the next hop type, as needed.
4. To enable or disable a custom route, in Enable this route?, select Yes or No.
5. Click Save.

To delete a custom route:

1. From the VNet peering connection details, select Routes and then locate the custom route you want to manage.
2. From the ellipsis menu, select Delete.
3. Select Deleting a route may disrupt active sessions to acknowledge the impact of deleting the custom route.
4. Click Delete Route.

Delete an Azure VNet peering connection

Before you can delete an Azure VNet peer, remove any catalogs associated with it. See Delete a catalog.

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right.
2. Select the connection you want to delete.
3. From the connection details, click Delete Connection.

About SD-WAN connections

IMPORTANT:

Citrix SD-WAN has been deprecated and all related content will be removed from the documentation in a future release. We recommend that you switch to alternative networking solutions to ensure uninterrupted access to Citrix services.

Citrix SD-WAN optimizes all the network connections needed by Citrix Virtual Apps and Desktops Standard for Azure. Working in concert with the HDX technologies, Citrix SD-WAN provides quality-of-service and connection reliability for ICA and out-of-band Citrix Virtual Apps and Desktops Standard traffic. Citrix SD-WAN supports the following network connections:

• Multi-stream ICA connection between users and their virtual desktops
• Internet access from the virtual desktop to websites, SaaS apps, and other cloud properties
• Access from the virtual desktop back to on-premises resources such as Active Directory, file servers, and database servers
• Real-time/interactive traffic carried over RTP from the media engine in the Workspace app to cloud-hosted Unified Communications services such as Microsoft Teams
• Client-side fetching of videos from sites like YouTube and Vimeo

As shown in the following graphic, you create an SD-WAN connection from the Citrix Managed Azure subscription to your sites. During connection creation, SD-WAN VPX appliances are created in the Citrix Managed Azure subscription. From the SD-WAN perspective, that location is treated as a branch.

SD-WAN connection requirements and preparation

• If the following requirements are not met, the SD-WAN network connection option is not available.

  • Citrix Cloud entitlements: Citrix Virtual Apps and Desktops Standard for Azure and SD-WAN Orchestrator.
  • An installed and configured SD-WAN deployment. The deployment must include a Master Control Node (MCN), whether in the cloud or on-premises, and be managed with SD-WAN Orchestrator.

• VNet IP range: Provide an available CIDR address space (IP address and network prefix) that is unique among the network resources being connected. This is the IP range assigned to the VMs within the Citrix Virtual Apps and Desktops Standard VNet.

  Ensure that you specify an IP range that does not overlap any addresses that you use in your cloud and on-premises networks.

  • For example, if your network has an address space of 10.0.0.0 /16, create the connection in Citrix Virtual Apps and Desktops Standard as something such as 192.168.0.0 /24.
  • In this example, creating a connection with a 10.0.0.0 /24 IP range would be considered an overlapping address range.

  If addresses overlap, the connection might not be created successfully. It also does not work correctly for site administration tasks.

• The connection configuration process includes tasks that you (the Citrix DaaS for Azure administrator) and the SD-WAN Orchestrator administrator must complete. Also, to complete your tasks, you need information provided by the SD-WAN Orchestrator administrator.

  We recommend that you both review the guidance in this document, plus the SD-WAN documentation, before actually creating a connection.

Create an SD-WAN connection

IMPORTANT:

For details about SD-WAN configuration, see SD-WAN configuration for Citrix Virtual Apps and Desktops Standard for Azure integration.

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right.
2. Click Add Connection.
3. On the Add a network connection page, click anywhere in the SD-WAN box.
4. The next page summarizes what’s ahead. When you’re done reading, click Start Configuring SD-WAN.

5. On the Configure SD-WAN page, enter the information provided by your SD-WAN Orchestrator administrator.

   • Deployment mode: If you select High availability, two VPX appliances are created (recommended for production environments). If you select Standalone, one appliance is created. You cannot change this setting later. To change to the deployment mode, you’ll have to delete and re-create the branch and all associated catalogs.
   • Name: Type a name for the SD-WAN site.
   • Throughput and number of offices: This information is provided by your SD-WAN Orchestrator administrator.
   • Region: The region where the VPX appliances will be created.
   • VDA subnet and SD-WAN subnet: This information is provided by your SD-WAN Orchestrator administrator. See SD-WAN connection requirements and preparation for information about avoiding conflicts.
6. When you’re done, click Create Branch.
7. The next page summarizes what to look for on the Manage > Azure Quick Deploy dashboard. When you’re done reading, click Got it.
8. On the Manage > Azure Quick Deploy dashboard, the new SD-WAN entry under Network Connections shows the progress of the configuration process. When the entry turns orange with the message Awaiting activation by SD-WAN administrator, notify your SD-WAN Orchestrator administrator.
9. For SD-WAN Orchestrator administrator tasks, see the SD-WAN Orchestrator product documentation.
10. When the SD-WAN Orchestrator administrator finishes, the SD-WAN entry under Network Connections turns green, with the message You can create catalogs using this connection.

View SD-WAN connection details

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right.
2. Select SD-WAN if it’s not the only selection.
3. Click the connection you want to display.

The display includes:

• Details tab: Information you specified when configuring the connection.
• Branch Connectivity tab: Name, cloud connectivity, availability, bandwidth tier, role, and location for each branch and MCN.

Delete an SD-WAN connection

Before you can delete an SD-WAN connection, remove any catalogs associated with it. See Delete a catalog.

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right.
2. Select SD-WAN if it’s not the only selection.
3. Click the connection you want to delete, to expand its details.
4. On the Details tab, click Delete Connection.
5. Confirm the deletion.

Azure VPN Technical Preview

The Azure VPN feature is available for technical preview.

About Azure VPN gateway connections

An Azure VPN gateway connection provides a communication link between your Citrix-managed Azure VDAs (desktops and apps) and your company’s resources, such as on-premises networks or resources in other cloud locations. This is similar to setting up and connecting to a remote branch office.

The secure connectivity uses the industry-standard protocols Internet Protocol Security (IPsec) and Internet Key Exchange (IKE).

During the connection creation process:

• You provide information that Citrix uses to create the gateway and connection.

• Citrix creates a site-to-site route-based Azure VPN gateway. The VPN gateway forms a direct Internet Protocol Security (IPsec) tunnel between the Citrix-managed Azure subscription and your VPN’s host device.

• After Citrix creates the Azure VPN gateway and connection, you update your VPN’s configuration, firewall rules, and route tables. For this process, you use a public IP address that Citrix provides, and a pre-shared key (PSK) that you provided for creating the connection.

An example connection is illustrated in Create an Azure VPN gateway connection.

You do not need your own Azure subscription to create this type of connection.

You can also optionally use custom routes with this connection type.

Azure VPN gateway custom routes

Custom, or user-defined, routes override default system routes for directing traffic between virtual machines in your networks, and the Internet. You might use custom routes if there are networks that Citrix Virtual Apps and Desktops Standard resources are expected to access but aren’t directly connected through an Azure VPN gateway. For example, you might create a custom route that forces traffic through a network appliance to the Internet or to an on-premises network subnet.

When you add custom routes to a connection, those routes apply to all machines that use that connection.

To use custom routes:

• You must have an existing virtual network gateway or a network appliance such as Citrix SD-WAN in your Citrix Virtual Apps and Desktops Standard environment.
• When you add custom routes, you must update your company’s route tables with the destination VPN information to ensure end-to-end connectivity.
• Custom routes are displayed on the Connection > Routes tab in the order they are entered. This display order does not affect the order in which routes are selected.

Before using custom routes, review the Microsoft article Virtual network traffic routing to learn about using custom routes, next hop types, and how Azure selects routes for outbound traffic.

You can add custom routes when you create an Azure VPN gateway connection or to existing connections in your service environment.

Azure VPN gateway connection requirements and preparation

• To learn about Azure VPN Gateway, see the Microsoft article What is VPN Gateway?

• Review the requirements for all network connections.

• You must have a configured VPN. The virtual network must be able to send and receive traffic through the VPN gateway. A virtual network can’t be associated with more than one virtual network gateway.

• You must have an IPsec device that has a public IP address. To learn about validated VPN devices, see the Microsoft article About VPN devices.

• Review the Create an Azure VPN Gateway connection procedure before you actually start it, so you can collect the information you need. For example, you’ll need allowed addresses in your network, IP ranges for the VDAs and gateway, desired throughput and performance level, and DNS server addresses.

Create an Azure VPN gateway connection

Be sure to review this procedure before actually starting it.

The following diagram shows an example of configuring an Azure VPN gateway connection. Generally, Citrix manages resources on the left side of the diagram, and you manage resources on the right side. Some descriptions in the following procedure include references to the diagram’s examples.

1. From the Manage dashboard in Citrix DaaS for Azure, expand Network Connections on the right.

2. Click Add Connection.

3. Click anywhere in the Azure VPN Gateway box.

4. Review the information on the Add VPN Connection page, and then click Start Configuring VPN.

5. On the Add a connection page, provide the following information.

   • Name: A name for the connection. (In the diagram, the name is TestVPNGW1.)

   • VPN IP address: Your public-facing IP address.

     In the diagram, the address is 40.71.184.214.

   • Allowed networks: One or more address ranges that the Citrix service is allowed to access on your network. Usually, this address range contains the resources that your users need to access, such as file servers.

     To add more than one range, click Add more IP addresses and enter a value. Repeat as needed.

     In the diagram, the address range is 192.168.3.0/24.

   • Pre-shared key: A value that is used by both ends of the VPN for authentication (similar to a password). You decide what this value is. Be sure to note the value. You’ll need it later when you configure your VPN with the connection information.

   • Performance and throughput: The bandwidth level to use when your users access resources on your network.

     All choices do not necessarily support Border Gateway Protocol (BGP). In those cases, the BCP settings fields aren’t available.

   • Region: Azure region where Citrix deploys machines that deliver desktops and apps (VDAs), when you create catalogs that use this connection. You cannot change this selection after you create the connection. If you decide later to use a different region, you must create or use another connection that specifies the desired region.

     In the diagram, the region is EastUS.

   • Active-active (high availability) mode: Whether two VPN gateways are created for high availability. When this mode is enabled, only one gateway is active at a time. Learn about active-active Azure VPN gateway in the Microsoft document Highly Available Cross-Premises Connectivity.

   • BGP settings: (Available only if the selected Performance and throughput supports BGP.) Whether to use Border Gateway Protocol (BGP). Learn about BGP in the Microsoft document: About BGP with Azure VPN Gateway. If you enable BGP, provide the following information:

     • Autonomous system number (ASN): Azure virtual network gateways are assigned a default ASN of 65515. A BGP-enabled connection between two network gateways requires that their ASNs be different. If needed, you can change the ASN now or after the gateway is created.

     • BGP IP peering IP address: Azure supports BGP IP in the range 169.254.21.x to 169.254.22.x.

   • VDA subnet: The address range where Citrix VDAs (machines that deliver desktops and apps) and Cloud Connectors will reside when you create a catalog that uses this connection. After you enter an IP address and select a network mask, the address range is displayed, plus how many addresses that the range supports.

     Although this address range is maintained in the Citrix-managed Azure subscription, it functions as if it is an extension of your network.

     • The IP range must not overlap any addresses that you use in your on-premises or other cloud networks. If addresses overlap, the connection might not be created successfully. Also, an overlapping address won’t work correctly for site administration tasks.

     • The VDA subnet range must be different from the gateway subnet address.

     • You cannot change this value after you create the connection. To use a different value, create another connection.

     In the diagram, the VDA subnet is 10.11.0.0/16.

   • Gateway subnet: The address range where the Azure VPN gateway will reside when you create a catalog that uses this connection.

     • The IP range must not overlap any addresses that you use in your on-premises or other cloud networks. If addresses overlap, the connection might not be created successfully. Also, an overlapping address won’t work correctly for site administration tasks.

     • The gateway subnet range must be different from the VDA subnet address.

     • You cannot change this value after you create the connection. To use a different value, create another connection.

     In the diagram, the gateway subnet is 10.12.0.9/16.

   • Routes: Indicate whether you want to add custom routes to the connection. If you want to add custom routes, provide the following information:

     • Type a friendly name for the custom route.

     • Enter the destination IP address and network prefix. The network prefix must be between 16 and 24.

     • Select a next hop type for where you want traffic to be routed. If you select **Virtual appliance, enter the internal IP address of the appliance. For more information about next hop types, see Custom routes in the Microsoft article Virtual network traffic routing.

   To add more than one route, click Add route and enter the requested information.

   • DNS servers: Enter addresses for your DNS servers, and indicate the preferred server. Although you can change the DNS server entries later, keep in mind that changing them can potentially cause connectivity issues for the machines in catalogs that use this connection.

     To add more than two DNS server addresses, click Add alternate DNS and then enter the requested information.

6. Click Create VPN Connection.

After Citrix creates the connection, it is listed under Network Connections > Azure VPN Gateway on the Manage dashboard in Citrix DaaS for Azure. The connection card contains a public IP address. (In the diagram, the address is 131.1.1.1.)

• Use this address (and the pre-shared key you specified when creating the connection) to configure your VPN and firewalls. If you forgot your pre-shared key, you can change it on the connection’s Details page. You’ll need the new key to configure your end of the VPN gateway.

  For example, allow exceptions in your firewall for the VDA and gateway subnet IP address ranges you configured.

• Update your company’s route tables with the Azure VPN gateway connection information to ensure end-to-end connectivity.

  In the diagram, new routes are required for traffic going from 192.168.3.0/24 to 10.11.0.0/16 and 10.12.0.9/16 (the VDA and gateway subnets).

• If you configured custom routes, make the appropriate updates for them, too.

When both ends of the connection are successfully configured, the connection’s entry in Network Connections > Azure VPN Gateway indicates Ready to use.

View an Azure VPN gateway connection

1. From the Manage dashboard in Citrix DaaS for Azure, expand Network Connections on the right.

2. Select the connection you want to display.

   Displays:

• The Details tab shows the number of catalogs, machines, images, and bastions that use this connection. It also contains most of the information you configured for this connection.

• The Routes tab lists custom route information for the connection.

Manage custom routes for an Azure VPN gateway connection

In an existing Azure VPN gateway connection, you can add, modify, disable, and delete custom routes.

For information about adding custom routes when you create a connection, see Create an Azure VPN gateway connection.

IMPORTANT:

Modifying, disabling, or deleting custom routes changes the traffic flow of the connection, and might disrupt active user sessions.

1. From the Manage dashboard in Citrix DaaS for Azure, expand Network Connections on the right.

2. Select the connection you want to display.

   • To add a custom route:

     1. From the connection’s Routes tab, click Add Route.

     2. Enter a friendly name, the destination IP address and prefix, and the next hop type you want to use. If you select Virtual Appliance as the next hop type, enter the internal IP address of the appliance.

     3. Indicate whether you want to enable the custom route. By default, the custom route is enabled.

     4. Click Add Route.

   • To modify or enable/disable a custom route:

     1. From the connection’s Routes tab, locate the custom route you want to manage.

     2. From the ellipsis menu, select Edit.

     3. Change the destination IP address and prefix, or the next hop type, as needed.

     4. Indicate whether you want to enable the route.

     5. Click Save.

   • To delete a custom route:

     1. From the connection’s Routes tab, locate the custom route you want to manage.

     2. From the ellipsis menu, select Delete.

     3. Select Deleting a route may disrupt active sessions to acknowledge the impact of deleting the custom route.

     4. Click Delete Route.

Reset or delete an Azure VPN gateway connection

IMPORTANT:

• Resetting a connection causes the current connection to be lost, and both ends must reestablish it. A reset disrupts active user sessions.

• Before you can delete a connection, delete any catalogs that use it. See Delete a catalog.

To reset or delete a connection:

1. From the Manage dashboard in Citrix DaaS for Azure, expand Network Connections on the right.

2. Select the connection you want to reset or delete.

3. From the connection’s Details tab:

   • To reset the connection, click Reset Connection.

   • To delete the connection, click Delete Connection.

4. If prompted, confirm the action.

Create a public static IP address

If you want all machines VDAs on a connection to use a single outbound public static IP address (gateway) to the Internet, enable a NAT gateway. You can enable a NAT gateway for connections to catalogs that are domain joined or non-domain joined.

To enable a NAT gateway for a connection:

1. From the Manage > Azure Quick Deploy dashboard in Citrix DaaS for Azure, expand Network Connections on the right.
2. Under Network Connections, select a connection under CITRIX MANAGED or AZURE VNET PEERINGS.
3. In the connection details card, click Enable NAT Gateway.
4. In the Enable NAT Gateway page, move the slider to Yes and configure an idle time.
5. Click Confirm Changes.

When you enable a NAT gateway:

• Azure assigns a public static IP address to the gateway automatically. (You cannot specify this address.) All VDAs in all catalogs that use this connection will use that address for outbound connectivity.

• You can specify an idle timeout value. That value indicates the number of minutes that an open outbound connection through the NAT gateway can remain idle before the connection is closed.

• You must allow the public static IP address in your firewall.

You can go back to the connection details card to enable or disable the NAT gateway and change the timeout value.

Brief Introduction of Azure Virtual Network

 Azure Networking : Brief Introduction of Azure Virtual Network

Azure Networking refers to a suite of services offered by Microsoft Azure that allows you to securely connect, manage, and monitor your resources within the Azure cloud platform. Microsoft provides various services and tools under Azure that make your network strong and easy to manage. This blog will cover the basics of networking concepts and an overview of Azure networking architecture with the above mentioned topics.

Overview of Azure

Azure is the name of the cloud computing service owned by Microsoft that provides Infrastructure as a Service (IaaS), Platform as a Service (Paas) and Software as a Service (SaaS). Azure’s cloud computing services are network, storage, compute, database, analytics, security, and many more. In this blog, we will only focus on the basics of network services.

What Is Azure Virtual Network?

An Azure Virtual Network (VNet) is a fundamental building block for creating your network within the Microsoft Azure cloud platform.
When it’s created, the services and Virtual Machines within the Azure network interact securely with one another.

Advantages of Using Azure Virtual Network

Some of the foremost advantages of using Microsoft Azure VNet are as follows:

• It provides an isolated environment for your applications
• A subnet in a very VNet can access the general public internet by default
• We can easily direct traffic from resources
• It is a highly secure network
• It has high network connectivity
• It builds sophisticated network topologies in a very simple manner

Moving on, let’s have a glance at the components of Azure VNet.

Elements of Azure Virtual Network

Azure networking components provide a large range of functionalities that may help companies build efficient cloud applications that meet their requirements.

The components of Azure Networking are listed below, and we have explained each of those components in an exceedingly detailed manner:

1. Subnets
2. Routing
3. Network Security Groups

Subnets

Subnets let users segment the virtual network into one or more sub-networks.
These sub-networks may be separated logically, and every subnet consists of a server.
We can further divide a subnet into two types:

1. Private – Instances can access the web with NAT (Network Address Translation) gateway that’s present within the public subnet.
2. Public – Instances can directly access the net.

Routing

• It delivers the information by choosing an appropriate path from source to destination.
• For each subnet, the virtual network automatically routes traffic and creates a routing table.

Network Security Groups

• It is a firewall that protects the virtual machine by limiting network traffic.
• It restricts inbound and outbound network traffic depending upon the destination IP addresses, port, and protocol.

How to Launch an Instance using Azure VNet?

• First, create a virtual network within the Azure cloud
• Next, create subnets into each virtual network
• Now, assign each subnet with the respective instance/Virtual Machine
• After which you’ll connect the instance/ VM to a relevant Network Security Group
• Finally, configure the properties within the network security and set policies if required for specific requirement
• As a result, you’ll be able to launch your instance/ VM on Azure

Moving forward, we’ll see an indication on creating an Azure virtual network step-by-step.

Demo: Step-By-Step Demo of Creating Azure  Virtual Network

Step 1 − First, log into your Azure  Portal by browsing to URL (portal.azure.com)

Step 2 − Search Virtual Network in Search resources , services & docs

Step 3 – Click  on +Create

Step 4 − Now, Enter all the required details of basic tab then click on Review + Create

Step 5 – Click on Create

Step 6 – Click on Go to resource to see your created Virtual Network.

Congratulations, you’ve successfully created an Azure Virtual Network.

Getting Familiar with IP Addressing

Before understanding IP Address, we need to learn the binary numbers. If you are not familiar with binary and decimal conversion, look at the brief explanation below.

In the decimal number system, the combinations are made using only the numbers from 0 to 9. In other words, it is the number system with a base of 10 (0 to 9). Similarly, in the Binary Number System base of 2 (0 and 1) is used. Each value in a binary number is made with 2N (‘N’ is the place value that increases from right to left). The below table shows the basic conversion between binary and decimal.

Binary	Conversion	Decimal
000	0x22+0x21+0x20	0
001	0x22+0x21+1×20	1
010	0x22+1×21+0x20	2
011	0x22+1×21+1×20	3
100	1×22+0x21+0x20	4
101	1×22+0x21+1×20	5

Also Check:  ARM Template.

What is IP Address?

IANA is the Internet Assigned Numbers Authority that manages and assigns the IP address in the world. IP Address identifies each device on a network uniquely. There are currently two IP Adress that is IPv4 and IPv6. An IPv4 address contains a total of 32 binary bits divided into 4 equal octets (8-bit block), whereas IPv6 is written in hexadecimal notation, separated into 8 groups of 16 bits by the colons, thus (8 x 16 = 128) bits in total. We will focus on IPv4 as it is the most used. Each octet of an IP Address is separated by a decimal and ranges from 0 to 255. You will clearly understand the binary number, octets, and IP address formation in the below table.

IP Address	Octet 1	Octet 2	Octet 3	Octet 4
10.2.7.4	00001010	00000010	00000111	00000100
192.124.249.161	11000000	01111100	11111001	10100001
255.255.140.40	11111111	11111111	10001100	00101000

There are two different IP address one is private, and the other is public.

• Private IP is accessed only within a network like a simple school network with a LAN connection.
• Public IP is accessed globally via the Internet.

The table below shows the Private IP address range assigned by IANA, and the rest are all Public IP address.

Private IP Range
10.0.0.1 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

Check Out: Azure Service Bus Pricing. 

What is IP Subnetting?

Subnetting is the process of dividing a network into many smaller networks. There are 5 classes of IP address and each with a unique purpose. Only the first octet is used for dividing an IP Address into different classes. The table below shows the range of IP address of the 5 classes.

Class	Octet 1 Range (in Binary)	Octet 1 Range (in Decimal)
Class A	00000000-01111111	0-126
Class B	10000000-10111111	128-191
Class C	11000000-11011111	192-223
Class D	11100000-11101111	224-239
Class E	11110000-11110111	240-255

Class D is reserved for multitasking and broadcasting purpose, whereas Class E is reserved for research and development. So both these classes are reserved and can not be used. The below table shows the range of the first octet in an IP address with each class.

Note: The IP address with the first octet as 127 (in decimal) is a loopback address to check the network and address of the machine itself.

An IP address can further be divided into small networks depending on the use and purpose. The above classes are not sufficient for real-life use. Only 5 classes can not hold all the hosts on the same network, and the loss of IP address will be huge. So, the CIDR method was introduced.

CIDR (Classless Inter-Domain Routing)

CIDR is a method for allocating IP Address. Using this method, we can apply a subnet mask to an IP Address. This mask defines the number of bits used as a network, and the host will use the other bits that left. To understand CIDR better, we will decode a simple IP address with a subnet mask.

Suppose 192.168.1.30/28 is an IP address with 28 as the subnet mask. By comparing with IP address classes in the above table, this IP comes under Class C. Now, 24 bits are made of 3 octets, so the network will take four extra bits from the next octet to complete 28 bits. Using 2N(‘N’ is the number of borrowed bits from the host), a total of 16 subnets is formed. After taking the four bits, the last octet is left with only 4 bits that a host will use. Using 2H(‘H’ is the number of host bits left), each subnet will contain a block of 16 IP address. The first and last IP is reserved for network and broadcast in each subnet, so the total number of hosts will be 2H-2(‘H’ is the number of host bits) equals 14.

Although a total of 16 subnets or network are possible for this example, the table below listed the initial 4 subnets that can be formed using 28 as the subnet mask. Each subnet contains a total of 16 IP address, and the number of hosts will be 14 as the other two are reserved for network and broadcast.

After comparing the IP given in the example that is 192.168.1.30/28 with the table below, it is clearly visible that it belongs to the second subnet ranging from 192.168.1.16 to 192.168.1.31.

Note: Every subnet’s first and last address is not allocated to any host as it is reserved for network and broadcast.

SubNet	Total IP	Network IP	Broadcast IP	Range of Hosts	Total Hosts
1	16	192.168.1.0	192.168.1.15	192.168.1.1-192.168.1.14	14
2	16	192.168.1.16	192.168.1.31	192.168.1.17-192.168.1.30	14
3	16	192.168.1.32	192.168.1.47	192.168.1.33-192.168.1.46	14
4	16	192.168.1.48	192.168.1.65	192.168.1.49-192.168.1.64	14

Check Out:  Azure Bastion.

IP Address in Azure

The two different types of IP Address used and allocated in Azure are Public IP and Private IP.

• Private – The Private IP address allows communication of resources within the azure resource group. In other words, resources can not access a private IP outside the network. The resources that can be connected using a private address are VM Network Interface, ILB (Internal Load Balancer) and Application Gateway.
• Public – The Public IP address allows Azure Resources to communicate with public-facing Azure services via the Internet. In other words, resources can access public IP outside the network. Some resources that can be connected using public address are VM Network Interface, Public Facing ILB, Application Gateway, VPN Gateway and Azure Firewall.

IP Allocation

• Dynamic IP – The default allocation method by which Azure can automatically assign the available and unreserved IP address from the subnet’s address range. Also, the Dynamic IP is not fixed and changes with time.
• Static IP – This is the custom allocation method to assign the available and unreserved IP address from the subnet’s address range. The Static IP is fixed and does not vary with time.

Also Read: Azure Load Balancer.

Azure Virtual Network

Azure Network is the interlinking and communication of all the Azure Resources in an organization. Networking leads to efficient resource work with better consistency and coordination.

Virtual Networking is the communication between devices, servers, virtual machines over the internet. Similarly, Azure Virtual Network (VNet) is a private network with interconnected Azure Resources like Azure Virtual Machines, Infrastructure and Network. It enables communication between various Azure Resources via the Internet. In a Virtual Network, a continuous block of IP Address is used to create multiple subnet networks.

Azure Subnet

As we know, the subnet is a part of a network that covers a range of IP Address. In Azure, VNet can be divided into smaller subnets for organizations. When a VNet is created in Azure, the subnet range and topology needs to be specified. In Subnet, the IP Address range will be a subpart from a big block of IP Address used in Virtual Network (VNet). The Virtual Machines and resources in a network will be assigned the IP Address from these subnets.

Azure Network Interface

In Azure, NIC is virtual ethernet cards that help communicate the Virtual Machines present in a network. When a Virtual Machine is created in Azure, the NIC with default settings is automatically created. Also, Network Interface settings in Azure can be customized using command tools like Azure CLI and PowerShell.

Network Security

Azure provides various protection methods for securing a service in a network. I have listed down some of the basic network security tools with a short description.

Network Security Group (NSG)

The Network Security Group in Azure acts like a firewall at the network level. It filters the traffic passing through Azure Resources in a virtual network. NSG is a group of security rules that defines the priority, source or destination, protocol, direction, port range and action. Using these rules, NSG allows or deny inbound and outbound traffic. The rules for entering traffic inside a resource is also called ‘Ingress‘, and the rules for exiting the traffic or going out of the resource is called ‘Egress‘. When all the rules are created, the NSG can be used in a Virtual Machine that will interact with a network.

Service Endpoints

Service Endpoints in Azure provides secure connectivity over the optimized route of the Azure Network. Without needing a public IP address, Service Endpoints allows Private IP address in a VNet to reach the endpoint of an Azure Service. It is simple to set up and improves security for the Azure resources in a network. The services here can be Azure Storage, Azure Database, etc.

Web Application Firewall (WAF)

Web applications are a common target for hackers to steal user information. So, protection from the most common attacks like SQL injection, cross-site scripting, etc., is a must. Web Application Firewall by Azure is a firewall for protecting the web application from these common threats. It provides an easy setup for applying various protection of layers that results in better security management. A user can deploy the WAF with other services like Azure Application Gateway, Azure Content Delivery Network (CDN) and Azure Front Door.

Azure Network Models

Network Models are the representation and methods of connecting multiple networks. In Azure also, Microsoft enables some ways to connect multiple networks. I have listed down some of the most used network models.

VNet Peering

Virtual Network peering enables to connect the two or more Virtual Networks in Azure. It also allows transferring data between deployment models, Azure Subscriptions, Azure Active Directory Tenants and Azure regions without downtime and failure. The traffic between the peered virtual networks use  Microsoft’s backbone infrastructure and is routed through a private network. Thus, gateways, encryption and public internet are not required.

There are two types of Virtual Network Peering:

1. Regional VNet Peering – When the two networks needed to peer are in the same region, the peering is called Regional VNet Peering.
2. Global VNet Peering – When the two networks are from different regions, the peering is called Global VNet Peering.

See More: VNet Peering in Azure

Virtual WAN (Wide Area Network)

Virtual WAN in Azure allows creating a web of multiple networks that are interconnected to each other. It brings multiple networking, security, and routing functionalities together to provide a new single operational interface.

In the above diagram, a Virtual WAN at the centre acts as a single operational hub to manage all the traffic coming from multiple resources in a VNet. Instead of contacting the multiple branches separately, a VNet can contact the central hub to connect with all the branches connected to it.

More Azure Virtual Network Information

Pricing

There is no charge for using Azure VNet; it’s freed from cost. Standard charges are applicable for resources, like Virtual Machines (VMs) and other products. to be told more, see VNet pricing and the Azure pricing calculator

Protecting Resources

Network security may well be defined because the process of protecting resources from unauthorized access or attack by applying controls to network traffic. The goal is to confirm that only legitimate traffic is allowed. Azure includes a sturdy networking infrastructure to support your application and repair connectivity requirements. Network connectivity is feasible between resources located in Azure, between on-premises and Azure hosted resources, and to and from the net and Azure.

Conclusion

Azure Networking allows secure communication between multiple resources in a network. From this blog, we understand the IP Address and created a subnet mask using the CIDR method. Also, we covered the basic Azure Networking topics like VNet (Virtual Network), Azure Subnet, Azure Network Interface, Network Security Group (NSG), Service Endpoints, Web Application Firewall (WAF), VNet Peering and Virtual WAN.

We only covered the basic terminology in Azure Networking. If you want to learn more about Azure Networking and get your Hands-on Azure, please check our  Microsoft Azure Job Oriented Program. It covers all the basic and expert-level knowledge in Azure and helps you to become a certified Solutions Architect in Azure.