Windows 2003 Routing Issue

We are having a problem with routing on the following server, 172.21.106.1 (servera).  I am trying to access a share on the following server, 172.21.122.57 (serverb). When I attempt to connect to the server, the traffic is being passed over the back side interface.  

From the server when I attempt to hit \\serverb\share

C:\Documents and Settings\user>netstat -an | find "122.57"

  TCP    172.21.95.56:1532      172.21.122.57:139      SYN_SENT

There are no static routes for this subnet on the server, therefore the default gateway should be used to reach the 122 subnet:

C:\Documents and Settings\user>route print

IPv4 Route Table
===========================================================================

Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 50 56 ac 68 72 ...... VMware PCI Ethernet Adapter
0x10004 ...00 50 56 ac 43 03 ...... VMware PCI Ethernet Adapter #2

===========================================================================
===========================================================================
Active Routes:

Network Destination        Netmask          Gateway       Interface  Metric

0.0.0.0          0.0.0.0   172.21.106.248     172.21.106.1      1
10.32.8.2  255.255.255.255   172.21.106.248     172.21.106.1      1
127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
172.21.95.0    255.255.255.0     172.21.95.56     172.21.95.56     10
172.21.95.56  255.255.255.255        127.0.0.1        127.0.0.1     10
172.21.106.0    255.255.255.0     172.21.106.1     172.21.106.1     10
172.21.106.1  255.255.255.255        127.0.0.1        127.0.0.1     10
172.21.106.100  255.255.255.255        127.0.0.1        127.0.0.1     10
172.21.255.255  255.255.255.255     172.21.95.56     172.21.95.56     10
172.21.255.255  255.255.255.255     172.21.106.1     172.21.106.1     10
224.0.0.0        240.0.0.0     172.21.95.56     172.21.95.56     10
224.0.0.0        240.0.0.0     172.21.106.1     172.21.106.1     10
255.255.255.255  255.255.255.255     172.21.95.56     172.21.95.56      1
255.255.255.255  255.255.255.255     172.21.106.1     172.21.106.1      1
Default Gateway:    172.21.106.248

===========================================================================

Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
10.32.8.2  255.255.255.255   172.21.106.248       1

Also, bear in mind, the 106.x NIC has presedence over the back side NIC in the binding order.

Heres where things get interesting.  I run a tracert to the IP, and the route is learned.  

C:\Documents and Settings\user>tracert 172.21.122.57

Tracing route to serverb [172.21.122.57]
over a maximum of 30 hops:
 1    <1 ms    <1 ms    <1 ms  172.21.106.248
 2    <1 ms    <1 ms    <1 ms  172.21.96.248
 3     1 ms    <1 ms    <1 ms  serverb [172.21.122.57]

Now when I hit the UNC, the frontside interface is used&

 C:\Documents and Settings\user>netstat -an | find "122.57"

TCP    172.21.106.1:1727      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1731      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1734      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1737      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1740      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1743      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1746      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1749      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1752      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1755      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1758      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1761      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1764      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1767      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1770      172.21.122.57:139      TIME_WAIT
TCP    172.21.106.1:1773      172.21.122.57:139      ESTABLISHED

Have anyone ever seen anything like this before?  I need the frontside interface to be used, always.  This is happening on multiple servers on this subnet (172.21.106.3).   Are we missing some static routes?  

Thanks!
LVL 23
Justin DurrantSr. Engineer - Windows Server/VirtualizationAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

from_expCommented:
does network card with 95.0 and 122.0 located within one physical subnet
is it possible they are trying to reach each other via netbios?
0
Justin DurrantSr. Engineer - Windows Server/VirtualizationAuthor Commented:
Nope.. the subnets are different. I am not sure if netbios is being used between .95 and .122. I can say that the .95 nic has netbios set to "default". The .106 nic has "netbios over TCP\IP enabled".
0
Rob WilliamsCommented:
I may be wrong, happened lots of time in the past, but something looks funky with your route print. Specifically the following 3:
172.21.106.100      255.255.255.255      127.0.0.1      127.0.0.1
172.21.255.255      255.255.255.255      172.21.95.56      172.21.95.56
172.21.255.255      255.255.255.255      172.21.106.1      172.21.106.1

I would check your subnet masks carefully, on both host and guest systems. Not sure what would cause that.  Also where does 172.21.106.100 come from?
I would expect to see:
Destination         Netmask             Gateway         Interface      
0.0.0.0                 0.0.0.0             172.21.106.248  172.21.106.1
127.0.0.0                 255.0.0.0             127.0.0.1        127.0.0.1
                  
10.32.8.2                 255.255.255.255 172.21.106.248  172.21.106.1
                   
172.21.95.0        255.255.255.0      172.21.95.56        172.21.95.56
172.21.95.56      255.255.255.255  127.0.0.1        127.0.0.1
172.21.95.255    255.255.255.255  172.21.95.56        172.21.95.56
                  
172.21.106.0      255.255.255.0       172.21.106.1        172.21.106.1
172.21.106.1      255.255.255.255   127.0.0.1        127.0.0.1
172.21.106.255  255.255.255.255   172.21.106.1        172.21.106.1
                  
224.0.0.0                  240.0.0.0               172.21.95.56        172.21.95.56
224.0.0.0                  240.0.0.0               172.21.106.1        172.21.106.1
255.255.255.255 255.255.255.255  172.21.95.56        172.21.95.56
255.255.255.255 255.255.255.255  172.21.106.1        172.21.106.1

I agree the default gateway should look after it, but have you tried a static route as a test to force it?
route add 172.21.122.57 mask 255.255.255.255 172.21.106.248

Just as a long shot, under adapters and binding, you mention the order is correct, but also verify File & Print Sharing  & TCP/IP is bound to the adapter.
0
Top Threats of Q1 & How to Defend Against Them

WEBINAR: Join WatchGuard CTO and our Threat Research Team on Aug. 2nd to hear the findings from our Q1 Internet Security Report! Learn more about the top threats detected in the first quarter and how you can defend your business against them!

Justin DurrantSr. Engineer - Windows Server/VirtualizationAuthor Commented:
the question is, why is the Windows box choosing the wrong interface?  I dont know.   In this scenario, the remote system has not yet entered the equation, as if on the source I run a tracert prior to attempting to access the SMB share, the source Windows box follows the appropriate route and reaches the system (gateway 106.248).  This removes any misconfiguration at the IP stack level.  If the mask were wrong on either side, this would never work.

What should happen, the mask on the source server /24, includes the entire class C subnet 106.x, anything outside that subnet must pass through the default gateway (excluding static routes).  In this case 122.x is on another subnet, which would require the gateway to be used to reach that subnet.  Why the Windows server is selecting the backup interface as the first path, is not clear.  

To answer your questions:
1.    106.100 is another address bound to the server, that is why you see it in the route print

2.    If File and Print sharing were not bound to the correct adapter, I would never reach the share, which I can, after Windows uses the correct interface.

Thanks!
 

0
Rob WilliamsCommented:
Agree with your logic 100%. I guess my key point was the route print looks odd. If there is a problem you may get unexpected results.
0
Justin DurrantSr. Engineer - Windows Server/VirtualizationAuthor Commented:
Also, static route does not work.. but disabling the backup nic does. WTF. :)

0
Rob WilliamsCommented:
As mentioned can you fix the route table, by verifying all adapter configurations? There appear to be overlapping subnets, which can result in unpredictability.
I have no other suggestions. Perhaps others will.
--Rob
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Rob WilliamsCommented:
Thanks jjdurrant.
Cheers !
--Rob
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Hardware-Other

From novice to tech pro — start learning today.