There are some things in life that no matter how hard you try to figure out, you can never make sense of them. I ran into one of these issues last weekend when trying to figure out why some people seem to think that a unihomed IAG wouldn’t be as popular as a unihomed ISA Firewall.
I was thinking of conversations I’ve had with the IAG marketing and technical folks and on multiple occasions I’ve asked about support for a unihomed configuration in future versions of the IAG product. I’ve been told that this is an interesting idea, but that there didn’t seem to be much interest in the unihomed configuration and thus they weren’t sure if it was worthwhile to officially support a unihomed IAG. However, this isn’t to say that such support wouldn’t be included, but that no hard and fast decisions have been made in this area.
As you can imagine, I found this to be a jaw-dropping response given my experience with trying to get people to not deploy unihomed ISA firewalls. No interest in the unihomed configuration? How could that be? We’ve been trying to over 8 years to go people to drop the unihomed configuration for the various versions of the ISA Firewall, but I’m sad to say that I suspect that close to, or over, 50% of ISA firewall deployments use the unihomed configuration. This in spite of the fact that we have pushed extraordinarily hard for people to use the full firewall configuration of the ISA firewall for over the years.
What does a unihomed ISA firewall do? Not much. It does forward and reverse Web proxy. Sure, it does add some security to inbound connections, and some to outbound connections if you can prevent users from bypassing the unihomed ISA Firewall since you can’t force it to be in the path (a single NIC prevents you from forcing the unihomed ISA Firewall from being in the path between source and destination). The unihomed ISA firewall does some caching too, as well as SSL termination and initiation.
So, given how popular the unihomed ISA Firewall is, what does the IAG do that the ISA firewall doesn’t do that prevents it from being as popular in a unihomed configuration? As an SSL VPN gateway, the vast majority of the work performed by the IAG is reverse Web proxy. While no caching is done, there is advanced URL inspection as well as advanced authentication support. But for the most part, the IAG is an advanced reverse Web Proxy device, similar to the unihomed ISA Firewall.
Given that multihoming the ISA firewall is often a deployment blocker, why isn’t multihoming the IAG a deployment blocker? Or maybe the IAG people aren’t really attuned to this issue as the ISA firewall people have been over the years, but instead are leveraging the experience of the Whale people, who had the Air Gap or eGap appliances.
If they had been paying attention to the unihomed ISA firewall experiences over almost the last decade, they would realize that requiring the IAG to be multihomed could represent a deployment blocker in many environments. At the very least, you significantly increase the customer base by enabling the application administrator the ability to introduce a unihomed IAG because the application administrator doesn’t have to deal with the “network guys”, who are often just outsourced Cisco teams who manage the edge router or firewall, and the internal network routers and switches.
It’s our firm opinion here at ISAserver.org that enabling unihomed support for the IAG and its successors will significantly increase the number of people who will deploy the IAG and its successors, and that whatever development and testing efforts that go into unihomed support will more than pay for themselves over the sales lifetime of IAG and future related products.
HTH,
Tom
Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: [email protected]
MVP — Microsoft Firewalls (ISA)