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

Post a Comment

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...
Post a Comment
Read more

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.
Post a Comment
Read more

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...
Post a Comment
Read more