![]() ![]() Step 7: Now we need to create the Phase 2 section, where all the local and remote connection settings will be needed. Create an Pre-Shared key, you can use your own key generator or personal password for this one, save it at a secure place. You can check this on the Virtual Gateway Essentials screen (after the creation of the Virtual Gateway is completed). Where the Remote Gateway is the Azure Public IP address (from step 4). Step 6: Setup the following general information settings. So if you familiar with pfsense it’s very simple, first you need to configure the IPsec that is in the menu accessible at the VPN part. For my homelab environment I use a pfsense (v2.3) device. ![]() Step 5: Now we need to prepare the on-premises IPsec VPN device for Azure usage. ![]() So let’s f ill in the name of the local network, enter the public IP of your on-premises IPsec gateway in the IP address field and configure all the local on-premises networks in Address space that you want to use in Azure and vice versa. Step 6 : We need to create a new local network gateway, in here we define the on-premises subnets and the public IP of you on-premises IPsec gateway. ![]() Note: This process can take a while (20-40 minutes), in the meanwhile we can proceed step 6 and 7. Setup the just created Virtual Network and create a new Public IP to use as Public Gateway IP that your on-premises IPsec tunnel will need to connect to. Step 4: Create a Virtual Gateway in Azure, name the gateway like Gateway-Organization choose for Gateway type VPN and VPN type Route-Based. The subnet must be at least /27 (32 addresses). Step 3: After the creation we need to create a new G atewaySubnet, this is the route subnet that is needed to configure the IPsec VPN network.To do so, open the vNet settings, go to Subnets and tick on the + next to Gateway subnet. Configure the subnet mask to your needs, I suggest to make it large, to create more flexibility in subnets for future usage Do not choose the same subnet as your on-premises network, its technically not possible on a layer 2 connection to extend the network. Step 3 : If you not created an Azure virtual network already, you need to do this first. Step 2: Create a Resource Group to bundle all your Azure resources. Step 1: First you need to have an VPN connection to Azure, otherwise your XenApp servers cannot register succesfull to the on-premises broker server. See this article to check all the supported devices, like NetScaler CloudBridge /SD-WAN ! IPsec supported VPN device at your on-prem site (in this article I will use a virtual pfsense).Note: This article is based on the Azure Resource Manager platform (v2), not the classic platform (v1). If you already have an active IPsec VPN to Azure and only want to know how to setup an Azure ARM Host Connection and a Citrix XenApp Desktop or configure Published Apps in Azure ARM, then skip to Step 13. In this blog article I describe in 3 sections how you can create a IPsec VPN tunnel from a pfsense firewall to the Azure Public Cloud, the configuration of an Azure ARM Host connection and the creation of a Machine Catalog and Delivery group to final the XenApp Published Application/Desktop setup of Azure Cloud (ARM platform). I personally think that all the new upcoming features will be released first to the Citrix Cloud after it go public to customers. What actually means that your on-premises desktop delivery controller can now deploy machines in Azure ARM, based on the MCS imaging strategy. Citrix already introduced this feature 2 months earlier to the Citrix Cloud, as they introduced the Cloud first release policy we had to wait. Since Citrix released their XenApp and XenDesktop 7.11 version, the software did get supported for the Azure Resource Manager Host Connection. ![]()
0 Comments
Leave a Reply. |