NetScaler SD-WAN Standard Edition is now available in Azure marketplace on BYOL basis. NetScaler SD-WAN Standard Edition for Azure logically bonds multiple network links into a single secure logical virtual path. The solution enables organizations to use connections from different service providers including Broadband, MPLS, 4G/LTE, Satellite, and point-to-point links to get high resiliency virtual WAN paths. NetScaler SD-WAN for Azure enables organizations to have a direct secure connection from each branch to the applications hosted in Azure eliminating the need to backhaul cloud bound traffic through a data center. Some of the benefits of using NetScaler SD-WAN in Azure are:
- Create direct connections from every location to Azure.
- Ensure an always on connection to Azure.
- Extend your secure perimeter to the cloud.
- Evolve to a simple, easy to manage branch network.
Topology - SD-WAN in Azure
NetScaler SD-WAN Standard Edition can only be deployed in Gateway deployment mode in Azure. A Public IP address (Static/Dynamic) can be assigned to both the management and WAN facing interface of SD-WAN in Azure. Since Azure only supports one public IP per instance, the web management GUI needs to be accessed through private IP assigned to the instance through a Windows/Linux machine.
An Azure VM is deployed within a specified region and can be connected to multiple branch locations through MPLS, Internet, or 4G/LTE. Within a Virtual Network (VNET) infrastructure, SD-WAN Standard Edition VHD (Virtual Hard Drive) is deployed in Gateway mode. The VNET has routes towards the Azure Gateway. SD-WAN instance has a route towards the Azure Gateway for internet connectivity.
Connectivity between Data Center, Branch, and Cloud is achieved by using different transports methods utilizing multiple WAN paths simultaneously.
To deploy NetScaler SD-WAN Standard Edition in Microsoft Azure:
- In a web browser, type https://portal.azure.com. Log into Microsoft Azure account. Search for NetScaler SD-WAN Standard Edition.
2. In the search results window, choose the solution as shown below:
3. Click create after going through the description and making sure the solution chosen is correct.
4. After you click Create, a wizard prompting for details necessary to create the virtual machine in Azure appears. In the first step, choose the resource group in which you like to deploy the solution. A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You can decide how you want to allocate resources to resource groups based on your deployment. Some important points to consider when defining your resource group are:
- a) All the resources in your group should share lifecycle. You deploy, update, and delete them together.
- b) If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.
- c) Each resource can only exist in one resource group.
- d) You can add or remove a resource to another resource group at any time.
- e) You can move a resource from one resource group to another resource group
- f) A resource group can contain resources that reside in different regions.
- g) A resource group can be used to scope access control for administrative actions.
- h) A resource can interact with resources in other resource groups. This interaction is common when the two resources are related but do not share lifecycle (for example, web apps connecting to a database).
In the following image, choose Create New.
Under Location, choose the region in which you want to deploy the solution. When creating a resource group, you need to provide a location for that resource group. The resource group stores metadata about the resources that you are creating. Therefore, when you specify a location for the resource group, you are specifying where that metadata is stored.
5. Provide a name for the Virtual Machine. Choose a username and strong password. The password must consist of an upper case letter, special character and must be more than nine characters. Click OK.
6. Choose the instance in which you want to run the image. The Standard_D3_V2 instance is applicable to the VPX-SE appliance only. The Standard_D4_V2, and F8 instance types are supported on the VPXL-SE appliance. If you are looking to achieve 200 Mbps of aggregated throughput, then choose Standard_D4_V2 as the instance type.
7. After choosing the image, choose the storage account. If you have an existing storage account, then you may choose that. In this step, you are creating a storage account as seen below. A storage account stores the VHDs for the operating system's temporary and more data disks.
8. Choose a Public IP for the Virtual Machine. You may choose either a static or dynamic IP. However, it is recommended that you choose a static IP.
The public IP that is assigned to the appliance here is provided by Azure and will become the Virtual IP of the SD-WAN VM and would be used to communicate with the Master Control Node. The public IP address can be assigned to the management or the WAN interface of SD-WAN.
9. After you have assigned an IP address, assign a DNS label. This DNS label must be able to uniquely identify the SD-WAN VM.
10. Create a new Virtual Network (VNET) or use an existing VNET. This is the most critical step for deployment as this step chooses the subnets to be assigned to the interfaces of the SD-WAN VM.
11. You can now assign the required subnets to each of the interfaces in the VM. The ordering for assigning subnets is WAN, LAN, and Management respectively. Choose as required and click OK. In the following image, you are assigning the subnets to each of the interfaces.
12. Verify all the configuration details and click OK.
13. Configure route settings.
14. All the configuration that you provided in previous steps is validated and applied. If you have configured correctly, then you should see that the validation passed message as shown below. Click OK.
15. After validation is passed, click on Purchase to purchase and create the image.
16. After you make the purchase, the deployment starts and you can view the status in the notifications section.
17. You can get more details of your deployment by going to the resource group in which you are creating the deployment.
18. After the deployment is successful, try to access the GUI through the public IP address. Use your administrator login credentials to log in. Modify the default password for security purposes.
19. To access the GUI for managing the solution, you need to configure a Windows VM in the same vnet and connect to the management IP assigned to the appliance. The management IP is assigned to the last NIC (sdwanrg42-Nic2 as shown below). You need to connect to the GUI of the appliance through the management IP assigned to this NIC, 10.14.2.4 as shown below.
20. After you log into the GUI, notice that the virtual service is disabled. This is because either the BYOL (Bring Your Own License) license is not installed or the SD-WAN appliance is not configured. Install the license through the licensing tab, if you have the license already or order a new one by going to http://store.citrix.com.
21. After the license is installed, you can apply configuration to the appliance and use it like any other branch. For more information on configuring the appliance, please refer to: http://docs.citrix.com/en-us/netscaler-sd-wan/9-3.html
For more information about configuring virtual WAN service, see SD-WAN configuration.
Limitations - Microsoft Azure VMs
- After a VM is created and booted in Azure, the interfaces cannot be added or deleted. The VM profile (RAM/HD/CPUs) can be changed.
- Azure does not allow two network interfaces NIC on a VM to have IP address on same subnet. There is no L2 Support and bridging is not allowed. SE-VPX on Azure has to be deployed in Gateway mode.
- There is no concept of MAC address spoofing in Azure Cloud. The LAN subnet of the SE-VPX and the LAN subnet of the Client/Server Host have to be different. This requires more routing configuration to be done in two places.
- PCI Enumeration causes the order of NICs in an Azure VM to get switched on reboots. This might cause Management Subnet unreachability.
–Routes have to be added in the Virtual WAN Configuration file directing all Virtual WAN Data traffic coming from the WAN to the Client/Server LAN Subnet.