issues with RDS virtual IPs

We run Cisco Ironports to monitor internet usage and block websites to certain staff etc. When authentication is enabled with the Ironports, and you are using Internet Explorer; Internet Explorer will silently authenticate using the current users credentials against the Ironport device. The Ironport will then save the IP address of the Computer using Internet Explorer, and assume all internet requests from that IP are coming from the user that originally authenticated.

This presents a problem in Citrix XenApp, as multiple users may be using the one server, which only has one IP address. If the first user to log onto the XenApp Server is a company director with full internet access, the Ironport will grant all subsequent users that log onto the server the same internet access. Hey all the traffic is from the same IP!

To get around this issue the Ironports offer a different method than using an IP address for remembering internet access, using a session cookie. From within Identities, under Authentication in the Ironports you can create an Identity, provide a list of IP addresses (your XenApp servers) and set the surrogate type to Session Cookie. From now on, when users try to access websites from servers that have an IP in the identity created above, Internet Explorer will be given a cookie for each website the user visits. Ironports will now refer to the session cookie rather than the IP address of the server for access.

Now internet monitoring and website blocking will work for users on RDS and Citrix XenApp servers!

Well… it’s not all rainbows and unicorns…

Session cookie based authentication is… well… shithouse. It’s terrible and I have no idea why they even offer it as a solution it’s so woefully inadequate. Here are some of the issues we have encountered:

1. Applications that require Internet Access, and don’t know how to handle a proxy asking for authentication… don’t work
   • As now the Ironports authenticate you on a site by site basis, if you are running an application that requires an external resource, the ironport will ask the application for credentials, as most applications don’t know how to handle these credential requests, they usually complain that they can’t access the internet.
   • If you were using IP based authentication then once the Ironport knows you are using a certain IP, it won’t bug you for credentials for some time. This allows applications that require internet access to work!
   • You could also set the websites to require no authentication to get around the issue, but do you really want to figure out the URLs of each website
2. Websites with urls with less than 3 characters in before the domain (such as t.co) just don’t work at all unless you want to also put them into your no authentication website list.
3. Websites that have dynamic content that pull from other locations will fail to work.
4. Sometimes websites won’t work until you have the user clear their cookies.

What has this got to do with Virtual IPs?

Well, if we could somehow give each Citrix User a unique IP, the issues above would go away! By enabling Virtual IPs on your RDS server each user will get their own unique IP address. People on Cisco forums also recommend enabling Virtual IPs to get around the issues stated above (although I seem to be unable to find official documentation on it).

So it should just be as simple as getting an IP range from your network guys and enable Virtual IPs right? Well… you would think so!

Enabling Virtual IPs

There are good resources on this already out there, I followed the following articles:

netsh winsock reset

IP Virtualization fails on Servers provisioned in VMWare ESX/ESXi

Sessions with Virtual IPs cannot LDAP

Group Policy fails to apply when Virtual IPs are enabled

Cannot shadow users with Microsoft Remote Assistance Tool on servers with Virtual IPs enabled

I could not find anything on the internet about this, so I created a technet forum post about it here. In the end the issue is: if you don’t have an administrative user logged onto the servers console session, you will not be able to shadow users on that server.

I contacted Microsoft Support about this issue, they worked on it for a few weeks before contacting me saying this is “by design”. I have requested Microsoft update their documentation and create a KB article to reflect this issue. I have not heard back yet but I will keep you posted.

I was still having difficulty with shadowing staff, in the end I created the following registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\TSAppSrvVirtualIPPerSessionraserver.exe

It just has to be an empty key, seemed to fix the issue for me. I found that RAServer.exe was looking for this key when I ran procmon. I created the key and the issue went away!

Conclusion