Name resolution in VPN connection

I am having an issue with name resolution while connected through a vpn. I have remote sites that connect to a main office through MS VPN connections. They connect to one of two boxes. One is a Windows 2k server and one is a Windows 2k SBS server. I think this is a name resolution issue because after connecting I can sometimes ping FQDN of various servers and sometimes I can not. I assign IP addresses via DHCP and also assign a DNS server and WINS server at time of connection. The DNS and WINS server assigned are the internal IP addresses of the SBS box (which, by default, is the PDC). This issue seems to happen more on Windows 2K box connections, but does happen sometimes on the SBS box as well. And what happens alot is when I initially connect I get name resolution, but then it fails after just a couple of minutes. I am not even able to ping the server that the vpn connection is made to.

budmanludnetwork adminAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

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.

Rob WilliamsCommented:
Name resolution over VPN's is a common problem as NetBIOS names are not normally broadcast over a VPN. I am surprised adding the WINS server IP has not resolved for you. Have a look at the list below concerning name resolution workarounds.
You should be able to connect and ping consistently using the IP of the remote device. If this is not the case you may have other issues. Dropped connections are often due to, too high an MTU (Maximum Transmission Unit) packet size. The following sites outline the problem, how to test and adjust. If you decide to make changes, the MTU should be changed on the connecting PC and it's local router:

NetBIOS name workarounds:
1) Use the IP address (of the computer you are connecting to) when connecting to devices such as;   \\\ShareName   or map a drive at a  command prompt using  
 Net  Use  U:  \\\ShareName
2) An option is to use the LMHosts file which creates a table of IP's and computer names. LMHosts is located in the Windows directory under c:\Windows (or WINNT)\System32\Drivers\Etc\LMHosts.sam , instructions are included within the file. Any line starting with # is just a comment and is ignored. Open the file with Notepad and add entries for your computers as below;      CompName       #PRE
Hit enter when each line is complete (important), then save the file without a file extension. To be sure there is no extension ,when saving enclose in quotations like "LMHosts". Now when you try to connect to a computer name it should find it as it will search the LMHosts file for the record before connecting.
More details regarding LMHosts file:
The drawback of the LMHosts file is you have to maintain a static list of computernames and IP addresses. Also if the remote end uses DHCP assigned IP's it is not a feasible option. Thus in order to be able to use computer names dynamically try to enable with some of the following options:
3) if you have a WINS server add that to the network cards configuration
4) also under the WINS configuration on the network adapter make sure NetBIOS over TCP/IP is selected
5) try adding the remote DNS server to your local DNS servers in your network card's TCP/IP configuration
6) verify your router does not have a "block NetBIOS broadcast" option enabled
7) test if you can connect with the full computer and domain name as  \\ComputerName.domain.local  If so, add the suffix DomainName.local to the DNS configuration of the virtual private adapter/connection [ right click virtual adapter | properties | TCP/IP properties | Advanced | DNS | "Append these DNS suffixes (in order)" | Add ]

budmanludnetwork adminAuthor Commented:
I am using a hosts file on the client machines that points to various servers on our office network. In the client offices, no servers exist. So should I add the WINS server IP address to the network cards/vpn connections on the client machine of the WINS server in our main office? I will test the MTU settings idea. The thing is, I am showing that I am still attached through the vpn but lose all name resolution.
Rob WilliamsCommented:
>>"I am using a hosts file on the client machines that points to various servers on our office network."
Hosts file will work although technically you should be using the LMHosts file.
You might want to verify your Hosts/LMHosts file entries are functioning. At a command prompt enter
  nbtstat  -R
to purge and reload the local name cache
then enter
  nbtstat  -c
to display the current name cache which should include your LMHosts file entries.
Note; the nbtstat "switches" R & c are case sensitive.

>>"So should I add the WINS server IP address to the network cards/vpn connections"
Assuming you are using the built in Windows VPN, add the WINS server IP address to the DHCP scope, under DHCP scope option #044  You should also add your SBS, the DNS server to option #006 and the domain name, such as MyDomain.local to option #015. This will automatically assign the necessary parameters to your VPN clients, assuming you are assigning IP's with DHCP (the default option).  Keep in mind WINS is only useful if you have enabled the WINS service on your server.
SolarWinds® VoIP and Network Quality Manager(VNQM)

WAN and VoIP monitoring tools that can help with troubleshooting via an intuitive web interface. Review quality of service data, including jitter, latency, packet loss, and MOS. Troubleshoot call performance and correlate call issues with WAN performance for Cisco and Avaya calls

budmanludnetwork adminAuthor Commented:
After doing the first nbtstat command you suggested, I get no names in cache when I do the second (nbtstat -c). My file is hosts and is in the windows\system32\drivers\etc directory. Does this mean it is not working? And if so, what should I do to fix this?
Rob WilliamsCommented:
Sounds like it is not working. There are a few oddities about those files. First I would recommend removing your entries from the Hosts file and using the LMHosts file in the same folder. The Hosts file is intended for DNS names such as  where as LMHosts id for NetBIOS names such as your computer names. Make note of these requirements:
-The LMHosts file, if it has not been used, has a .sam extension (sample). When you save it, save without an extension. To be sure of this save with quotations...   "lmhosts"
-Using the PRE option as per the instructions in the file pre loads the names for faster resolution. If you choose to use this option PRE must be capitalized
-you must hit the return key after entering a line, before saving (very important)
-and #'s are comment lines

Then again test by running:
  nbtstat  -R
to purge and reload the local name cache
then enter
  nbtstat  -c
to display the current name cache which should include your LMHosts file entries.
Note; the nbtstat "switches" R & c are case sensitive.

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
budmanludnetwork adminAuthor Commented:
I changed the MTU and redid the LMHosts file. The nbtstat -c does come back with my lmhosts file. But I am still having problems. I am thinking that there must be something else that is causing either packets to drop or some other networking issue. I am awarding you the points since you showed me some new stuff.
Rob WilliamsCommented:
Thanks budmanlud.

MTU can definitely cause some dropped connections, though it shouldn't affect name resolution, unless not connected of course. Following links may be of some help explaining the problem, how to test, and how to change. Keep in mind should be set on the client machine and on their local router. PPTP VPNs need to be set to 1430 or lower if setting it manually.

Good luck,
budmanludnetwork adminAuthor Commented:
Microsoft says that by default VPN connections are at 1400 MTU. And by following the directions, that is what the optimal setting is on the client machines. And there never seems to be a dropped connections from the machine vpn'd into. Just lose Exchange connections and shared folder connections. Could this be server rather than client related?
Rob WilliamsCommented:
>>"Microsoft says that by default VPN connections are at 1400 MTU. "
Actually MS default is 1500
Recommended for PPPoE connections 1492
Recommended PPTP VPN connections 1430
Lower is fine.
However in most cases Windows and the router automatically adjusts quite satisfactorily.
Here is a list if interested:

>>"Could this be server rather than client related?"
Hard to say, but I would think if it was server related some local/LAN users would loose their connection.

Do you have a keep alive option on your router. Try enabling that, especially if a PPPoE connection.
I have a client with SBC in the US that after considerable testing we discovered she looses her connection for 2-120 seconds up to 10 times a day. So on occasion it can be ISP related.
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

From novice to tech pro — start learning today.