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"
<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>
Please click <a href=’https://portal.booches.nl/Citrix/XenApp/auth/login.aspx’>here</a> if you are not automatically redirected.
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.
Last week I have installed a Microsoft UAG array. I installed Microsoft ForeFront Unified Access Gateway 2010 including Service Pack 1. When using an array configuration you have to deploy Microsoft’s Network Load Balancing (NLB) for redundancy and load balancing purposes. I configured NLB with multicast and IGMP support. I had configured some HTTPS trunks and some HTTP trunks for http-to-https redirection.
Everything was working perfectly and I decided to install the update KB2585140 (ForeFront UAG SP1 Update 1). The main reason for installation was the introduction of SharePoint 2010 with Office Web Apps and Lync web services publishing.
The installation process was easy and completed without any errors. I noticed that after installing the update I couldn’t activate any configuration changes. Everything I hit Activate I receive the following error message:
The Activation works again by deleting all HTTP trunks and only use HTTPS trunks. The customer started a support call with Microsoft and Microsoft acknowledges this behavior when installing the update on an array configuration. At first Microsoft advised to “break” the array and use a stand-alone server deployment. If that isn’t an option we should uninstall the update. We are told that the current configuration will get to the configuration state prior to the installation.
This morning the customer received another e-mail from Microsoft stating at more and more calls were logged with the same issues. The issues now has the highest priority for the Microsoft UAG developers. Microsoft couldn’t tell when the issue will be fixed, but I guess very soon.
So when using a Microsoft UAG array configuration DON’T install Microsoft UAG SP1 Update-1.
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;220.127.116.11
; 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).
My colleague over at PBSPlaza wrote a nice article about enabling squid on eSafe Gateway 7.1 Forwarding Proxy. Today I had to configure an extra step to enable squid. I followed the instructions from my colleague, but when I tried to start squid I received the following error message.
FATAL: Could not determine fully qualified hostname. Please set ‘visible_hostname’
Squid Cache (Version 2.6.STABLE18): Terminated abnormally.
CPU Usage: 0.030 seconds = 0.000 user + 0.030 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 244
I added the following line to /opt/eproxy/etc/squid.conf:
Now squid starts perfectly
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.