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