If you would like to read the other parts in this article series please go to:
- TMG Firewall Options for Scalability and High Availability (Part 1)
- TMG Firewall Options for Scalability and High Availability (Part 2)
Introduction
In the first two parts of this multi-part article series, we talked about enterprise arrays and how you can use enterprise arrays to create a collection of TMG firewalls that can act as a single logical firewall. Enterprise arrays in TMG are a very powerful method for building a redundant and highly available firewall solution using a collection of commodity servers or even virtual machines. In my opinion, any large organization that is using the TMG firewall as its network firewall or web proxy server solution should be using enterprise arrays rather than standalone TMG firewalls.
Enterprise arrays solve the problem of high availability for the firewall itself, but there are other things you need to think about when it comes to redundancy, and that’s what we’ll be focusing on in this, Part 3 of the series.
Internet link redundancy
When it comes to a network device such as a TMG firewall, the other major high availability consideration is redundancy at the network level. For the corporate network that connects the client systems to the TMG firewall outbound access point, in a large enterprise your networking guys will have already taken care of that. They have deployed redundant routers and switches and routing protocols to make sure that the network is as available as possible. So, as the TMG firewall admin, you don’t have to worry about that.
However, as the TMG firewall admin, you do need to worry about high availability of the Internet connection. Your corporate network can be highly redundant, but if your Internet connection goes down, it doesn’t matter how redundant the internal network is (at least from the perspective of Internet access – and that’s what users care about today). Internet link redundancy is more important now than ever, since so much of enterprise computing increasingly requires access to cloud services. If the Internet connection goes down, so does access to all those cloud services you depend on. In fact, given this dependency on Internet connectivity to cloud services, you need to do everything you can do to insure as closely as possible the equivalent to “dial tone level” services to your users for Internet access.
This was a major problem with the ISA firewall, as the ISA firewall supported only a single ISP. With the release of the TMG firewall, though, the ability to use multiple ISPs became a reality – and that was a welcome relief to many admins. If you were in the ISA firewall space at the time, you know that support for multiple ISPs was a feature that had been requested by customers from the time the ISA 2004 first came out. Good things are worth waiting for, and now you have it with the TMG firewall.
Multiple ISP support
Before getting into the details of the TMG multi-ISP feature, there are a few things you need to know about it in advance:
- While the term Microsoft uses to describe the feature is “multi-ISP” support, it more accurately could be called “dual ISP” support, because you are limited to two ISPs. This is an important consideration to keep in mind, because if you are only able to use two ISPs, you are going to need to make sure that these ISPs don’t share the same infrastructure. That might require a little research. For example, if both of the ISPs use the same cable or fiber infrastructure, or end up at the same demarc or telco ingress point, then having two ISPs won’t give you true redundancy because they share a point of failure. You’ll probably need to ask some questions of the providers on this to make sure that having two ISPs will mean that you actually have a truly redundant infrastructure. And if not, you want to be aware of at what point the redundancy ends.
- There must be a NAT relationship between the source and destination Networks. That means if you are using a route relationship on any of the TMG firewall Protected Networks, they are not going to be able to take advantage of multiple ISPs. In general, this shouldn’t be a problem. The only time I can think of that this might pose a possible issue is if you have a DMZ network between the TMG firewall and the client systems. In that scenario, some organizations will have set up a route relationship between the DMZ network and the external network. If that’s the case, you will either have to change your plans regarding using multiple ISPs or change the route relationship between the DMZ network from route to NAT.
- Each ISP connection needs to connect to a default gateway that is on a different network ID from the other ISP. In other words, both default gateways cannot be on the same network ID (which means the external IP addresses on the TMG firewall cannot be on the same network ID). You might be wondering why this would be a problem. Think of a scenario where you have a pair of NAT devices in front of the TMG firewall. Each of the NAT devices (or routers) has an external interface that connects the device to a different ISP, so that each of the external interfaces is connected to a different network ID. However, the internal interfaces are most likely connected to the same internal network ID, since there’s no reason why you would want to create two internal default gateway addresses for Internet access. Why make your routing infrastructure more completed than it has to be? That normally would make sense, but in this case, this won’t work with the multiple ISP configuration on the TMG firewall. That’s because the design of the multiple ISP feature assumes that you’re going to have the external interfaces directly connected to the Internet. If you happen to find yourself in this situation, you are going to need to change the network IDs on the internal interfaces of the NAT devices or routers in front of the TMG firewall so that they are on two different network IDs. This is not a major problem, but is an extra added bit of hassle factor that I wish we didn’t have to deal with.
- Your external interfaces cannot use DCHP to obtain their IP addresses. Obviously, if you are using a home-user type ISP connection, then multi-ISP support is not for you. Some businesses may also find themselves in that situation. With that said, there is a possible solution, however, which is to put NAT devices in front of the TMG firewall that is configured to use multiple ISPs. However, this is going to add a level of overhead that organizations that have to use DHCP for public address assignment probably don’t want to have to deal with.
- Technically, you can host both ISP connections on one NIC, or you can use two NICs. However, since we’re thinking about redundancy, my recommendation is that you should probably want to make sure your hardware is redundant as well, which means you would want to have a separate NIC for each of the ISP connections. The reason for this is that while you can connect to multiple ISPs using a single NIC, if that NIC should go down, you would then lose all of your Internet connectivity, and that would really suck (not to mention that it would make you look bad to your bosses) since you had the option of preventing that from happening.
- Network offload processing ought to be set to the same setting – either on or off – on both NICs because if one of the NICs has it on and the other has it off, then offloading processing will be disabled on the NIC that has it on. This isn’t that much of a big deal, but it’s something that you should know about, just in case you do have network offload processing enabled on your TMG firewall connected NICs.
These are some of the basic things you should know about multi-ISP support before considering adopting it in your TMG firewall infrastructure. In addition, remember that multiple ISP support can be configured to work in one of two ways. These include:
- Failover only – in this mode one ISP is used at all times until it becomes unavailable. When that happens, your Internet connections are forwarded to the secondary ISP. This is a good choice when you have one high speed link and the other is slower, but good enough to get you by until the primary link comes back up again. Also, an advantage here is that if your bandwidth is metered, you do not have to pay for bandwidth used on a link that is not being used until required.
- Failover and load balancing – in this mode, both links are used all of the time. You have the option to set a weighting for each of the links, so if you do not want to use both of them equally, you don’t have to. Of course, if one of the links fails, all the connections go to the one that’s online.
Summary
In this article, we finished up our series on high availability and redundancy for the TMG firewall. Over the course of the three parts, we talked about the ways you can ensure that your TMG firewalls provide for high availability to Internet resources for the users in your organization. In this, Part 3, we discussed the multiple ISP function in TMG that enables you to connect the TMG firewall to two different ISPs so that in the event that one of the ISPs goes down, your users will still have Internet connectivity. This bring us to the end of this series on TMG firewall high availability.
If you would like to read the other parts in this article series please go to:
