Advanced ISA Firewall Configuration: "Network Behind a Network" Scenarios
The ISA 2006 ISA Firewall’s multi-networking feature represents a major departure from the ISA Server 2000 firewall’s approach to networking. In ISA 2000, networks are seen as either trusted or untrusted. In ISA Server 2000, there is a necessary relationship between trusted networks and the Local Address Table (LAT). It is not possible to have one without the other. Trusted networks are defined by the networks listed in the LAT: networks not included in the LAT are untrusted. Communications moving between LAT hosts (hosts with IP addresses contained in the LAT) are not exposed to the ISA 2000 firewall’s stateful packet and application layer inspection mechanisms.
Discuss this article
The LAT is gone in the ISA 2006 firewall. The ISA firewall’s concept of multi-networking includes as its basic tenet that no network is trusted by default and all communications moving through the ISA Firewall are exposed to the firewall’s stateful packet and application layer inspection mechanisms. This provides for a much higher level of security and access control that you could obtain with the ISA 2000 firewall. By severing the relationship between the LAT and trusted networks, the new ISA 2006 firewall gives administrators a much more refined granular level of control over communications that move between networks.
The Network object (ISA Firewall Network) is one of the key concepts you must understand in order to get the most out of your ISA firewall. Key issues regarding the ISA firewall’s Network object include:
- An interface can belong to only one Network
- An interface cannot belong to two or more Networks
- You can place as many network interface cards in the ISA firewall as your hardware supports
- All IP addresses located behind a network interface are part of the same Network
- All IP addresses defined on the ISA firewall are considered Protected Networks
- Any IP address that isn’t defined on the ISA firewall is considered part of the default External network
The VPN Clients Network and the Quarantined VPN Clients Network are virtual or dynamically created Networks in that addresses are added and removed to these networks when VPN clients connect and disconnect
The network directly connected to a particular interface might be considered the root of a particular ISA Firewall Network. For example, if you were using network ID 10.0.0.0/16 as the default Internet Network, then other networks behind it might be 10.1.0.0/16, 10.2.0.0/16, etc. You could then summarize the entire Network associated with that adapter as 10.0.0.0/8 and that would include all the networks located behind that interface.
You could also include networks behind the same interface that do not summarize. For example, you might have the ISA Firewall’s internal interface on network ID be 10.0.0.0/16 and another network located behind that network be 172.16.0.0/16. The ISA firewall doesn’t have a problem with this configuration. You just include all the addresses in both Network IDs when defining the ISA Firewall Network that network interface represents.
When you have multiple networks defined by a single network interface, the networks that aren’t part of the on-subnet network are considered networks within a Network. Figure 1 shows an example of a network within a Network. The ISA firewall must be configured with a routing table entry that provides the gateway address to the networks behind the on-subnet network. In figure 1, the routing table entry on the ISA firewall would send all connections to network ID 10.10.10.0/24 to 10.0.0.100, which is an interface on a Checkpoint server.
Example Network within an ISA Firewall Network Setup
Figure 1 shows the basic setup in the lab network I’ll be using to demonstrate some of the issues you’ll run into while working with networks within a Network configurations. The on-subnet network is network ID 10.0.0.0/24 and the network located behind the Checkpoint server is network ID 10.10.10.0/24. I used a Checkpoint Server in this example because it’s what I had available, but it could be any firewall device or packet filtering router. You could replace the Checkpoint server with a hardware router, layer 3 switch, or even a VPN gateway that connects another network to one of the ISA firewall’s Protected Networks.
Figure 1: Back-end “network within a Network”
As a quick overview, the SecureNAT client is any machine configured with a default gateway that routes connections to the Internet through the ISA firewall. If the SecureNAT client is located on a network directly attached to the ISA firewall, then the default gateway of the SecureNAT client is the IP address on the ISA firewall’s interface that the SecureNAT client is connected to. If the SecureNAT client is located on a network ID different from the ISA firewall’s interface, then the SecureNAT client is configured with a default gateway address of a gateway that will forward Internet bound requests to the ISA firewall’s interface.
In figure 1, the host with IP address 10.0.0.5/24 uses the default gateway 10.0.0.1 because it’s on the same network ID as the ISA firewall’s local interface. The host with IP address 10.10.10.224 has a default gateway 10.10.10.1, which routes Internet bound requests to the local interface of the Checkpoint server. The Checkpoint server is configured with a default gateway address 10.0.0.1, which is the interface on the ISA firewall which is on the same Network as the Checkpoint server. The Checkpoint server forwards the Internet bound connections to the ISA firewall and the ISA firewall sends them to the Internet host.
Firewall clients work quite a bit differently. The Firewall client is configured with the name or IP address of the ISA firewall. The Firewall client software intercepts all TCP and UDP connections made by Winsock applications the Firewall client computer and remotes them (sends them directly to) the IP address of the Firewall client listener on the ISA firewall’s interface that is on the same Network as the Firewall client machine.
For example in figure 1, the client with IP address 10.0.0.5/24 is configured as a Firewall client and the Firewall client software is configured to use address 10.0.0.1 as its default gateway. A firewall client on the back-end network with address 10.10.10.2/24 also has its Firewall client application configured to use IP address 10.0.0.1. The Firewall client machine sends communications mediated by the Firewall client software directly to the ISA firewall. This means that the Firewall client is independent of organization’s current routing infrastructure. The only requirement is that the organizations routing infrastructure know the routes to the networks that the ISA firewall’s interface is located.
While these difference might seem straightforward when dealing with Internet bound connections, there are some special considerations you’re going to have to take into account when dealing with network within a Network scenarios. If you don’t understand these differences you’ll end up frustrated and confused with your network within a Network configurations.
Figure 2 shows the request and response paths between a SecureNAT client on the on-subnet network and a server on the back-end network (the network within a Network). When the SecureNAT client on the on-subnet network sends a connection request to the host on the back-end network, the SecureNAT client sends the request to the ISA firewall’s interface on the same Network as the SecureNAT client. The ISA firewall forwards the request to the interface on the Checkpoint server that can route to the back-end network and then the Checkpoint server forwards the connection to the destination host. The response path is through the Checkpoint server and then directly to the SecureNAT client, because the Checkpoint server can forward response directly to the client and does not need to use its gateway address to do so.
Figure 2: A SecureNAT Client Connecting to a network within a Network
Now let’s take a look at how the Firewall client works. Figure 3 shows two scenarios: the first scenario is the Firewall client connecting to a non-local network. A non-local Network is any network that isn’t on the same Network that the Firewall client computer is located. The non-local Network could be somewhere on the Internet, or a network located behind another interface connected to the ISA firewall. The second scenario shows a Firewall client connection to a local network, which is a network defined as being on the same Network as the Firewall client making the request.
Discuss this article
The first scenario is illustrated by the Firewall client located on the right. This Firewall client machine attempts to connect to a Terminal Server at address 188.8.131.52. The Access Rule on the ISA firewall requires authentication before the connection request to the RDP server on the Internet is allowed. The Firewall client automatically forwards the user’s credentials to the ISA firewall and if the Access Rule allowing the outbound RDP connection applies to that user, the connection is forwarded to the remote RDP server on the Internet.
The second scenario also depicts a Firewall client machine on the same subnet as the ISA firewall’s local interface, but this time the RDP connection is to a host on the back-end network within a Network.
This is where problems may creep in. The Firewall client software automatically downloads a list of all IP addresses defined for the Network that Firewall client belongs to. In this example, the Firewall client’s ISA Firewall Network includes all the addresses in the 10.0.0.0/24 and 10.10.10.0/24 ranges. The Firewall client software compares the destination address of the connection request to the addresses defined for the Network to which the Firewall client belongs. If the destination is on a non-local Network, then the connection is remoted to the ISA firewall’s local interface and the ISA firewall proxies the connection to the non-local network. However, if the destination address is for a host on the same Network as the Firewall client, then the Firewall client software will ignore the connection.
When the Firewall client ignores the connection, the destination host must be located on the same network ID as the Firewall client machine making the request, or the Firewall client machine must also be configured as a SecureNAT client, with a default gateway address that is able to route the connection to the destination network ID. In this second scenario, the Firewall client is also configured as a SecureNAT client.
When the Firewall client in this second scenario attempts to establish an RDP connection to a host on the back-end network, the Firewall client software will ignore the connection because the back-end network is part of the same ISA Firewall Network as the on-subnet network. Since the SecureNAT client is unable to send credentials to the ISA firewall, the connection request will fail if the Access Rule allowing RDP connections requires authentication. This is what takes place in this second scenario.
Note that if the Access Rule did not require authentication, then the second scenario would work, because the Firewall client would be able to fail over to the SecureNAT client configuration and connect to the back-end network host. Of course, the entire point of using the Firewall client is to allow strong user/group based authentication.
Figure 3: Firewall Client Paths through Local and non-Local Networks
The log file entries in figure 4 show the connections to the remote RDP server and the RDP server on the same network. The second and third lines in the log show RDP connections to a host on another Network. The Firewall client detects that the connection is destined to a host on another network and intercepts the connection and remotes it, along with the user credentials, to the ISA firewall. You can see the user information in the Client Username column, which confirms that the connection was handled by the Firewall client.
On the 5th, 8th and 9th lines of the log file, you see RDP connection attempts to a machine on the back-end network that is part of the same Network as the Firewall client computer. Because the destination is on the same Network as the Firewall client computer, the Firewall client ignores the request and the SecureNAT client configuration takes over. You can see that the rule allowing connections to the back-end network with the Network denies the connection. The connection is denied because the rule is configured to require users to authenticate before connecting. The SecureNAT client can never send credentials to the ISA firewall, so the connection fails.
Figure 4: Log files showing Firewall client and SecureNAT client connections
What is the solution to this problem? The best solution is to configure the machines as Firewall clients so that they can access resources on the other Networks, and for on subnet hosts, configure the machines as SecureNAT clients, but use a gateway address that is not the IP address of the ISA firewall on the same Network.
Figure 5 shows the recommended configuration. The machines on the on-subnet network are configured as Firewall clients. When connections are made to other ISA Firewall Networks, the Firewall client will handle the connection. When connections are made to hosts on the same ISA Firewall Network, the SecureNAT client will take over and the default gateway address is set as the back-end router’s interface to the back-end network with a Network. Since the back-end router has a default gateway set to the ISA firewall’s interface on the same Network, any SecureNAT client requests that need to be routed to the Internet can be done by the back-end router. This would be required if the host on the on-subnet network needs to use a non-Winsock protocol (non-TCP or UDP) such as ICMP (for ping and tracert).
With this configuration you don’t need to make any changes on the back-end network within a Network. The Firewall clients on this network still remote their Winsock requests destined to other Networks to the ISA firewall’s interface on the same Network. The SecureNAT client configuration is still set to the back-end router and that router already knows the route to all internal subnets, so the ISA firewall never even has a chance to deny the request, since it never sees it. The back-end client’s SecureNAT client configuration allows a direct connection to other hosts on the same Network.
Figure 5: Using an Alternate Default Gateway Address for On-Subnet Hosts
The network within a Network scenario is a completely workable scenario and all it requires is that you include all addresses behind a specific interface to be included in that Network. The primary limitation in this scenario is that you can’t use the Firewall client to perform user/group based access controls to control traffic moving between network IDs located on the same ISA firewall defined Network.
While this might at first seem like a disappointing limitation, the fact is that the ISA firewall controls traffic traversing the firewall. While we can do some tricks with access rules to control traffic from one IP address group to another, the truth is that in order for the ISA firewall, or any firewall, to do the real work of a firewall, the connections must traverse the firewall, but just be routed from one network to another behind the same interface.
An example of one such trick is to use the Subnet or Address Range objects to control access to other machines located on the same Network. In fact, you can get even more granular and use Computer objects. Note that this is useful only for the machines located on the on-subnet network. You would have to create router ACLs on any back-end subnets to obtain a similar level of control.
Discuss this article
In this article we took an advanced look at how the ISA Firewall’s multi-networking features work in a network with an ISA Firewall Network scenario. In particular, we examined the differences between how SecureNAT and Firewall clients behave in this scenario, and described a configuration that you can use to support machines that are configured as both Firewall and SecureNAT client.