2

I have users who constantly travel outside the office.

Internally, they have mapped network drives.

They then go outside and connect via VPN which when connected bridges and puts them on the same subnet. They can ping resources on the network over the VPN without any issue.

When they try and connect to the same network drive by name it takes a long time to connect and then says the share name cannot be found.

The particulars are as follows:

  1. Internally, everything works fine
  2. I am running WINS on the server to which they are trying to connect.
  3. This WINS server is provided in the DHCP options for VPN clients
  4. DNS is provided in the DHCP option for VPN clients For adapter bindings
  5. On Windows 7 clients network adapter properties I have ensured Remote Connections are the top priority over local connections
  6. If connection by IP address is used, it works, but fails when connecting by machine name

What other steps should I try to resolve the above?

2
  • 2
    First, why are you still using WINS? Do you have old servers or clients on the network? Second, if you run nslookup commands over the VPN connection to your servers what results, if any, do you get? Aug 30, 2012 at 12:32
  • 1
    It's a WINS or DNS issue. If you can, get rid of WINS and see if that fixes it, if not, troubleshoot both. Most common causes of this type of issue I see are 1) split-DNS setups using external DNS servers to look up internal servers and 2) the wrong or no DNS suffix being appended to non-qualified hostnames. So, I'd look at those two things first. Aug 30, 2012 at 15:48

3 Answers 3

2

Are you being careful to use the same naming when troubleshooting as when connecting to the network share? For example, are you pinging:

ping servername.domain

But connecting to a server share:

\\servername\share

If you're able to ping with a fqdn, try setting up the user's network shares the same way. I've seen issues before where not specifying the domain name when on VPN tries to access the user's local network instead.

I'm also curious if you're getting an external IP when pinging the network resources. I've seen VPN connections to a network that's Windows domain is also the company's website, and pinging servername.domain.com ends up getting a result from a catch-all web server instead of the internal resource.

0

The obvious stuff first: In cases where this happens, is there significant packet loss over the VPN connection? Try pinging with increased packet size:

ping -l 1200 servername.your.internal.domain

I have made bad experience with even minor (~1-10%) packet loss and lots of TCP retransmissions on the connection that carries the SMB payload (ports tcp/445 and tcp/139 on the server side).

The other one is the name resolution: First workaround would be to try a network connection using the server's IP adress instead of the name. So let someone try

net use X: \\10.0.1.200\sharename

and watch if that goes through.

If that "fixes it", watch name resolution closely. Not sure about WINS, but maybe deconfigure that and try to rely on DNS. What is the primary and secondary DNS nameserver (ipconfig /all)? check if they both provide the right IP address:

nslookup servername.your.internal.domain 10.0.1.1
nslookup servername.your.internal.domain 10.0.1.2

(10.0.1.1 and 10.0.1.2 would be the DNS servers)

Maybe Windows tries a connection over IPv6 and that is silently dropped? Try to temporarily disable the IPv6-protocol on the active adapters.

Good luck!

-2

A quick and dirty way to fix this would be to use the hosts.ini file.

Location:

\Windows\system32\drivers\etc\

Make sure you edit as an administrator on the machine.

Start at the bottom and add the servers they need to connect to. Type in the PRIVATE IP address, hit tab, then type in the Fully Qualified Domain Name (FQDN) Then save.

The user should now be able to connect to the server using the name.

If you would rather not use the Hosts.ini file, then check into how the remote machine is handling DNS. More than likely this is where the issue is.

1
  • 1
    No, no, no, no, NO! First of all, don't use the hosts file, and second of all, you'll be searching until the end of the world if you're looking for hosts.ini (Not to mention that editing hosts.ini won't help in the slightest anyway). Aug 30, 2012 at 15:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .