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):
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:
; 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;18.104.22.168
; SSL only mode
; If set to on, only requests sent through HTTPS are accepted
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).
I wanted to change the login screen of a NetScaler CAG, but I didn’t know which files to change. Luckily my college from DigiPulse and member of the Dutch Citrix User Group (DUCUG) gave me the solution by pointing me to the following blog post.
Op verzoek van Edwin Houben hieronder een overzicht van aanpassingen die ik heb gedaan om de website van https://vpn.azlnet.nl te maken zoals hij nu is:
Design van de site is aan te passen in deze bestanden:
– /netscaler/ns_gui/vpn/index.html (taal aanpassingen)
– /netscaler/ns_gui/vpn/login.js (taal aanpassing gemaakt en custom error page)
– /netscaler/ns_gui/vpn/nsshare.js (layout aanpassingen voor "vakken")
– /netscaler/ns_gui/vpn/images/caxtonstyle.css (style codes)
Let er wel op dat als je de pagina’s aanpast dat deze na een reboot weer terug gezet worden naar de oude (fabrieksinstellingen), dit kun je voorkomen door de volgende instructie aan te houden:
Copieer de aangepaste documenten naar /var/vpn/custom/vpn/ (ook de images directory als je eventueel nieuwe plaatjes hebt toegevoegd) en as het script /flash/nsconfig/rc.netscaler aan door onderstaand commando toe te voegen:- cp /var/vpn/custom/vpn/*.html /netscaler/ns_gui/vpn/
– cp /var/vpn/custom/vpn/images/* /netscaler/ns_gui/vpn/images
Hierdoor worden je wijzigingen wel meegenomen bij een reboot.
Mijn excuses voor de korte uitleg, als ik ooit tijd heb maak ik een nieuwe handleiding voor zowel de 8.1 als de 9.0 netscalers.
Mochten jullie toch nog vragen of problemen hebben plaats ze hier of mail me op email@example.com
It has been a while since my last post, but time is short these days.
Today I had to troubleshoot a Microsoft IAG appliance. Microsoft IAG stands for Microsoft Intelligent Application Gateway. And indeed, intelligent it is. NOT. I have seen and configured multiple SSL VPN solutions like Juniper SA, Citrix Access Gateway, Citrix Secure Gateway and Cisco WebVPN. But to be honest, Microsoft IAG is the worst of all.
Microsoft IAG is installed on an appliance and is closely related to Microsoft ISA 2006, which is also installed on the server. Whenever you make some configuration changes to IAG, you have to active the new configuration inside IAG. After activating the configuration, I looked at the new ISA firewall policies and I really couldn’t believe my eyes. IAG configured ISA automatically, when activating the configuration.
A simple portal, where 2 websites and OWA are published and a network connect (SSL IP VPN), results in approximately 10 firewall policy rules in ISA. Okay, I could live with that, but I shivered while taking a closer look at the rules. It is not easy to discover what purpose a specific rule has, without looking to the different tabs while editing the rule.
Besides the crazy management of the appliance, me and a colleague had a lot of problems when testing the appliance. Currently the network connector is not supported on Windows Vista and you receive a lot of (useless) errors when using Internet Explorer 8. The logging functionality is also very basic and hard to find. I had problems with configuring and testing the network connector with the non-split tunneling and disable local area network access option, I couldn’t find any useful logging about the problem. For some reason only specific traffic is routed into the VPN tunnel. I ended up configuring split-tunneling and only route specific network segments into the SSL VPN tunnel.
My opinion till now, Microsoft IAG cannot be compared with other SSL VPN appliances I have seen. I guess Microsoft IAG could test positive when using the appliance in a solely Windows environment, where only Windows services, like OWA and SharePoint, are published to the internet.
Maybe the solution is a lot cheaper compared with the Juniper and Citrix solution, but for know I would rather buy a Cisco ASA 5505 or Cisco ASA 5510. I would definitely not configure the Microsoft IAG as a cooperate firewall terminating the Internet connection.
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.
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.
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|