Connecting the world…

sa

Microsoft IAG

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.

Juniper SA publish custom ICA

I have deployed more Juniper SA 2000 appliance and in overall I am pleased with the working of the appliance. Sometimes we have minor problems when publishing ICA sessions through the appliance.

My colleagues have customers with connection problems, where suddenly the ICA sessions get disconnected and we cannot find the cause of these disconnects. Load balancing through the SA is also “hard” to configure. You have to define a custom ICA file and add the correct parameters for load balancing the sessions. In our opinion the Juniper SA appliance is a decent SSL VPN appliance, but not suitable for native Citrix environments. In native Citrix environments we prefer Citrix Secure Gateway or Citrix Access Gateway.

Now I recently noticed something strange with the Juniper SA. I am publishing a ICA session with a custom ICA file. The firmware of the Juniper is 5.5R2.1. Now I noticed that it isn’t possible to connect from a Windows 2003 server. When trying to connect you will receive the following error message:

I/O error

I checked the compatible platforms for Secure Terminal Access and Terminal Services for the 5.5 firmware and yes……Windows 2003 server isn’t supported!!!

Looking at the compatible platform for the latest firmware (6.2) Windows 2003 is supported for Secure Terminal Access and Terminal Services. So I hear you think: JUST UPGRADE THE DAM THING, but I don’t know the impact on the current configuration and published services.

I guess it would be great to check if it is possible to “hack” a Windows 2003 server and adjust the security features of the server. Because I guess that the security policies, introduced in Windows 2003 server, are the cause of not connecting the ICA session.

I hope: TO BE CONTINUED…..