Understanding ISA Firewall Networks (v1.1)

Understanding ISA Firewall Networks (v1.1)

By Thomas W Shinder MD, MVP

Got Questions? Go to:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000233 and ask!

We’ve been fielding a ton of questions on the ISAserver.org mailing list in the last couple of weeks that focus on issues with the new ISA firewall’s concept of the network. This is one of the key differences between the ISA Server 2000 firewall and the new ISA firewall, ISA Server 2004. Because this is such a critical issue to understanding how the ISA firewall works, I figured it would be worth taking some time to discuss these issues with you so that you don’t run into problems with your ISA firewall configuration and access policy.

In this article we cover the basic principles of ISA firewall Networks. For deep details and expanded coverage of this subject, check out our book Configuring ISA Server 2004

If you’re an ISA Server 2000 firewall admin, you know that it had a very simple concept of the network: there were trusted networks and untrusted networks. Trusted networks were defined as those containing addresses included in the LAT. Untrusted networks were networks including addresses that were not on the LAT. The ISA Server 2000 firewall’s approach might have been useful and reasonable during the development of ISA Server 2000 in the latter 1990s, but the model doesn’t work so well today.

The problem with the ISA Server 2000 networking model was that is was based on the assumption that you could trust a network. Communications between trusted (LAT) hosts was not filtered or inspected by the ISA Server 2000 firewall’s stateful packet filtering or stateful application layer inspection mechanisms.

This created several problems:

• All internal interfaces on the ISA firewall were part of the LAT. All communications between LAT hosts on the corporate network and the ISA Server 2000 firewall were not filtered. Exploits could be directed at the ISA Server 2000 firewall’s LAT interfaces and bypass the ISA Server 2000 firewall’s stateful inspection mechanisms.
• Creating multiple internal networks and controlling traffic moving between multiple internal networks was difficult because the ISA Server 2000 firewall did not manage communications between these networks because they were on the LAT. If you wanted access control on communications moving between internal networks, you needed to use RRAS packet filters to accomplish the task. RRAS packet filters are not stateful inspection filters.
• Creating DMZs on a multihomed ISA Server 2000 firewall was difficult because you needed to use public addresses on a DMZ segment, and even when you created the public address DMZ segment, the ISA Server 2000 firewall only performed stateful packet inspection (like a typical hardware firewall), but did not perform stateful stateful application layer inspection.

These limitations made the ISA Server 2000 firewall difficult to manage in a complex network and led to its relegation as back-end firewall and application proxy, instead of a full-fledged front-end stateful packet and application layer inspection firewall.

The networking model used by the new ISA firewall (ISA Server 2004) is completely different than what we had with ISA Server 2000. Most importantly, there is no longer a LAT. That’s right, there is no LAT. None. Not any. Not a trace.

If someone claims there is a LAT in the new ISA firewall, they are wrong. There are local addresses configured on a per ISA firewall Network basis, which are used by Firewall Client and Web Proxy clients located on that specific ISA firewall Network, but there is no LAT.

The major implication of not using a LAT is that there are no trusted networks. Immediately after installing the ISA firewall, you’ll find that you can’t get to the Internet, you can’t get to any DMZ segment, and you can’t get to the ISA firewall itself.

This is all part of Microsoft’s SD3 concept: secure by Design, secure by Default, and secure in Deployment.

firewall functionality and security is not determined by you being able to connect to the Internet without understanding how to configure the firewall.

The ISA firewall is very network centric, so you need to understand the ISA firewall’s concept of networks in order to get things to work correctly. First, you need to understand that right out of the box, the ISA firewall creates the following default Networks (note that I use a capital “N” for an ISA firewall network, this contrasts the lower case “n” which is used to refer to networks in general):

The default Internal Network is defined during the installation of the ISA firewall software and is not the same as the internal network concept used by ISA Server 2000. With ISA Server 2000, the Internal network was defined by any host IP address included in the LAT.

In contrast, the ISA Server 2004 firewall’s default Internal Network contains the core network services the ISA firewall might need to communicate with, such as domain controllers, DNS servers, RADIUS servers, and other core network services. This information is used by the default System Policy.

You are not locked into the concept of the default Internal Network, nor do you need to use it in your System Policies. Its just a convenience that allows your default System Policy to work correctly out of the box in the majority of installations. If you have a more complex network, where core networking services are located throughout multiple corporate networks located behind multiple interfaces on the ISA firewall, then you can easily readjust your System Policy.

The fact that the default Internal Network is not the same as the ISA Server 2000 LAT-based internal network is borne out by the fact that you can install many NICs in the ISA firewall and create multiple internal Networks (note the lower case “i”, since there can only be one default Internal Network). Stateful packet and application layer inspection is performed on all interfaces, so whether the Network you define is an internal, perimeter or external network is not an issue when it comes to firewall security.

The default External Network is defined by all IP addresses for which there is no network definition on the ISA firewall. If the ISA firewall cannot associate an IP address with one of the Networks defined on the ISA firewall, then that IP address is automatically placed in the default External Network.

The Local Host Network includes all IP addresses bound to the ISA firewall’s interfaces. You do not need to explicitly configure entries in the definition of the Local Host Network. The ISA firewall dynamically places all addresses you configure on any of the ISA firewall’s network interfaces into the definition of the Local Host Network.

All communications from the ISA firewall itself source from the Local Host Network, and all communications directed explicitly to (but not through) the ISA firewall have their destination to the ISA firewall’s Local Host Network.

The VPN Clients Network is another ISA firewall Network where IP addresses are added dynamically. Whenever a remote access VPN client connects to the ISA firewall, then the IP address assigned to the VPN client is automatically added to the VPN Clients Network. Even if you use DHCP to assign IP addresses to VPN clients, those addresses will be automatically added to the VPN Clients Network when a VPN client connects and is assigned an address on that Network.

The Quarantined VPN Clients Network also consists of dynamically assigned addresses. In this case, the addresses of VPN clients who are currently in VPN quarantine are automatically assigned to this network.

While those are the default ISA firewall Networks, you can create as many Networks as you like. You can create additional internal Networks (note that we use a lower case “i” here, because there is only one default Internal Network, you can create additional external Networks (note that the “e” is lower case here, because there is only one default External Network) and you can create perimeter Networks (the “p” is never capitalized because there is no default perimeter Network).

There is one more Network, and that’s the Remote Site Network. Remote Site Networks are created when you configure a site to site VPN connection linking two entire network to one another using a site to site VPN link. The ISA firewall uses Remote Site Networks for routing and access control between the local and remote networks connection through the site to site VPN link.

While you can create additional internal, perimeter and external Networks, the type of Network you create is really only for accounting purposes. I say that because the Properties of any of these Networks is exactly the same and the ISA firewall performs stateful filtering and stateful application layer inspection on all Networks, including the default ISA firewall Networks and any custom Networks you create.

What does the ISA firewall do with all these ISA firewall Networks? It uses them to:

The two subjects that new ISA firewall administrators have problems with is understanding the nature of the route relationship between Networks and how the ISA firewall uses Networks to block spoofed packets.

When the ISA firewall intercepts a request for resources that must be made through the firewall, the first thing it does before it checks the firewall policy is determine if the networks are connected.

The ISA firewall determines whether or not the source and destination Networks are connected by checking its Network Rules. If there is a Network Rule defining a relationship between the source and destination Network, then the firewall concludes that the Networks are connected and then begins to compare the connection’s characteristics with firewall access policy.

A Network Rule defines the routing relationship between the source and destination Network. ISA firewall Networks can be connected using either a:

A NAT relationship is “unidirectional”. That is to say, if there is a NAT relationship from the Internal to the External Network, you cannot define a second Network Rule that sets a NAT relationship from the External to the Internal network. The NAT relationship is a one-way relationship.

The implication of this is that you cannot create Access Rules controlling communications from the non-NATed Network into the NATed Network. For example, if we have a Network Rule that sets a NAT relationship from the default Internal Network to the default External Network, then you cannot create an Access Rule allowing communications from the non-NATed Network (the default External Network in this example) and the Internal Network. You must create either Web or Server Publishing Rules to allow communications from the non-NATed Network into the NATed side of the Network relationship.

Protocol Definitions for Access Rules use outbound primary connections. Protocol Definitions for publishing rules always use inbound primary connections. This is something you cannot change and you can’t violate these principles. Even if the user interface allows you to violate these rules, the Access Rules you create will not work.

Watch out for this when you have private or public address DMZs and you use the 3-leg perimeter Network Template to configure a trihomed DMZ segment. The default Network Rule created by this template sets a NAT relationship between the DMZ and the Internal Network, and a Route relationship between the perimeter Network and the default External Network.

A Route relationship is bidirectional. Once you create a Network Rule setting a Route relationship between the source and destination networks, that route relationship exists for hosts on both sides included in the Network Rule.

For example, if you have a Route relationship between a DMZ Network and the default External Network, you also have a Route relationship between the default External Network and the DMZ Network.

The implication of the Route relationship set by a Network Rule is that you can create both Access Rules and Web or Server Publishing Rules allowing communications to and from the Networks participating in a Route relationship.

For example, if you have a Web server in the DMZ segment you want users located on the default External Network to access, you can create either an Access Rule allowing outbound HTTP from the default External Network to the DMZ Network, or you can create a Web Publishing Rule to allow inbound connections from the default External Network to the DMZ Network, or you can create a Server Publishing Rule to allow inbound access to the DMZ Network.

Whether you decide on creating an Access Rule or a Publishing Rule depends on the level of functionality and/or security you require on the connections between the source and destination ISA firewall Network.

The second major issue regarding the ISA firewall’s Networking model is how it performs spoof detection. The ISA firewall uses its Network definitions to determine if a packet is spoofed. If a network interface defined as the root of an ISA firewall Network receives a packet that isn’t directly reachable from that interface, as defined by the Windows routing table, then the packet is considered spoofed.

The practical result of this spoof detection mechanism is that all IP addresses directly reachable from a NIC on the ISA firewall must be defined as part of the same ISA firewall Network.

Example 1: Your corporate network uses only addresses on Network ID 192.168.1.0/24. The definition of the Internal Network will include the address range 192.168.1.0-192.168.1.255.

Example 2: Your corporate network consists of two network IDs and there is a LAN router managing the routing on the corporate network. Network IDs are in use on the corporate network are 192.168.1.0/24 and 192.168.2.0/24. You would include the address range 192.168.1.0-192.168.2.255 in the definition of the Internal Network.

Example 3: Your corporate network consist of three network IDs and there is a LAN router managing the routing on the corporate network. Network IDs are in use on the corporate network are 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24. You would include the address range 192.168.1.0-192.168.3.255 in the definition of the Internal Network.

Example 4: Your corporate network consists of three network IDs on the wired network, and there is a WAN link or site to site VPN link connecting a remote office to the corporate network. The remote office connection is located behind the ISA firewall’s internal NIC. Network IDs 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 are on the wired network and network ID 10.10.0.0/16 are in use on the remote network connected to the network located directly behind the internal NIC. You would include the address ranges 192.168.1.0-192.168.3.0/24 and 10.10.0.0-10.10.255.255 in the definition of the Internal network.

Make sense? All addresses located behind a NIC on the ISA firewall must be included in the Network definition that the address on the NIC participates. There can never be any overlap of addresses between two ISA firewall Networks, and each NIC must be located on a different ISA firewall Network.

Even when there are hosts on remote network IDs (remote from the on-subnet network ID on which the ISA firewall’s interface is located), those addresses must be included in the ISA firewall Network definition for which that interface is the “root” for that ISA firewall Network.

Another way of approaching this issue is to think of how the ISA firewall’s routing table sees networks. For each remote Network (“remote” from the standpoint that the network isn’t on-subnet with the ISA firewall), the ISA firewall’s routing table must have a routing table entry.

For each routing table entry, there is information about the network ID, the subnet mask, and the gateway address. There is also an entry regarding which interface on the ISA firewall device is responsible for routing packets to that network ID. All the network IDs associated with a specific network interface on the ISA firewall must belong to the same ISA firewall Network’s definition.

The figure below shows the routing table for a trihomed ISA firewall. Note that the firewall in this example uses a private address for its external interface, since its behind a NAT router (the NAT router is in front of this ISA firewall because this ISA firewall is located behind a cable network connection, and some cable network providers don’t get along well with the ISA firewall). In this example, you can see that there must be two ISA firewall networks defined: one for the 192.168.1.0/24 network and one for the 10.10.10.0/24 network. The 192.168.123.1 interface doesn’t require a Network definition, because it has a default gateway configured on it and this defines the external interface of the ISA firewall

I could define an ISA firewall Network for the DMZ between the external interface of the ISA firewall and the LAN interface of the upstream NAT device (I don’t call the NAT device a router, since its only a SOHO NAT box, not a real router). This would allow me to configure a NAT or Route relationship between any of the other ISA firewall Networks and the DMZ. This configuration is beyond the scope of this discussion. Check the book for more details on this type of setup.

The practical implication of this is that if you have multiple network IDs behind the same interface on the ISA firewall, you cannot use the Network Network Object [sic] to control access between the source and destination network, since the ISA firewall considers both network IDs as part of the same ISA firewall Network and expects you to use Direct Access for these communications.

This does not mean you can’t use Network Objects to control access from the source and destination network, since you can use Computer Objects, Subnet Objects, and Address Range Objects to set the source and destination in an Access Rule in the ISA firewall’s firewall policy. The only limitation from the viewpoint of source and destination control in an Access Rule is that you can’t use the Network Network [sic] Object.

Another side effect of this spoof detection mechanism is that you need to use Direct Access for host to host communications on the same ISA firewall Network. One way to think of an ISA firewall Network is that the ISA firewall doesn’t perform stateful packet and stateful application layer inspection on communications between hosts on the same ISA firewall Network. So, in a manner of speaking, the ISA firewall Network definition is a pseudo-LAT. But remember, the ISA firewall has NO LAT!

On the other hand, it makes no sense to loop back through the ISA firewall to access resources on the same ISA firewall Network. If hosts on the same ISA firewall Network are part of different security zones or partitions, then you need to create multiple perimeters within that ISA firewall Network and place additional ISA firewalls on that network to create multiple network and application layer partitions within the same ISA firewall Network.

This is a common requirement in larger network environments. For more details on this type of configuration and the implications for SecureNAT, Firewall and Web Proxy clients, check out our book Configuring ISA Server 2004 by Deb Shinder and myself.

The new ISA firewall has a completely different network model compared to that used by the ISA Server 2000 firewall. The new networking model has as its core concept the fact that the ISA firewall does not trust any network and all networks are equally untrusted. The Network centric nature of the ISA firewall also allows it to define whether source and destination Networks are connected, and if connected, what the route relationship is between those Networks. Finally, we went over the details of how the ISA firewall Network concept is used by the ISA firewall’s spoof detection mechanism.

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000233 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy