One of my favorite features of ISA 2000 was the ability to perform firewall chaining in a back to back firewall scenario and in branch office scenarios. Firewall chaining allowed you to make the downstream ISA firewall a de facto firewall client of an upstream ISA firewall. The provided two valuable features:
- Support for complex protocols requiring secondary connections through all ISA firewalls in the chain
- The ablity to authenticate to the upstream firewall, so even if a host in the DMZ was compromised, it could not gain outbound Internet access because the attacker would not have legimate user credentails to connect to the Internet
This situation changed in ISA 2004, but it was never officially recognized. I did make a note of these problems in our ISA 2004 book and in the ISA 2004 Branch Office Deployment Kit (http://www.microsoft.com/technet/prodtechnol/isa/2…) but there was never a KB article or white paper that explicitly mentioned this problem.
With ISA 2006, there is a doucment Chaining Concepts in ISA Server 2006 at http://www.microsoft.com/technet/prodtechnol/isa/2… which points out the following limitation in Firewall chaining:
There are a number of limitations associated with firewall chaining scenarios:
- Setting authentication between the downstream and upstream servers does not work as expected. Use of firewall chaining is not recommended if user authentication is required on the upstream server.
- Requests from Firewall clients do not work as expected for protocols with secondary connections. For these protocols, we recommend that you do not configure firewall chaining to forward requests from Firewall clients to an upstream server.
- Firewall chaining does not work as expected if there is a network object defined between the downstream and upstream server locations. We recommend that you do not configure a network between the downstream and upstream firewall.
Even with these limitations, firewall chaining may be useful in some scenarios for the support of SecureNAT clients. Configuring firewall chaining ensures that SecureNAT clients are not reliant on a routing infrastructure and default gateway settings. The routing structure only requires that the downstream ISA Server computer has a route to the upstream proxy. For example, in a branch office scenario, firewall chaining allows you to chain non-Web requests from SecureNAT clients (who may not be Windows clients) to the main office.
While I agree that the support for SecureNET clients is a good thing, you have to keep in mind how limited the SecureNET client is, in that it does not provide for authenticated connections and there is no support for complex protocols that require secondary connections unless there is an application filter in place.
Let’s hope they fix this problem in a service pack or in the next version of the ISA firewall, as Firewall chaining is a key feature in any branch office deployment scenario.
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP — ISA Firewalls