VPN issue \ Windows sharing

We have an office in India and they currently can not access our servers.  I can from my office which is configured the same way...  There is a Site to Site VPN tunnel and they can ping the ip of the servers they need access to.  Once they go to the server via the run line and ip address ex: \\172.19.20.36 they see the shares and printers but when they open on the of the shares they get the attached error.  I now have 60 people there that can not work any help would be great.
Error-Message.jpg
stuart100Asked:
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.

beesterCommented:
Can you access it if you use the FQDN in the UNC path, i.e. \\computername.domain.tld\share?
0
beesterCommented:
http://support.microsoft.com/kb/899268

Take a look at that as well, I see you're using Windows 2000 servers.
0
Texas_BillyCommented:
Tags on this issue indicate that you're using a Cisco vpn solution for the site-to-site tunnel(s) and Windows 2000 servers that they can't see.  Considering they can ping the server(s) in question, the vpn tunnel is ok.  You've probably got a DNS issue here.  

When they ping the servers, can they be pinged by fqdn, or just by IP?  What is your cisco solution, what are the endpoints?  For instance, if you're using ASA on each end, it could be that you just need to enter the "no sysopt proxyarp" command on the wan interfaces of the endpoints.  If you're using routers with IOS firewall, you just need to specifically enter the "permit udp host x.x.x.x host x.x.x.x eq 500" on the inbound access-lists of each endpoint because ISAKMP is breaking down after tunnel creation, i.e., as soon as the phase II starts transmitting.   As that point, inbound ACLs will kill traffic going through an already established tunnel as soon as it's decrypted; i.e., traffic can't find it's way back to hosts.  Also verify you've got proper DNS forwarding set up, assuming these clients are using local DNS servers.  Because this is a site-to-site tunnel, there's no process giving clients at site B any information about hosts at site A - no DNS servers are being handed out to remote hosts, they're using local DNS.  If local DNS servers don't know about hosts on the remote end, they can only resolve by IP because that's all that the Cisco equipment knows about, it has no idea what server names are, nor shares.  If you've got a VPN concentrator in there, myriad things could cause this.  --TX
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

stuart100Author Commented:
We found out the issue was caused by an ISP called seabone that handles the fiber that runs through the Atlantic ocean.  They were having issues with a router that was dropping packets.  We have never seen anything like it and ended up having to have our ISP call them to track down the issue.

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
beesterCommented:
That sounds very unlikely to be the source of this exact problem?
0
stuart100Author Commented:
beester I apologize if you don't like my answer.  Tell you the truth I did not like it either and I really believe they or one of the many other ISPs that the data travels through had an issue that they are just not admitting to.  I assure you the problem is fixed and I did not make any configuration changes on either side.  We had Microsoft, and Cisco check it out and both ended up looking at the issue and telling me it was not their problem so we moved onto the ISPs.  Once we made a bunch of noise at both of them they started making calls and bam the problem went away.  First time in 15 years I want to quit... tough to have an issue that affects 8 hours of production that you still do not have a clear answer about.

0
beesterCommented:
It's not that I don't like YOUR answer :)  I just don't exactly see how this would be the issue since other services worked in the VPN tunnell, whereas packet loss would cause the VPN tunnel to drop...

And that's why I don't think it sounds likely that packet loss is what caused this problem at all, but more like you say - that the ISP(s) have had other, underlying problems, which caused it...
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
Windows 2000

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.