Something that comes up a lot is how can you leverage multiple ISP connections with the ISA Firewall. As you may already know, the ISA firewall doesn’t support multiple gateways or policy based routing, so you need to put another device in front of the ISA firewall that supports multiple WAN interfaces. You need to be careful when choose such as device, because if you want to support publishing rules, you’ll need a device that will support DNS in a way that while fail over the incoming connections.
In spite of our lack of support for multiple gateways, I got to thinking about a possibility after listening to the Web cast on how Microsoft uses the ISA firewall to protect the Microsoft corporate network. What goes me to thinking about this was the discussion regarding the new CARP algorithm and how it load balances connections based on FQDN and not the entire URL. I discussed this in a blog post last weekend if you want to check that out.
Since all requests and responses for a particular Internet host are now assigned to the same ISA Firewall array member, it might be possible to connect each array member to a different ISP, or a subset of array members to different ISPs. This would theoretically increase overall throughput if we can reach the point where the CARP algorithm becomes statistically significant, because all connections will, over time, be evenly distributed across all array members, and hence, across all ISPs server those array members.
So, if we had an ISA Firewall array of 4 members, and two members are connected to ISP1 and two members are connected to ISP2, then the aggregate throughput through the array will be the bandwidth available on ISP1 + ISP2. If each ISP provided 15Mbps, then total outbound bandwidth available to the array would be 30Mps.
There are some limitations to this configuration that I can think of right now:
- This works only for outbound Web proxy. It will not work for Web Publishing Rules
- If one of the links goes down, all Internet hosts serviced by those array members will be unreachable. CARP will not remove these array members from the array membership list because the machines are still online.
- While CARP will, over time, provide outbound bandwidth equal to the aggregate provided by all ISPs, these is a statistical phenomenon only. You will not see this bandwidth aggregation in real time
There may be more limitations that I haven’t considered, and there might be solutions for some of these problems. For example, it might be possible to write a script that tests the integrity of the ISP connection and if the connections goes down, then the Firewall service could be disabled. This should be enough to remove the ISA Firewall Array members using that ISP from the array membership list. The script could also detect when the gateways are active again, and restart the Firewall service, which would place the array members back on the array membership list.
This should also work with NLB enabled on the internal interfaces. Of course, NLB could not be enabled on the external interfaces because the external interface addresses would be on different network IDs for the array members using different ISPs.
I put these ideas out here for discussion. I have no idea if it would work and if anyone would want to try this. But maybe someone will be able to add to these ideas and come up with some creative ways to solve the problem of multiple WAN links without having to buy another device to put in front of the ISA Firewall array
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: [email protected]
MVP — Microsoft Firewalls (ISA)