Skip to main content

Network Behind A Network

If you find an error in ISA server event viewer like below then read the below article and it will help you understanding the problem.


Event ID14147
SourceMicrosoft Firewall
TypeError
Description
ISA Server detected routes through adapter "" that do not correlate with the network element to which this adapter belongs. The address ranges in conflict are: -;. 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.

Network Behind A Network
By Clint Denham

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
Default Gateway: 157.57.157.1 ================================================== ====================Persistent Routes:None

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 MicrosoftISA 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".

Copied from
http://www.isaserver.org/pages/article.asp?id=1278

Comments

Popular posts from this blog

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Recreating a VMFS-3 or VMFS-5 partition table in ESXi 5.x

For this kind of issues you need to engage VMware support on this, following any part of this article could lead to more complex situation if not ran by an expert.   Symptoms Datastore does not mount because of a lost or overwritten partition table.   Purpose When a VMFS partition is created in ESX 3.x or ESX 4.x, it has a Master Boot Record (MBR) partition map. The MBR is written to the first 512 B block (LBA0) and contains the information where the (VMFS) partition starts and ends. ESXi 5.0 introduced VMFS-5, which uses a GUID partition table (GPT) for new datastores. When a VMFS-3 partition is created in ESXi 5.x and is later updated to VMFS-5, the original partition map (MBR) is maintained. If the partition information of a VMFS datastore is deleted or overwritten (for example, by a Windows system with direct access to the same disks), it is impossible to determine if the partition map was GPT or MBR. The only time you can be sure that a GPT partition map was used is if th...

How to deploy an OVA in Cloud Director

  How to deploy an OVA in Cloud Director Yesterday I was in a call with a customer and we discussed uploading OVA’s into Cloud Director. I said sure that is no problem at all. Well then I started thinking how are you supposed to deploy an OVA in Cloud Director because I do not even remember how this is done. So I opened up Cloud Director and tried it for myself. I decided to make this blog post along the way to show you how to deploy an OVA in Cloud Director. As an added bonus I will also show you how to upload an OVA to the catalog. This way I can deploy the OVA over and over again. Environment information Cloud director 10.3 OVA How to deploy an OVA in Cloud Director In Cloud director I opened up the Applications section and selected “NEW” I am deploying an OVA so I selected “Add vApp From OVF”. In the screenshot below you can see all the steps involved with (in my case) deploying and customising the Usagemeter. Options to customise are for instance: Network settings, vApp naming...