Connecting the world…

citrix

Citrix Secure Gateway via https-only

Configuring a Citrix Secure Gateway (CSG) server is simple, but provides a powerful solution to access resource from remote locations. CSG is an application installed on a DMZ server. Mostly I also configure the Citrix WebInterface on the same server. The CSG instance listens on TCP/443 and the WI instance listens on TCP/80. To improve the user friendliness of the solution you have to configure a redirect. This redirect changes the protocol from the unsecure http protocol to the secure https protocol. It also redirect the user to the correct login portal, like redirecting http://portal.booches.nl to https://portal.booches.nl/Citrix/XenApp/auth/login.aspx. The HTML code for the redirect is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Refresh" content="1 ;URL=https://portal.booches.nl/Citrix/XenApp/auth/login.aspx" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>Citrix Secure Gateway-Booches</title>
</head>
<body>  
<p>
        Please click <a href=’https://portal.booches.nl/Citrix/XenApp/auth/login.aspx’>here</a> if you are not automatically redirected.
</p>
</body>
</html>

This configuration requires you to allow the http and https protocols from the internet to the server. When accessing the login page the remote user connects to the CSG instance over https and the CSG instance connects to the WI instance over http. A customer noticed that a user could change the login URL from https to the unsecure http. This means that the remote user connects directly to the WI instance and bypasses the CSG instance. This behavior is not allowed and also unsecure, because username and password are sent clear text over the internet.

I wanted to change this behavior so the user isn’t allowed to connect over http to the login page, but the default redirect from http to https should still be allowed. I looked at solutions on the internet to redirect all IIS traffic from http to https, but this introduced some problems and errors. In the end I simply configured IP Address and Domain Restriction on the /Citrix/XenApp virtual directory. Only the CSG instance needs to connect to the WI instance, so the IP restrictions only allow the localhost and the server IP address. I also changed the default behavior to deny all unspecified clients.

csg-wi-ip

PacketShaper Traffic Discovery and Citrix Session Reliability

While troubleshooting some performance issues with Citrix sessions between headquarters and sub locations, I decided to take a closer look at the PacketShaper. The PacketShaper is positioned at the headquarter and does outbound shaping to the sub locations. The PacketShaper is using older software (7.2x), which isn’t necessarily a problem.

I deleted the class for a specific location, created the class again and enabled traffic discovery for that class to check which protocols are used by the sub location.

Traffic Discovery: The PacketWise process of observing and creating traffic classes for all packets as they pass through the unit. This process compiles a list of the protocols and applications in use on a network, creating a traffic tree.

Traffic Discovery is working perfectly, because I see different protocols popping up under the sub locations class under which Citrix. In the past PacketShaper had the opportunity to discover the Published Applications or priority bit tagging used with Citrix. This gave you the opportunity to configure shaping parameters per published application.

Nowadays a lot of Citrix customers use Session Reliability. A major drawback of Session Reliability, in conjunction with a PacketShaper, is the encryption of the data stream. The encryption of the data stream prevents the PacketShaper from discovering the published applications or the priority bit tagging.

I first checked if this problem is solved by the latest software release (8.5 at the time of writing), but it isn’t. BlueCoat acknowledges the problem and describes it in this article. The article contains a link to another article about Manage Citrix Performance, which can be useful when using Citrix without Session Reliability.

Disabling Session Reliability isn’t an option for my troubleshooting, so I guess I have to find another way to troubleshoot the performance issues.

Citrix Access Gateway: duplicate STA ID

I received complains from a customers who wasn’t able to add two new Citrix servers to his Citrix Access Gateway configuration. He could successfully add the first Citrix server, but he couldn’t add the second Citrix server, because the first was overwritten by the second. I looked at the problem and noticed that both Citrix server were using the same STA Identifier.

After asking some question about the installation of the Citrix server, I discovered that the second Citrix server was a clone of the fist Citrix server. That is why both servers have the same STA Identifier. The STA ID from a Citrix server can be changed by altering the file CtxSta.config. By default a Citrix server has two CtxSta.config files, located at the following destinations (default installation):

  • C:\Program Files\Citrix\System32;
  • C:\Inetpub\Scripts;

I had to change the STA ID in the C:\Inetpub\Scripts directory, because IIS was used to share port 80 on the server. The CtxSta.config file contains a UID, like the example below:

[GlobalConfig]

UID=STAA3D2D2970C9C

TicketVersion=10

TicketTimeout=100000

MaxTickets=100000

LogLevel=0

MaxLogCount=10

MaxLogSize=20

LogDir=c:\inetpub\Scripts\

; Allowed Client IP addresses
; To change, substitute * with client IP addresses. Use ";" to seperate IP addresses/address ranges.
; To specify a range of IPs always use StartIP-EndIP.
; For example, AllowedClientIPList=192.168.1.1;10.8.1.12-10.8.1.18;123.1.2.3

AllowedClientIPList=*

; SSL only mode
; If set to on, only requests sent through HTTPS are accepted
SSLOnly=off

I changed the UID on the second server and restarted IIS. I tried to add the Citrix server to the Citrix Access Gateway, which is now possible with the new unique STA ID. The last step is adding the second Citrix server to the Citrix WebInterface (server farm & STA ID).

Citrix Terminal Server License Server problem

One of our customers is using a Citrix NetScaler appliance for SSL VPN capabilities for remote users. I tried to start an application (RDP Client) through this SSL VPN solution, but I couldn’t succeed. I was able to login and I would see all the published applications, but when executing one, I received the following error message:

The remote session was disconnected because there are no Terminal Server License Servers available to provide a license. Please contact the server administrator.

So I did contact customers system engineers, because I thought the problem was related to the customers Terminal Server License Server environment. I thought this, because I was still able to use SSL VPN solutions from other customers. They couldn’t find any solution for my problem and that’s correct.

The solution for the problem is found on my own laptop. I stumbled upon this TechNet article. I opened my registry and deleted the following folder and subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE000

This did the trick. I was able to execute the published applications again without any problem after rebooting my laptop.

Microsoft Outlook through Citrix Access Gateway SSL IP VPN

One of our customers wants you use their locally installed Microsoft Outlook through a Citrix Access Gateway (CAG). Sales people from that customer travel through the country and use the Outlook offline to read or prepare e-mail to send later. These people use UMTS technology to connect their laptops to the Internet. The customers wants these sales people to have the ability to use their Outlook offline and actually send/receive mail when connected to a network with Internet access.

The customer is using CAG’s to publish multiple services to the Internet, so together with my colleague Edwin Houben from DigiPulse, we started to look at a suitable solution. The CAG is located behind a CheckPoint firewall and traffic to the internal network needs to go through an ISA server firewall.

First we started to look at the ports Microsoft Outlook uses to connect to the Exchange server. Looking at the settings from a laptop, the connection is made by FQDN of the Exchange server. While performing a netstat -na we noticed that Outlook uses two ports to connect to the Exchange server.

PORT DESCRIPTION
TCP/135 EPMAP
TCP/1536 AMPR-INTER

The Outlook clients connects to the Exchange server on FQDN. So the laptop needs to have an IP connection to the Exchange server. So we decided to use the Citrix Secure Access Client to give the user the ability to establish an secure IP connection to the network.

Looking at the customers network, we had to configure access-lists on two locations to make the solution more secure. The first location is a Network Resource in the CAG. The Network Resource enables only the above ports to the Exchange server IP address. The second location is allowing the IP address of the CAG to connect to the Exchange server on the above port numbers through the ISA server.

After configuring both access-list, we did some testing and the solution works perfectly. You can now use the laptop on the internal network and externally with the Citrix Secure Access Client without making any changes in the Outlook configuration.

Later, the customer noticed that he couldn’t use Microsoft Outlook anymore in conjunction with the Citrix Secure Access Client. After digging a bit deeper in the traffic flow between Microsoft Outlook and the Exchange server, I noticed that, beside TCP/135, random ports above 1024 are used. So I changed the Network Resource  and the ISA servers to allow TCP/135 and the range TCP/1024-2000. I haven’t used the complete range of registered port numbers, so I hope Exchange doesn’t use a port above TCP/2000.

FUNNY ADD-ON

I didn’t some Googleing (or Googling or whatever) on TCP port 135 and I found some “funny” things:

Some well known Root kits also use this port to transmit data back to home base and download more malware. I also suspect may be an entry point for some root kit /malware for un patched systems or systems that did not patch correctly. Source 

Currently inbound scans are likely the Nachi or MSBlast worms. Source

The problem with port TCP 135 is that it is used for multiple services, which are listed below. So blocking port TCP 135 could affect communication between devices or the usage of services.

 

Client/Server Communication DCOM DHCP Manager
Exchange Administrator Microsoft Message Queue Server RPC User Manager
RPC Service Manager RPC Port Mapper SCM used by DCOM
SQL Session Mapper WINS Manager