If you would like to read the other parts in this article series please go to:
- TMG Firewall Access Control Policies and Rules (Part 1)
- TMG Firewall Access Control Policies and Rules (Part 2)
- TMG Firewall Access Control Policies and Rules (Part 3)
Introduction
In Part 3 in this series on access control with the TMG firewall, we talked about TMG firewall Networks. In that article, you learned that in order for the TMG firewall to accept and forward connections from one endpoint to another, the TMG firewall has to be aware of the existence of the IP address space of the source and destination host. In most cases, the TMG firewall will already be aware of these address spaces because of the default, built-in TMG firewall Networks – the default External Network and the default Internal Network. However, as we discussed in that article, there are plenty of exceptions to the default scenario, and therefore you need to be aware of how the TMG firewall uses Networks to control access.
As I noted in that article, creating the TMG firewall Networks is just the beginning. After you define your TMG firewall Networks, the next step is to connect those networks. Just creating the Networks isn’t enough. Oh, when you create the Networks, the TMG firewall is aware of them; however, it doesn’t know at that point how to handle the traffic between the Networks. Connecting Networks is an exercise by which you tell the TMG firewall how to route the traffic between the Networks. There are two ways that you can connect TMG firewall Networks to each other:
- Route
- NAT
As you can see, connecting TMG firewall Networks is essentially the process of telling the firewall what the route relationship is between the two Networks. You don’t have to define the route relationship between the default Internal and External Networks, because that’s already done for you; that relationship is set to NAT.
Route Relationship
A route relationship between TMG firewall Networks essentially tells the firewall to leave the source and destination addresses as they are. The TMG firewall will not change the IP address in the IP packet of the source of the request. Route relationships then apply to both Access Rules and Server Publishing Rules. Here’s how that works in each case:
- In the Access Rule scenario, the TMG firewall will forward the packet from the requesting host to the destination server. When the destination server receives the packet, it will see the original IP address of the host that made the request through the TMG firewall. The destination server responds to the request by sending the response to the IP address of the original requesting host.
- In the Server Publishing Rule scenario, the TMG firewall will forward the packet to the published server using the source IP address of the request of the requesting host. When the published server accepts the request, it will respond to the IP address of the requesting host and not to the IP address of the TMG firewall.
When would you use a route relationship to connect TMG Firewall Networks? Here are some examples:
- For Access Rules, you could use a route relationship if you were going to connect two Networks that are part of the corporate network. The source and destination Networks could be private IP address Networks, public IP address Networks, or a mixture of the two. It doesn’t matter if you mix up public and private address Networks when the source and destination are part of the corporate network, since you control the routing table entries for all network IDs that are under corporate control.
- For Server Publishing Rules, you could use a route relationship in this same way. Suppose you have a TMG firewall Network defined for the network on which all the server infrastructure is located. You can connect the Network on which the clients live to the server infrastructure Network using a route rule. Of course, you could instead use an Access Rule to allow connections from the clients on the client Network to the server Network, but you would miss out on some added security in many cases. The reason for this is that in contrast to Access Rules, Server Publishing Rules have application filters attached to them. For example, the SMTP Server Publishing protocol has an application filter attached to it. When clients send messages to an SMTP server through a TMG SMTP Server Publishing Rule, those connections are subjected to the security screening of the SMTP filter. That’s not the case if the connections from the clients are forwarded through an Access Rule.
Route relationships are simple, but they depend on your existing routing table infrastructure. The TMG firewall needs to be configured with all the routing table entries it needs to route packets to the correct gateway. If the routing table entries are missing, it doesn’t matter whether you created a route relationship or not, the TMG firewall won’t have the gateway address it needs, and the connection will fail. Sure, the TMG firewall will end up using the gateway of last resort, but in most cases, that gateway is the one that provides access to the Internet, not access to the subnets that are located on the corporate network.
In contrast to the NAT relationship that we’ll talk about next, the route relationship doesn’t incur the processing overhead that’s required of NATing packets between networks. Not that this requires a ton of overhead, but it does require memory and processor cycles be dedicated to maintaining and updating the NAT table. If you don’t need to NAT, then why not save some cycles and some memory and just define route relationships between the source and destination?
The primary reason that you might want to do that is if you think it’s important to hide addresses from one side or another. In that case, you’d want to set a NAT relationship between the source and destination Networks.
NAT Relationship
When you define a NAT relationship between the source and destination TMG firewall Network, you are going to end up hiding the IP address of the requesting host. When the requesting host sends a request to the destination host through the TMG firewall, the TMG firewall is going to replace the IP address of the requesting host with an IP address that’s assigned to the NIC on the TMG firewall that is responsible for forwarding the request. That NIC is going to be the one “closest” to the destination host. For example, if the request is going out to the Internet, then that IP address is going to be one that is assigned to the network adapter that’s associated with the default External Network.
When you connect two Networks and assign the routing relationship to NAT, you are given the choice of whether you want to use the default IP address that’s assigned to the NIC that will be forwarding the request to the destination. You have the following options:
- Use the default IP address
- Use the specified IP address
- Use multiple IP addresses
The Use the specified IP address address option is used when there is more than one IP address assigned to the NIC in question. You can choose which one of those IP addresses to use. The Use multiple IP addresses is a special case scenario, where you have configured the TMG firewall to use multiple ISPs.
Selecting the Use the default IP address option used to mean that the firewall would use the IP address that was on the top of the IP address list when you looked at the TCP/IP Properties of the NIC. That was the case for the ISA firewall. That’s not the case for the TMG firewall, and that difference has caused its fair share of confusion over the years. I don’t want to go into all the gory details here, but if you want to learn more about that issue, check out the blog post about this on the TMG firewall team blog.
When would you use a NAT relationship? Here are some examples:
- You want to hide the IP address of the source host that is making the request from the destination host.
- The destination host doesn’t have routing table information that would allow the response from the destination host to make it back to the requesting client. The most common example of this is when the requesting host is located on a private address network behind the TMG firewall and the responding host is located on the Internet. Since Internet-located hosts don’t have routing information for private address spaces, you would have to configure a NAT relationship.
Server Publishing Rules are a little different from Access Rules when applied to Networks that are connected via a NAT relationship. When you publish a server on the corporate network so that it’s available from a Network through a NAT relationship, you have two options regarding how to forward the IP address of the requesting host:
- Replace the source address with the IP address of the TMG firewall NIC closest to the published server
- Preserve the IP address of the requesting host that is sending a request to the published server
When you replace the IP address of the requesting host, the published server on your corporate network will see all connections coming from the IP address of the TMG firewall. This isn’t very useful when it comes to doing things like forensics and web analytics, since in these scenarios you want to have the actual IP address of the devices connecting to the published server. In this case, you will want to make sure that you preserve the source IP address of the requesting host.
There is a subtle routing requirement for each of these options. Consider:
- When you create a Server Publishing Rule between Networks that have a NAT relationship and you replace the source IP address with the address of the TMG firewall, the published server only needs to know that route required to reach the TMG firewall IP address that forwarded the request. That route could be the published server’s default gateway, or a route that doesn’t require a default gateway and just uses your internal routing table entries.
- When you create a Server Publishing Rule between Networks that have a NAT relationship and you preserve the IP address of the requesting host, you’ll find in most cases that the requesting host is located on a network that is not under your control and requires routing table entries that are also not under your control (the Internet scenario). In this case, the published server will need a default gateway configured that provides a path to the Internet. Some security specialists consider this to be a potential security issue, since you don’t really want the server to be able to initiate connections to the Internet through a default gateway.
Summary
In this article, we completed our series on access control considerations for the TMG firewall. We talked about TMG firewall Networks and how to connect those Networks use routing relationships. The two routing relationships are Route and NAT and you use them based on your requirements for security, performance, and ease of use. I hope you enjoyed this series and learned a thing or two. Thanks! –Deb.
If you would like to read the other parts in this article series please go to:
