Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 344
  • Last Modified:

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
0
stuart100
Asked:
stuart100
  • 4
  • 2
1 Solution
 
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
Who's Defending Your Organization from Threats?

Protecting against advanced threats requires an IT dream team – a well-oiled machine of people and solutions working together to defend your organization. Download our resource kit today to learn more about the tools you need to build you IT Dream Team!

 
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
 
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

Featured Post

Who's Defending Your Organization from Threats?

Protecting against advanced threats requires an IT dream team – a well-oiled machine of people and solutions working together to defend your organization. Download our resource kit today to learn more about the tools you need to build you IT Dream Team!

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now