Two Port ICA

When a Citrix ICA client connects to a Citrix Presentation Server, it either uses TCP/IP port 2598 or port 1494. Port 2598 is used with session reliability and internally it uses SSL with the Citrix CGP protocol. The communication over port 2598 is like a private network link for a small selection of information related to Citrix.

The idea had its original invocation as part of the Secure Gateway project and the Nylon protocol. I briefly worked with Nylon around 2003 while working with the client piece of SG and learned of the bigger project to support Citrix Gateway Protocol (CGP) for standard client connections. Obviously port 2598 is more advanced since it allows for secure communication over SSL and it also has the ability to maintain sessions when the SSL link fails. This is
achieved by using a having a modified version of Apache on the Citrix Presentation Server (XenApp now) that accepts the connections for port 2598. This, in turn, is changed into a connection to port 1494 on the same system. To the user, it transparently works. Internally there is a change-over between 2598 and 1494. The Apache piece acts as a relay and also a point of allowing the session to continue.

Normally on terminal services sessions once the connection is dropped, the session is deemed as being disconnected. This causes a lot of churn and makes it hard to reconnect too quickly. However, since the Apache piece can hold up the connection to 1494 regardless of what the outside link is doing, the session does not need to be disconnected. This makes it much easier to re-establish a link from outside back to port 1494. From a user point of view, there is a good chance that a short term outage will not even be noticed except for the case of input feedback. There was a time in the past that any hiccup would trigger an instant drop of the client with the need for a full reconnect. Even with Auto Client Reconnect (ACR) this was not always a very pleasant experience.

This leads us to port 1494. If you select to drop session reliability it really means that you are bypassing the middleman. There is a good reason to have the middle management but sometimes it is nice just to go straight to the source. Port 1494 is the original design. The history of it I have already told before but let’s go down memory lane.

While working on the TCP/IP option for WinView, I realized that Citrix was going to need a server port number. Initially I would have picked just some semi-random number to test with. Eventually I determined that there was a central authority for giving out such numbers (IANA). This would have been 1994 and still fairly early on this list of supported ports. I asked John Richardson to get us a number from that group. John already had done this before or had some kind of connection with the group. I don’t remember which it is. Within a fairly short time, we had a port number reserved for us and we were told that we could use port 1494.

During the whole time I’ve known about port 1494, I usually remember it as Columbus+2. Of course I don’t have trouble remembering 1494 anymore since it is now ingrained in my memory from being referred to so many times.

Recently a co-worker, Jonathan, sent me a link for all the TCP and UDP ports in use. ICA is listed here at 1494 officially and 2598 unofficially.

There is an old trick to see if a Citrix Presentation Server is listening. Just issue a “telnet [servername] 1494”.  Of course replace [servername] with either an IP address or the DNS name for the server.  If you get a couple of “ICA” strings back, you know it is working (at least at the connection level).  I’ve used this trick a number of times when debugging issues.  Of course it works with PortICA as well but only if you are lucky enough to have an internal standalone version that is always listening.  By default PortICA only listens when a user is coming in through XenDesktop.

In the history of ICA, it used to be much more important to support other protocols besides TCP/IP.  In fact TCP/IP was a relative latecomer.  The other protocols such as IPX/SPX, NetBeui, and even Async have essentially faded away.  It would not have been easy to predict how strong TCP/IP would be circa 1990.  It would be interesting to see if any other protocol (besides derivatives of TCP/IP) will become stronger.   Remember how the 7-layer OSI was supposed to replace TCP/IP?  I still remember my instructors at school professing that TCP/IP was a dead end and that OSI was the way to go.  I guess the real world is not always as practical.

One last interesting point about how the server receives the connection.  Ever since 1997 when Citrix sold Multi-Win to Microsoft, the actual socket is accepted by a Microsoft device driver.  The driver is configured to listen on different ports based on how the server has RDP and/or ICA.  2008 will see the first Citrix device driver in PortICA to accept connections.  This was necessary since PortICA does not use Terminal Services and needs to implement the entire kernel stack to drive ICA.

About Jeff Muir

Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide