Microsoft and Citrix recently made NetScaler available as an appliance within Microsoft Azure, with a bring-your-own-license model, meaning that we can deploy a virtual appliance and use our own license there. However, we still need to pay Microsoft for the running instance and network traffic that is going out of Azure cloud. As of now, three versions are supported in Azure: VPX 10, VPX 200, and VPX 1000.

If we want to deploy a NetScaler VPX within Microsoft Azure, we have to use the current build available in the Microsoft Azure Marketplace. As of now, it is only available in the new management portal.

First, you need to have an active subscription in place for Microsoft Azure. Then, go to the new management portal at https://portal.azure.com.

Next, navigate to the marketplace, which can be found in the main menu, Browse | Marketplace.

Here, we type Citrix NetScaler, and it will appear in the list of options, as shown in the following screenshot:

From there, click on Create. Then enter the required information, such as the IP address that will be used for management, username, and password. The default here is to enter nsroot and a custom password for that user. It is important to note that Microsoft Azure has its own DHCP service, which allows all virtual instances that run in Azure to get an IP address. Before deploying the virtual instance, you should define that the NetScaler VPX must use a static IP address to make sure that it does not lose its license in case of reboot or downtime, as in Azure, a virtual appliance may be moved to another and may be given another MAC address. In order to do so, navigate to Optional Configuration | Network | IP ADDRESSES. From here, you have the option to enter a static IP for the private IP address, which allows you to retain the IP address during reboots. Note also that Azure will automatically create a virtual network within a custom private IP range. So enter an IP address within the range that is created and click on OK.

The last thing to do before provisioning NetScaler is to enter a custom endpoint that will allow you to manage the appliance externally using HTTP. This can be done from within the provisioning wizard, before going into Optional Configuration. From here, you need to add an endpoint that defines which ports can be accessed externally. Here, add port 80 private, which is the internal port on NetScaler where management resides. Then, choose port TCP and then enter a public port. The public port nr will be used for external access later.

Another thing that is important to remember if you are deploying NetScaler in Azure is that by default, the appliance is deployed as an A2 Linux virtual machine. The A2 instance has a limitation of bandwidth of 200 Mbps. If you are planning to deploy a VPX 1000, you need to change this to an A4 instance.

NetScaler in Azure also has some additional limitations, for instance, it runs in a single-IP mode, meaning that we only have one useable IP address, so we use the same IP address for management, server traffic, and load balancing. As a part of this limitation, we can therefore not use the following ports for external services:

21, 22, 80, 443, 8080, 67, 161, 179, 500, 520, 3003, 3008, 3009, 3010, 3011, 4001, 5061, 9000, 7000

These ports cannot be used as they are used by the NetScaler for different purposes, such as high availability, management, and so on. Even though we cannot use these ports for our services on NetScaler, we can still use, for instance, 443 as an external port, since Azure has the concept of endpoints, which allow for port forwarding from one external port to another private port on NetScaler. Another thing to remember is that some features are not supported on NetScaler in Azure, which are: Clustering, IPv6, Gratuitous ARP (GARP), L2 Mode, Tagged VLAN, Dynamic Routing Virtual MAC (VMAC), USIP, GSLB, and CloudBridge Connector.

These features cannot be used because of the limitations of the network capabilities in Microsoft Azure. Also important is the fact that the current build running in the marketplace is the only one supported, so that means that we cannot do a direct upgrade as of now.

After we have deployed NetScaler in Azure, we access it using the FQDN given to us from the cloud service using SSH on a random port, or access it using HTTP on the custom endpoint we added.

NetScaler is available as an Amazon Machine Image in the Amazon Web Services (AWS) marketplace, and like Azure, you need an active subscription to provision the virtual appliance. Head over to the management portal on http://aws.amazon.com/ and choose login to the management portal. After logging in, you have the marketplace on the right-hand side, which, for reference, is located at https://aws.amazon.com/marketplace. Once there, search for Citrix NetScaler and press Enter. Now, you will get multiple options here as shown in the following screenshot:

You have the option to buy a finished Citrix licensed NetScaler appliance here, or you can buy an appliance without a license like with Azure. Choose the Customer Licensed option and then click on Continue.

Note that Citrix NetScaler in Amazon requires that you have a virtual private cloud (VPC) configured with three different subnets, which are not covered in this book. In order to learn how to configure VPC and different subnets, you can read more about it at http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html.

After the VPC and subnets are in place and the three different interfaces are placed within the three subnets, it's time to provision the virtual appliance.

Now, by default, the appliance will not get a public IP address attached to it, so you have to add an elastic IP address (EIP).

This can be done through the EC2 dashboard by navigating to Network and Security | Elastic IPs | Allocate New Address. After allocating a new address, assign it to the management interface of the virtual appliance. Right-click on the address and choose Associate Address, then choose either Instance or Network Interface and find the management interface from the list. Then click on Associate.

After this, you can reach the NSIP using the EIP address on HTTP, as shown in the following screenshot:

To log in, use nsroot. The password will always be set to the instance ID, which can be seen from the EC2 dashboard as well.

As with Azure, there are some limitations to the deployment of NetScaler in Amazon, and some features are not supported, such as IPV6, Gratuitous ARP (GARP), L2 mode, Tagged VLAN, and Dynamic Routing Virtual MAC (VMAC). However, unlike Azure, you are not bound to a single NIC and therefore do not have the same port restrictions.

Now, inside the main administration GUI we are presented with three main panes:

Configuration

The Configuration pane is where we do our configuration of services and also of NetScaler; this is where we will spend most of our time, and it also important how the GUI works and how to navigate in it.

By default, most of the features are disabled, which will appear in the GUI, as shown in the following screenshot:

This is because if we do not need them running, NetScaler will not start the services that they depend on.

In order to enable a feature, we can right-click on it and choose enable. Alternatively, we can navigate to System | Settings | Configure Modes.

Most of the features are sorted by the tasks they do, for instance, content switching and frontend optimization are both optimization features and are placed within the Optimization menu. When working with the GUI, in most cases, we will see a plus sign, which indicates that more options are available or that we can add an option to an object:

In many cases, we want to edit existing objects. Most of the objects in this version allow us to do so by clicking on the pencil icon.

Many of the features contain nested options, so it is important to look at the navigation bar where, for instance, you might be adding a policy and attaching it to an action, as shown in the following screenshot:

Now, we configure some basic features before deploying any services to NetScaler:

• DNS: This feature allows for name resolution
• NTP: This feature allows for time synchronization
• Syslog: This feature allows for central logging of states, auditing, and status information
• SNMP: This feature allows NetScaler to send alarms to a designated SNMP server

Syslog and SNMP features are not needed but should be evaluated in larger deployments and for auditing and monitoring purposes. For example, NetScaler can be monitored using SNMP with System Center Operations Manager. You can read more about it at http://msandbu.wordpress.com/2013/04/02/monitoring-netscaler-with-operations-manager-2012/.

It can also be monitored using the NITRO API interface using, for instance, PowerShell or Comtrade management pack for Citrix NetScaler, which is an extension to Operations Manager.

The first to add is a DNS server to allow for name resolution. This setting can be found by navigating to Configuration | Traffic Management | DNS | Name Servers. Here, click on Add and enter the IP address of the DNS server, and leave the rest as default values. After you have added the DNS server, NetScaler will automatically start monitoring it. Make sure that ICMP is also opened in the firewall to the DNS servers; NetScaler uses ICMP with UDP to monitor if the DNS servers are available. For redundancy, you should add more than one DNS server to the list. After you have added the DNS servers, you can verify the state of the servers by going back to the Name Servers pane.

Note

DNS using TCP is only needed for zone transfers, and therefore it is not used for regular name resolution. We also have the ability to use both UDP and TCP. This is used for TCP-enabled DNS systems.

After each configuration, I am going to show the CLI-based option to perform the same action. To add a DNS server using the CLI, use the following command:

add dns nameServer IPaddress

Next, you should add an NTP server. This is important because of logging purposes, timestamps, certificates, reporting, and so on. The NTP server's configuration can be found by navigating to System | NTP Servers. Here, click on Add and enter the IP information and a key if you are using authentication. If you do not have an NTP server available in your network, you can use a public one. You can find a public NTP server at http://www.pool.ntp.org/en/.

You can also add an NTP server using the following command:

add ntp server IPaddress

After you have added the NTP server, you have to perform a sync using the following CLI command:

enable ntp sync

You also need to change the time zone of NetScaler to reflect your own time zone. This can be done by navigating to System | Settings | Change time zone.

Another important feature that you should look closer at is Syslog. Syslog is a common open standard logging feature that allows you to place logs on a central host instead of on NetScaler itself. This makes it easier to view logs from different devices that use Syslog from a single repository. This is not something that I consider as required, but it makes it easier to access and view logs.

If you do not set up Syslog, you will have to view the different logs locally on NetScaler. The Syslog feature can be enabled by navigating to System | Auditing | Servers. This requires that you have a central Syslog server in place.

If you have a central monitoring solution, you should consider configuring SNMP. SNMP consists of alarms and traps. If any abnormalities happen, such as high usage of RAM or, for example, Syslog, an alarm will trigger on NetScaler and the SNMP agent on it will send the alarm to an SNMP trap listener (which could be a central SNMP solution such as Microsoft System Center Operations Manager).

In order to allow NetScaler to be queried by an SNMP server for information, enter the following information, which can be added in the GUI by navigating to System | SNMP:

• SNMP manager: This is the IP address of the host that is allowed access
• SNMP community string: This is used for authentication of the appliance

In order for NetScaler to send traps whenever a critical event occurs, enter the following information:

• Enable/Disable SNMP alarms: This defines which alarms should create a trap
• SNMP traps: This defines which host should get the traps and the conditions for the traps

You can also change the hostname of the appliance, which by default comes with the name ns. You can change it using the following CLI command:

set ns hostname

Note that the hostname value you define here is used for licensing for the NetScaler Gateway VPX model.

You should also change the default password, as nsroot is the default password for all NetScaler appliances. This can be done using the following CLI command:

set system user nsroot password

This can also be done through the GUI by navigating to System | User Administration | Users | nsroot | Choose Action and clicking on Change password.

After you are done with this setup, you also need to add our platform license to the appliance. This can be done through the GUI by navigating to System | Licenses. Here, just click on Add license and upload the license that was generated from www.mycitrix.com/.

After adding the license, you need to reboot the appliance. You can verify that the license is properly applied by checking under the Licenses tab or by using the CLI command show license, as this will list all the features that are licensed along with the model type, as shown in the following screenshot:

You can also see up in the top-left corner, which version of the VPX you are running from the number that is listed there.

Note that in the portal or CLI, if the model number ID is 1, it means that the license file has not been read correctly or the hostname allocation is wrong.

The last thing to do is to enable secure management of the NetScaler appliance, since by default, you can connect to it using telnet and regular HTTP, which is insecure. In order to set up secure access only, navigate to System | Network | IPs | Choose the NSIP and click on Edit. At the bottom, choose Secure Access Only and click on OK.

As we have discussed earlier, this IP address is used for management purposes in the local NetScaler, and it is used to authenticate against services such as AD, LDAP, and Radius. We need to make sure that the NSIP address is allowed to talk through the firewall.

By default, the NSIP address is allowed to be used for management services using several protocols, such as SSH, HTTP, and HTTPS. This is also the IP address we use to communicate with NetScaler using the NITRO API. We can restrict the security level to only allow secure access by navigating to System | Network | IPs | NSIP, and then choosing Secure Access. Remember that this requires that we import a trusted certificate, as by default, it uses a self-signed certificate. If we try to connect it with a browser when running a self-signed certificate, we will get browser warnings stating it cannot verify the publisher.

Next we have the MIP address, which is used for backend server connectivity. When we add an MIP address to a network, it automatically creates a route entry with its address as the gateway to reach that particular network.

The SNIP address is also used for backend server connectivity. When setting up a NetScaler appliance, the startup wizard requires you to enter an SNIP address. The SNIP address also creates a route entry with its address as the gateway to reach that particular network. The SNIP address is also used for connectivity against DNS/WINS servers. In order to use an SNIP address, the Use Subnet IP (USNIP) feature must be enabled.

The common feature of both these addresses is that they are used for proxy connections by users connecting to a service via a VIP address to a backend server. Most of the time, MIP was used to set up an address on the same subnet in which the NSIP was placed, and the SNIP address was used to contact backend servers, which were located on another subnet. But with the latest releases of NetScaler, there is no need to use the MIP address feature. Citrix also recommends using SNIP instead of MIP addresses.

When we want to add an SNIP or an MIP address to NetScaler, we can do this from the same pane where we saw the NSIP address, that is, by navigating to System | Network | IP addresses | Add. If we want, we can also use the following CLI command:

add ns ip 10.0.0.0 255.255.255.0 –type SNIP

We can change the type name depending on what we need. Valid parameters here are SNIP, VIP, MIP, and NSIP.

VIP is a virtual IP address. It represents a service or different services by an IP address, port, and a protocol, and depending on the configuration, it might be a load-balanced service. Clients connect to this IP address to access a service. We will have a detailed look at how the VIP address works in Chapter 2, NetScaler GatewayTM, and Chapter 3, Load Balancing.

Now, let us tie this together to understand the concept of how NetScaler processes traffic for a service. In this example, we have a web service running on a couple of web servers located on our intranet subnet 10.0.0.x. We want this service to be accessible to our external users by using NetScaler. We will place it in the DMZ with a two-arm topology, with one NIC in the intranet, and define the different IP addresses to be used. In this example, we set up an SNIP with the address as 10.0.0.2, which is used for server connectivity at the backend. Our users are placed on the Internet and will access the service using www.service1.company.com. This FQDN resolves into the VIP address on NetScaler, which is 80.80.80.80.

Remember that VIP is a virtual address, and in our example it is used to load balance the connection between the two web servers that are placed on the intranet, as shown in the following screenshot:

So, when a client connects to the VIP of NetScaler, it terminates the connection and establishes a connection with the backend web server using its SNIP client connection to the VIP address www.service1.company.com, as shown in the earlier example. The following table shows how the packets are routed:

From here, NetScaler establishes a connection to the backend server on behalf of the client requesting the content.

The return traffic goes in the same direction back to the client.

This is a simple overview of how the traffic flow may be with a load-balanced service. There are, of course, many factors here that decide how the traffic flows, and it is also dependent on how the network is configured.

One thing that is important to note is that the IP addresses are not associated with an interface as they are with a regular network appliance. They are active on all the interfaces, so NetScaler behaves more like a hub. This might be a problem in some cases, where TCP packets are sent and received on different interfaces, and it might cause a loop. This is where VLANs come in. We can associate an IP address with a VLAN, which we can again associate with an interface. First, we need to create a VLAN. This can be done through the GUI by navigating to Network | VLANs | Add. From here, we can enter an ID for the VLAN and give it an alias name. Then, we can bind an interface and an IP address to the VLAN. This allows an IP address to be bound to a specific virtual interface.

We can also do this via the CLI by using the following commands. First, we need to create the VLAN as follows:

add vlan 20 –aliasName "Network 1"

Next, we need to bind it to an interface:

bind vlan 2 -ifnum 1/8