Network Behind A Network
By Clint Denham
Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000080
Symptom : ISA Server logs the following error message
| Description: ISA Server detected routes through adapter “Internal” that do not correlate with the network element to which this adapter belongs. The address ranges in conflict are: 192.168.0.0-192.168.0.0; 192.168.0.255-192.168.0.255. Fix the network element and/or the routing table to make these ranges consistent; they should be in both or in neither. If you recently created a remote site network, check if the event recurs. If it does not, you may safely ignore this message. |
The address range specified in the error message will vary with your setup, but the cause of this problem is the same.
Short Answer – The ISA Server administrator has not correctly configured the Internal network.
Long Answer – How ISA Server 2004 Views The Network
When ISA Server is installed, some Administrators define the address range 192.168.0.1 through 192.168.0.254 are addresses in the “Internal” Network element. “Network” elements are defined from the ISA Server’s point of view. There is some subtlety to that, so let’s get into the details.
When you provide addresses in the properties of a “Network”, ISA looks through all of the adapters on the system and tries to find an adapter that has an IP address in that range – once it finds one, it associates the “Network” with that adapter.
Consider the following routing table from a Windows Server 2003 host.
| Active Routes: | ||||
|
Network Destination |
Netmask
Gateway
Interface
Metric
0.0.0.0
0.0.0.0
157.57.157.57
157.57.157.57
30
157.57.157.0
255.255.255.0
157.57.157.1
157.57.157.57
30
157.57.157.57
255.255.255.255
127.0.0.1
127.0.0.1
30
157.255.255.255
255.255.255.255
157.57.157.57
157.57.157.57
30
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1
192.168.0.0
255.255.255.0
192.168.0.1
192.168.0.1
30
192.168.0.1
255.255.255.255
127.0.0.1
127.0.0.1
30
192.168.0.255
255.255.255.255
192.168.0.1
192.168.0.1
30
224.0.0.0
240.0.0.0
157.57.157.57
157.57.157.57
30
224.0.0.0
240.0.0.0
192.168.0.1
192.168.0.1
30
255.255.255.255
255.255.255.255
157.57.157.57
157.57.157.57
1
255.255.255.255
255.255.255.255
192.168.0.1
192.168.0.1
1
You can see from the highlighted entries that Windows considers the destination addresses 192.168.0.0 and 192.168.0.255 accessible through the interface 192.168.0.1 (the 192.168.0.1 host specific destination address is a special case).
Furthermore, you can see that the 224.0.0.0 Multicast address and the “All Subnets Broadcast” destination address of 255.255.255.255 are also accessible through the 192.168.0.1 interface – Multicast addresses and this Broadcast address are handled differently from Unicast traffic so we’re not concerned with those destinations when defining Networks.
This is where the subtlety comes into play and there are 2 aspects to it…
| 1. Windows associates the destination addresses 192.168.0.0 and 192.168.0.255 with the interface 192.168.0.1.
2. ISA Server associates it’s “Internal” network with the interface 192.168.0.1. |
ISA Server now compares the information that Windows is providing (192.168.0.0 and 192.168.0.255 are available through the interface 192.168.0.1) with the information that the ISA Server administrator has provided (192.168.0.1 through 192.168.0.254) and sees they are not in conjunction. The simple answer is that these addresses have to be included in the properties of the particular Network object.
Now, consider the following scenario…
The .10, .20 and .30 subnets are also accessible to ISA Server through internal routers. The Windows administrator would go into either the command prompt and use the ROUTE command to add routes to the .10, .20, and .30 subnets through their respective router, or create the routes through Routing and Remote Access Service (RRAS). This would also generate the error, but this time the error message would include the .10, .20 and .30 subnets. This is caused by the same problem – Windows associates those subnets with the 192.168.0.1 interface, but ISA checks the configuration of the Internal network and “sees” that these address ranges are not included in the properties of the Network.
An ISA Server administrator would, logically, think that they need to define a “Network” that contains these addresses – one for the .10, .20 and .30 subnets. Unfortunately, this would not resolve the error. Earlier, we stated that “When you provide addresses in the properties of a “Network”, ISA looks through all of the adapters on the system and tries to find an adapter that has an IP address in that range – once it finds one, it associates the “Network” with that adapter.” If the ISA Server administrator created “Networks” for the .10, .20 and .30 subnets, ISA Server would look through the list of adapters in the system and try to find an adapter that has an address assigned to these subnets. Since, in our configuration, ISA Server has no such network adapters (we only have a single Internal adapter and External adapter), ISA assumes the “Network” the administrator is trying to configure is associated with an interface that is physically disconnected or disabled and sets the “Network” to a disconnected state.
Additional Information : The ISA Server Help file (under Microsoft
ISA Server -> Multi-Networking -> Multi-Networking Architecture) provides a good definition of a “Network”.
- ISA Server groups IP addresses into sets, called networks. A network is used by ISA Server to describe addresses of hosts that can exchange traffic without passing through ISA Server.
That last sentence is critical to understanding how ISA views the network – since the .0, .10, .20 and .30 subnets can communicate among themselves without “traversing” ISA Server, they should all be considered a part of the same network.
OK – that makes sense – how do I control access to the .10, .20 and .30 subnets then?
Once all of these address ranges are included in the Network, you should go into the Firewall Policy -> Toolbox -> Network Objects and create new “Subnets” for the .0, .10, .20 and .30 subnets and then create Firewall Policy Access Rules that apply to the Subnets instead of the “Network”.
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=000080 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.
