Figure 10.4 shows a scenario where a system on the network services segment needs to initiate a connection to a host on the corporate network. A network management server on the network services segment makes a connection to a workstation on the corporate network in front of the network services perimeter ISA firewall.
The connection is first sent to the network services perimeter ISA firewall’s internal interface, as this is the default gateway of the network management server.The connection is then sent directly to the workstation, because the ISA firewall has knowledge of all networks to which is it directly connected.That is to say, the ISA firewall can do an Address Resolution Protocol (ARP) broadcast to get the Media Access Control (MAC) address of the workstation and send the request directly to that workstation.
A problem arises when the workstation tries to respond to the management server on the network services segment. Because the destination IP address of the management server is on a network remote from the workstation’s network ID, the workstation sends the response to its default gateway, which is the internal interface of the edge ISA firewall.The response traffic is denied by the ISA firewall because the client is sending a SYN-ACK message back to the management server, but the ISA firewall never “saw” the SYN message from the management server to the workstation. Because the ISA firewall is a stateful packet inspection firewall, it drops the SYN-ACK because it isn’t associated with a preceding SYN.
You can deal with this issue in several ways:
-
Make sure that no servers on the network services segment behind the perimeter
ISA firewall ever need to create new outbound Transmission Control Protocol (TCP) connections to hosts on the corporate network in front of the network services perimeter ISA firewall.This means that not only can you not place servers making outbound connections through the network services perimeter ISA firewall, but you also cannot use protocols where the clients make primary connections to the servers on the network services segment and require secondary connections from the servers on the network services segment.
-
Put a LAN router between the edge ISA firewall and the rest of the corporate network.
-
Put a LAN router between the network services segment perimeter ISA firewall and the rest of the network.
-
Create routing table entries on the hosts located on the corporate network in front of the network services perimeter ISA firewall so that they know the gateway address to reach the network services segment, which in this case would be the IP address on the external interface of the network services perimeter ISA firewall.
-
Use multiple network interface cards (NICs) on the edge ISA firewall and place the network services segment on an ISA firewall network associated with one of the NICs.This avoids the routing and “network with a network” scenario.
Most enterprise networks will have LAN routers in place, so it’s easy for these organizations to create the appropriate routing table entries to support this scenario. For small organizations that do not have LAN routers in place, you can get complete support for connections to and from the network services segment by automating routing table entries on the corporate network hosts located in front of the network services segment perimeter ISA firewall.You could use a logon script to enter these routing table entries on the clients using the route add –p command.
Multiple Departmental Networks/Security Zones Connected to a Backbone Network
Note that the issues mentioned earlier are specific for the “network within a network” scenario and when clients systems are “on a subnet” with an edge ISA firewall that must be reached from a host on a remote subnet that is part of the same ISA firewall network.This is not a problem when you have a backbone network configured and all the clients and servers are behind ISA firewalls.
For example, consider the network in Figure 10.5. In this scenario, we do not run into similar problems because there are no host systems on the backbone network, and therefore no host systems on a subnet of the edge ISA firewall’s internal interface. All ISA firewalls contain routing table entries directing them to the external interface of the appropriate ISA firewall to reach the appropriate network ID(s) located behind any specific ISA firewall. Hosts behind each ISA firewall use the internal interface of their local ISA firewall as their default gateway, and the routing table entries on the ISA firewalls route the connection to the correct ISA firewall’s external interface for the remote networks.
Note that we are assuming a Route relationship between all ISA firewall networks in this scenario. A mix of route and NAT relationships will work too, and can potentially simplify the routing table entries because segments that use a NAT relationship do not require routing table entries on the ISA firewall to reach the addresses behind the NAT.The responder only needs to reach the IP address on the external interface of the ISA firewall sending the connection, and in a backbone network scenario, all the external interfaces are likely on the same network ID. Whether you decide to use a route or NAT relationship depends on the type of access required.
Note that for the route configuration to work most efficiently, each ISA firewall requires the appropriate routing table entries.You could get around this requirement if each ISA fire-wall used the edge ISA firewall as its default gateway, and the edge ISA firewall contained the appropriate routing table entries.This solution could potentially work, but performance would be abysmal because the edge ISA firewall would be routing connections between all network IDs on the corporate network.
0 comments
Post a Comment