Virtual IP addressing in Citrix Presentation Server 4.0

by Rich Brumpton [Published on 1 Nov. 2006 / Last Updated on 1 Nov. 2006]

This article will explore the use of Virtual IP addressing in the Citrix Presentation Server 4.0 environment including how to assign virtual IP addresses for network communication and licensing compliance.

Virtual IP’s?

We have all encountered virtualization of some kind by this point including virtual machines, virtualized storage and even virtualized applications. Citrix Presentation Server 4.0 in the Advanced and Enterprise editions includes a feature known as Virtual IP addressing that can be used to provide users with a unique IP address for communicating with network resources for applications that do not allow multiple connections or users from the same IP address. In addition Virtual IP addressing can be used to provide applications that communicate between components with a private loopback address or even report the client IP address to the application for licensing purposes.

Uses of VIP

Compatibility

Virtual IP addresses allow some applications that have not been possible to run on Presentation Server the chance to be centralized and managed like other applications in a Server Based Computing environment. In particular applications that authenticate users using the IP as part of the user access token are problematic.

FileNet, who were recently acquired by IBM, produce a product called Content Manager which is a document management system that has been the poster child for virtual IP addresses. This application has a backend database that stores all of the documents that authenticates users based on their username, password, and IP address. This means that even though it will install and run perfectly for a single user on a Presentation Server, it will only allow one user to connect to a given database from that server. Unless you have enough money to throw a machine (or VM) at each user this has meant that FileNet Content Manager was simply not a good fit for Presentation Server.

With Virtual IP addresses this is no longer a problem as you can have each user that runs the program use a unique IP address from a pool to contact the server and the application works as expected. Other applications in the same session will continue to use the server IP unless they are also configured to use the virtual address.

Licensing Compliance

There are also some products out there that license a user based upon their IP address in a database or check out licenses to IP addresses. Virtual IP Addressing can either provide a real IP address to the user session or “fake-out” the application on the Presentation Server so that it thinks it is using the client workstation IP address.

Auditing

Administrators in high security environments have long been required to audit activities and some have asked for the ability to determine who accessed particular resources on the backend. With virtual IP addressing the checkout process can be logged, which shows the IP address assigned to a particular session on a server as well as the user that is using the session. This allows reconciliation of these events with access logs from databases or other servers that need to be stringently monitored.

Secure communication between processes

While we will not be discussing it in this article, the Virtual Loopback allows the assignment of a unique loopback address for each session on a server which allows applications that assume the loopback address is private to the user to function as expected and avoid interacting with components from another user session.

Testing of VIP

Now for the fun part! We are going to walk through setting up and testing Virtual IP addresses and get down into the details of how they work and how to use them.

For this purpose I will be using three tools.

Setting up VIP

To set up virtual IP addresses you need to follow 3 simple steps:

  1. Create a pool of IP addresses
  2. Add servers to this pool of addresses
  3. Specify processes that trigger the use of the virtual IP addresses

Step 1

This is one of the hardest to communicate with the network team on so be sure to talk with them about the need for a pool of addresses and the fact that Citrix uses a completely different definition for Virtual IP than they are used to. Network infrastructure folks are used to using a Virtual IP for load balancing where we have multiple servers behind a single IP address. We are flipping this around and assigning many IP addresses to a single server. It can also be difficult to get sufficient numbers of IP addresses when IP space for the servers is limited. In the event that you have a class C subnet mask you only have 253 available IP’s for servers and virtual IP addresses. It is recommended that you talk with your networking team about putting the servers on a segment with a broader subnet mask or use multiple logical IP networks on the same or multiple network adapters.

It is also very important for Step 1 to ensure that you have enough IP addresses. Every session on a server with Virtual IP addresses enabled requires a virtual IP address. This is because they are assigned at executable launch and not at session launch. Because of this handling you will need to plan ahead for your maximum total load on the servers that use Virtual IP addresses and it might be a good idea to silo them out.

Once we have our IP pool we can configure the addresses in the Presentation Server console. Open properties on the farm node and go to the Virtual IP Address Configuration tab to do this.


Figure 1

Once on this tab select Add IP Range and add in the range of IP addresses that are to be used.


Figure 2

Once you have entered the IP address range you can move on to step 2 by selecting yes or get there later by selecting the Add IP Range…?

Step 2

Select Add to add servers to the IP range and then move the server to use this virtual IP range over to the right hand side and hit OK.


Figure 3

Once they are added, note that count can be overridden and that by default the servers are assigned an even distribution based on the number of enabled network interfaces they have. This number should be sufficient for ALL Sessions on the server, not just those that require a Virtual IP. This has confused enough administrators to warrant the article CTX109207.


Figure 4

Once the server(s) have been assigned to the pool(s) that they will use they must be rebooted so that the virtual IP addresses can be accessible by Winsock. During testing and perhaps during production, logging can also be enabled to audit the assignment and release of the IP addresses. Below there are three pools. This is to illustrate that a server can be assigned to multiple pools and that users will be assigned addresses in sequence across all pools that are within any subnets configured on the server. 


Figure 5

Before the reboot an IPCONFIG looks like this:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : education.ctxs
IP Address. . . . . . . . . . . . : 192.168.1.11
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.254

After the reboot it looks like this:

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : education.ctxs
IP Address. . . . . . . . . . . . : 192.168.1.155
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.154
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.153
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.152
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.151
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.140
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.139
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.138
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.137
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.136
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.135
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.134
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.133
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.132
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.131
Subnet Mask . . . . . . . . . . . : 255.255.255.0
IP Address. . . . . . . . . . . . : 192.168.1.11
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.254

Despite these results in the IPCONFIG command, examining the network adapter TCP/IP properties shows that only one address is actually configured for this adapter. The other addresses are only used inside ICA sessions.


Figure 6

Even though there are three pools of addresses one of them is on a subnet for which there is not an address on the server. The 192.168.1.0/24 network is accessible but the 192.168.0.0/24 network is not so we received a 1223 error in the system log that indicates the problem. If this subnet was configured by using a second IP address in the adapter configuration or on a second network adapter then this pool would also be available.


Figure 7

Every Session will have a 1221 event for the assignment of an IP address and a 1222 event for the release at the end, note that the user and session ID have been logged also which could lead to interesting auditing possibilities. Unfortunately the Resource Manager summary database does not trace these yet so some method of combining the logs would have to be performed. Microsoft Operations Manager could be of help here. It would be nice to see an entry in the Resource Manager SDB_Session table for the Virtual IP and Virtual Loopback addresses as well as perhaps flags in the SDB_Process table to denote wither they were used for a process or not.


Figure 8

Step 3

The final step is to add the list of processes that will trigger the use of virtual IP addresses. This is done on the farm properties, Virtual IP Processes Tab. Just select Add Process… and then enter the name of the process to use a virtual IP. Remember that these will be the only processes to use a virtual IP address and they will only be assigned for ICA sessions, not RDP or console sessions. It is also interesting to note that process list changes take effect immediately and will work for the next launch of the application. No reboot or new session creation is needed.


Figure 9

Once Virtual IP Addressing has been configured for a farm it can also be managed on a server by server basis.


Figure 10

In this example Get IP is using a virtual IP address but the telnet session is not. Both of these applications are sharing the same session.


Figure 11

After adding telnet.exe to virtual IP processes and hitting OK, it does use it on the next telnet.exe launch within the same session.


Figure 12

When users connect to the server the virtual IP addresses are assigned in order. Note that the four sessions below have consecutive numbers. Of course once the system has been in operation for a while there will be some fragmentation of assignment as addresses are freed up out of order.


Figure 13

Alternate use of VIP

An alternate use of the Virtual IP Addressing feature can be found at http://support.citrix.com/article/CTX107574 which describes using virtual IP address features to allow applications that use the Winsock GetHostByName method to retrieve the client IP address from the ICA session instead of the server IP address. This is intended to allow license compliance and/or confirmation that a user is connected from the correct workstation to access an application. This does require manual configuration of the registry on each server but it does not conflict with virtual IP unless both are needed by the same process.

Below is an example of three network applications in a single session reporting 3 IP addresses… my head hurts…


Figure 14

Virtual IP addressing can solve a variety of issues ranging from compatibility problems to license compliance to security auditing and can be a valuable tool in the belt of any Presentation Server administrator.

See Also


The Author — Rich Brumpton

Rich Brumpton is a Senior Systems Consultant with MTM Technologies, Inc and is based in St. Louis, MO. He is a Citrix Certified Instructor as well as a field engineer that has been invited by Citrix to sit on the Partner Technical Expert Council. In addition to his instructor credentials Rich also holds a MCSE and CCIA along with a smattering of other certifications.