Hello,I have a problem with one of my servers that showed up after having to switch it's IP address. It's running Windows Server 2000. It's utilized as our web server. This machine is in my DMZ and all firewall rules (Cisco Pix) have been updated and internet connectivity is working. This problem did not exist prior to the change in IP and nothing else was changed on this machine.The problem I'm having is that I am unable to map a drive (either through the Windows interface or the Net Use command) to this machine from any computer (inside or DMZ). When using 'net view' from another machine in the DMZ, the machine shows up in the list for that workgroup. When I do a net view \\server, I get: "System error 53 has occurred. The network path was not found."I have it in our internal DNS server with the correct IP.I am able to ping the machine both by name and IP from inside and DMZ, as well as perform a nslookup successfully.I have tried mapping using the name as well as the IP and both give the same error.I am able to map drives to any other computer in the DMZ from inside or other DMZ.I can also map a drive from the machine in question to other machines in the DMZ.File and print sharing is enabled.I'm about out of ideas to track down the problem.Any ideas would be greatly appreciated.Thanks,Chris

Hmmm. What happens if from that machine you \\127.0.0.1 Do you see the shares?Miguel Fra www.falconits.com

Hi chris, thanks for posting in windows networking forum, i would like to check if ports 139 and 445 are opened ?as a test what happens when you disable the firewall and try mapping a driveare you able to access the shares ? \\ipaddress \\fqdn \\netbiossainath !analyze

Hi chris, i am following up to know if you had a chance to go through the earlier suggestions and if it were helpful.sainath !analyze

When I go to the loopback address while on the machine, it shows the shared folders.

Sorry for the late reply.When I telnet to that IP with those ports, the connection failed.There is no local firewall installed. I'll recheck the pix ACL, but I haven't been able to see any differences in the ACL compared to before the IP address change.

Sorry for the late reply.When I telnet to that IP with those ports, the connection failed.There is no local firewall installed. I'll recheck the pix ACL, but I haven't been able to see any differences in the ACL compared to before the IP address change. OK, so if you can \\ipaddress or \\loopback from the machine itself and you can view the shares... 1. double check the firewall settings and packet filter rules2. use \\ipaddress instead of NBname to eliminate static entries in hosts or lmhosts pointing to the wrong machine3. check for remembered connections to previous shares affecting user name and password on the machine you are mapping from4. check that there are no third party firewalls running on the machine5. Check the network bindingsMiguel Miguel Fra www.falconits.com

1. I've looked at the firewall again and none of the access rules have changed for this machine.2. I have been using the IP and not the name to troubleshoot this problem.3. No drives were mapped to this machine from machines I am testing from before the IP change occurred, so that shouldn't be an issue. I did delete the folders that show up under the Network Places under XP.4. There are no firewalls on this machine.5. The network bindings look correct. This machine has dual Broadcom NIC cards that are set up in a teaming arrangement, allowing for failover and load balancing. This has not changed since the machine went into service.Chris

1. I've looked at the firewall again and none of the access rules have changed for this machine. 2. I have been using the IP and not the name to troubleshoot this problem. 3. No drives were mapped to this machine from machines I am testing from before the IP change occurred, so that shouldn't be an issue. I did delete the folders that show up under the Network Places under XP. 4. There are no firewalls on this machine. 5. The network bindings look correct. This machine has dual Broadcom NIC cards that are set up in a teaming arrangement, allowing for failover and load balancing. This has not changed since the machine went into service. Chris Hi, Check both the physical and the Virtual adapter address NIC is correct. At this point, knowing that you are running NLB (i'm guessing you are using NLB, and I am not an expert at it!!) and this whole thing happened when the IP address changed, my guess is the bindings or IP addresses related to NLB could be the problem. Are you using a VLAN switch? Have you cleared the hardware ARP tables? Try power cycling any switches, hubs, routers to cleare their memory. Other than that, I am stumped and out of suggestions. If I come up with any more ideas I'll post back. Miguel Miguel Fra www.falconits.com

I'll try power cycling the switches after the office closes this evening. Just wouldn't think that would be a problem since none of the other machines are affected. I've double checked the IP address information in the teaming setup and everything is correct. No VLAN.I'll let you know the results after I'm able to power cycle.Chris

No joy.Power cycling the switches had no affect.Chris

Wow! I am stumped. * What says the server's log files after the connection is denied/blocked? Something has to show up in the logs otherwise the connection never reaches the server. * TCP/IP Filtering on the Network Card properties? * Are you running RRAS? If so, is Windows Firewall properly configured? * What if you http://privateIP or http://host.domain.local from a workstation, does it display the default web page? Miguel Miguel Fra www.falconits.com

I've been stumped since this happened as well. I've been hoping that it was something stupid that I overlooked and someone could point it out to me, but so far it's been extremely perplexing.The event viewer doesn't show anything about failed attempts to reach. I have run wireshark on both sides and the microsoft-ds traffic is not making it to the problem machine. Tracert shows the correct information for the machine/IP.TCP/IP filtering is not enabled.I'm not running RRAS and there is no windows firewall as this is Windows Server 2000 which was did not have the windows firewall as part of the OS.We have the default webpage stopped, but I did start it briefly and am able to get to the page from the same machine that is unable to map a drive to it. I can get to any of the other websites on the machine either from external or internal IPs.Chris

Hi, Sounds lik the traffic on the ports mentioned by Sainath are being dropped by the filter rules or not opened for business. Try settting up the two machines side by side with static IP's and a simple layer 2 switch and I bet you will be able to map the drive! Or, try replacing the PIX with a simple router after hours just as a process of elimination, but I am willing to bet it's the PIX config! MiguelMiguel Fra www.falconits.com

Hi Falcon ITS ,Thanks for following up with chris, the issue seems to be wierd , and chris as i mentioned the above ports needs to be opened for the file share to work across the network.can you please check the behavior in safe mode with networking ?also i would like you to take a ethereal / netmon capture and then reproduce the issue so that we can analyze the packets. also make sure you do not have faulty NIC ( might sound funny but many a times these are real pain )sainath !analyze

Hi Falcon ITS ,Thanks for following up with chris, the issue seems to be wierd , and chris as i mentioned the above ports needs to be opened for the file share to work across the network.can you please check the behavior in safe mode with networking ?also i would like you to take a ethereal / netmon capture and then reproduce the issue so that we can analyze the packets. also make sure you do not have faulty NIC ( might sound funny but many a times these are real pain ) sainath !analyze Hi All,I also agree that this is weird. I think it may be the firewall for the following reasons:1. Fiddler mentioned that none of the ACL rules have changed on the firewall. However, IF the packet filter rules by default onlyallow traffic on common ports like80, 53, 443, between hosts, then 139 and 445 have to beallowedby either setting up a new rule or by altering the existing rule after the IP address change. For example, if the rules:FROM ->LAN TO ->hostSERVICE 139-> allow FROM ->LAN TO ->hostSERVICE445-> allow FROM ->DMZ TO ->hostSERVICE 139-> allow FROM ->DMZ TO ->hostSERVICE445-> allow If these rules haveNOT beenaltered AFTER the IP address change where the IP address of host has been updated on firewall, then that could be the problem.2. WhenFiddler Telnets to the problemsystem using 139 and 445, the connection fails3. There is no log file on the server generally this would indicate that the connection attempt never got as far as the serverThe easiest way to eliminate this possibility is to put the machines separate, side by side on a switch and let layer 2 handle their traffic. Also, as Sainath mentioned, packet capture is a great idea and will give a better view of what's going on.Miguel Miguel Fra / Falcon ITS Computer and Network Service and Support, Miami, Fl

Hello, Any news? I am curious about what happened. Miguel FraMiguel Fra www.falconits.com

Sorry about the delay. I've been overtaken by events here in the office. I hope to get back to this soon. Unfortunately, I'm an IT team of 1 and often spread pretty thin.Thanks for following up. I'll let you know what happens when I'm able to get back to this.Chris

Hey all,I finally got things under control in the office and got back to this.I now have access working again. The problem? Can you say Symantec?Turns out the Symantec package corporate gave to me had a firewall buried down inside it. Once I knew that and was able to get down to it, I was able to add rules to allow ports 139 and 445.I want to thank everyone that tried to help me out on this issue.Thank you,Chris