stuart100
asked on
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
Error-Message.jpg
beester
Can you access it if you use the FQDN in the UNC path, i.e. \\computername.domain.tld\
http://support.microsoft.com/kb/899268
Take a look at that as well, I see you're using Windows 2000 servers.
Take a look at that as well, I see you're using Windows 2000 servers.
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
That sounds very unlikely to be the source of this exact problem?
ASKER
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.
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...
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...