ICA connects with Windows XP but not with Vista

I have been diggind around for a solution to this but have not found one that sticks as of yet.  
I have recently changed laptops to a machine running Vista Ultimate.  I am attempting to connect to a Citrix server running Presentation Server 4.0 with the latest hotfix rollup package on a Server 2003.  Currently, we conect via straight custom ICA connection without using the web interface.  I know I need to upgrade both the version and the connection method, but for a small firm with proprietary software I have to move somewhat slowly with upgrades and everyone but me is having no issues.

With both laptops side by side on my home network, the XP machine connects fine and the Vista machine gives me the errror that there is no Citrix server at the specified address.  I have listed both the IP address of the virtual IP on the firewall and the FQDN address in my trusted sites in IE7 and given booth ICA.32 and pn.exe full access on my Mcafee firewall.  This made it work for a couple of days but now I am getting the error again.  

Any thoughts?
Who is Participating?
Also, I guess you could try disabling the local firewall altogether...
Did you return to the office in that few days before it stopped working again?  I'm wondering if a group policy update reset your local firewall settings, or perhaps a McAfee update?

I'm slightly unclear - you say you are using a custom ICA connection, but then mention IE settings.  If Web Interface isn't in the mix, why bother with IE?
warpstreamAuthor Commented:
I did not go into that office between the time it was working and now.  My machine is not part of their Windows domain since I am an outside IT consultant for this office.

I agree that it seems strange that I did the steps with IE.  The reason is that in my research into this issue, it was one of the items referenced in possible solutions.  The default setting for a custom ICA connection is to use TCP+HTTP so I thought it might be using the security settings from IE.  The even stranger thing is that when I made the changes to the settings in IE the ICA connection started working.

In my tests I did change the protocol to just TCP/IP but the connection is still not made.

Another note, I am able to connect with ICA to another office I work with.  The only difference is that they are using Presentation server 4.5
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

The reference to TCP+HTTP is how the ICA client locates the server farm.  By default, the ICA client wants to resolve 'ICA' to an IP address.  If it can, it then uses a random source port to connect to destination port 80 on that IP address.  Thats where the HTTP bit comes from.  You can tell the client to skip the ICA name resolution and specifiy an IP address instead.

The client is actually connecting to the servers XML service, which is listening on port 80.  The server then responds with the IP address of the least busy server in the farm.  At that stage, the client tries to connect to this server on port 1494, or 2598 if session reliability is enabled.  It does this in order to authenticate the user and enumerate applications.

If you hadn't seen the connection work for a few days, I would suggest that perhaps the client wasn't able to resolve ICA, but that clearly isn't the problem.  Presume you have an IP address configured within your custom connection?

I'm wondering about the communication process between your machine and the internal network.  Has the firewall been opened to allow this direct ICA connection to work?  In that case, there may be NAT in the equation, and unless the server is configured to return an alternate (the NAT'ed address), then the connection will fail as the server will return an internal IP address.  However, if one server had been configured in this way, and not another then you could have the problem you see.  Could you possibly give me some more detail about the communications process - how is the connection made, how exactly is your client configured etc?
warpstreamAuthor Commented:
I do have an actual address associated with the ICA connection.  The firewall at the office is configuured to allow and redirect the Citrix protocols.  There is only one Citrix server on that network.  The strange thing is that my XP laptop can connect just fine.  My XP desktop can connect just fine.  My Vista laptop does not.  As far as the two laptops are concerned the network that I am on has not changed anything.  I have tested both machines from three separate internal networks as well as with my aircard.  The result is the same.  The XP latop connects and the Vista does not.  

The other 3 people in the office who also connect to the Citrix server are doing so with no issues.

The connnection properties are the same for both of my machines:

IP address specified
Data Compression
Diske Cache

The two differences are thee operating systme an the XP is using ICA 9.15 while the Vista is using 10.2.  I am hessistant to upgrade the XP to 10.2 since I need this connection in order to provide support.

Also, keep in mind that the ICA connection I have on the Vista machine that connects to a different office running Presentation Server workks fine.  The difference between these two offices is that the non-working office is running Presentation Server 4.0 and the working office is running Presentation Server 4.5.  The connection settings for this connection are the same as the non-working conection (exept for the IP adress of course)
Ok - the ICA client version isn't a factor.  Nor is whether it's PS4.0 or 4.5 - there is no difference in the connection mechanism, and other clients can connect to the server without an issue.  Likewise, your Vista client can connect to a different server without a problem.  ICA 10 has been designed with Vista's enhanced security in mind, so there should be no problem there.

I think we need to go back to first principles to troubleshoot this problem, and check connectivity.  Can you have a look at the following:

When you launch your custom connection, use Netstat -an to check the active connection and port - does this look correct?  

In your ICA connection, are you connecting tdirectly to a server, or to a published application?  If a server, can you telnet to the IP address on port 1494? (you should see ICA..ICA...ICA)
Is session reliability enabled?  If so, can you telnet on 2598? (no message)

If a published application, can you telnet to the IP address specified under the server location on port 80? (no message)
Also, if you're currently using a published app, is it possible to try configuring the connection to connect directly to the server instead?  Note that by default, only admins can connect directly to a server, unless you change the properties of the ICA listener to uncheck 'only launch published applications'.

If any of these tests fail, there is clearly a problem with connectivity - either at the client firewall, or at the corporate firewall.  You may think 'it cant be a comms problem because it works for other machines', but if one is trying to connect over 1494, and the other over 2598, then its possible you would have this type of issue.  You have your local firewall logs, but are you able to work with your client to see if they can review the firewall logs for you?
warpstreamAuthor Commented:
Sorry for taking so long to get back to this.  I have been slammed.
Checking with netstat -an I see the vista machine I see port 1494 syn_sent but I do not see established.
On the XP machine I do see established.
Session reliability is enabled but neither machine is trying to establish the connection using that port
With my connection I am talking directly to a server.

I agree it is a communication problem but if the everything is the same accross the board for mutiple machines and only one maching is having issues (which is the only machine runing Vista), doesn't that point to the comms problem being with that machine?

Unfortuanatley the logs from the office firewall are not very verbose since they are using an older Netscreen box.  It shows that there are successful ICA connections but does not show unsuccesfull attempts.  The successful connections are just shown as a time and duration of connection.

To almost argue with myself, I did take the XP laptop into the local office network and was able to connect to the Citrix server when I was inside.  

Yep - agree it sounds like a local client connectivity issue, but that is why I suggsted looking at the firewall logs.  Thought maybe you would see unsuccessful connections and the rule that matched it.  

Just to clarify - "To almost argue with myself, I did take the XP laptop into the local office network and was able to connect to the Citrix server when I was inside."  
-Do you mean the Vista laptop?
warpstreamAuthor Commented:
You are correct.  I did mean the Vista laptop.  Are there areas with Vista that I should be checking?  
With Vista, Microsoft in thier wisdon changed the way that dial up networking worked.  Instead of having the default gateway set as the remote gateway, its now set as (you should see this if you do an Ipconfig).  Although MS say that this doesn't affect the behaviour of the connection, it apparently does with certain types of interface, such as the AirCard.  Have you any other means of connecting to the internet that you could try? e.g. ADSL router.
warpstreamAuthor Commented:
OK... Sorry for the long delay in responding to this.  I had been working on it and found the solution.  I recently replaced the firewall and it immediately started working.  I think the old firewall was not able to handle the Vista tunneling traffic correctly.  Everything is working correctly now.
warpstreamAuthor Commented:
The issue did turn out to be ther firewall.  Once replaced with a new one, everything works!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.