Name resolutions over VPN

I have created a VPN server in our office using Windows 2003 Standard Edition. The clients all run Windows XP Professional. The server assigns IP addresses to tbe client from a pool of addresses. At the VPN server the private NIC is configured to use the internal DNS server and the public NIC is not assigned any DNS server at all. The internal DNS server is configured as a forwarder. From the VPN server I can ping any computer on the internal network by name with no problem at all. When the client computer connects it is unable to resolve computer names. I can ping by IP address, but not by name. IPCONFIG shows that the VPN connnection has been assigned the DNS server on the internal network. When I try to ping or do nslookup to a computer name on the internal network it is resolving to a public IP address. Can anyone help me, please??
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.

Rob WilliamsCommented:
Name resolution over VPN's is a common issue, however if the clients are assigned you DNS server properly I am surprised you are having problems, unless the VPN client also has the local ISP's DNS, in which case it may be solving using that first, even though it is not the primary DNS server. Following are ways to deal with accessing resources over a VPN. You can ignore the first regarding using IP's

NetBIOS names  (computer names) are not broadcast over most VPN's.
You can resolve this in several ways:
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 ]

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
rcg112355Author Commented:
Actually, I had pretty much done all of the things that you suggested. It is a small network so I eneded up adding the important static address to the HOSTS file.

However, I did run into another problem. The internal network behind the VPN has a subnet of 192.168.1.x. Of course this is pretty popular for home networks as well. So if one of them connects to the VPN and they share the same subnet the client is unable to see the VPN network at all. It can't even ping by address.

I changed the subnet on the two remote users, but I realize that is not the ultimate solution. What happens when the company owner is sitting in a hotel and can't browse his network?? I guess the best solution is to give them a more unique subnet internally such as 172.16.x.x. That should dramatically reduce the chance for a conflict.

Do you have any other suggestions??

Rob WilliamsCommented:
Hosts file works very well, but a bit of a pain. If you can set up a WINS server it often works better, and is dynamic.

As for the IP addressing, it is a common problem and only solution is to change the corporate Subnet, though that can be a big project on some networks. 172.16 is a great choice, but I would still avoid 172.16.0.x  I usually use something like 192.168.ab.x where ab is the last 2 digits of the client's street address just so I can remember who is who <G>

If by any chance your users only need access to the RRAS server, and no other PC's or servers, as a rule if the "use default remote gateway" option is checked on the VPN client (it is by default), they should be able to connect to that server only with the remote and local subnets the same.

Thanks rcg112355,
rcg112355Author Commented:
I thought that I was using the WINS Server. I was assigning the WINS address to the dynamically assigned IP's, but failed to configure it on the static IP's. What a rookie mistake!!

Unfortunately, they do need to connect to computers beyond the RRAS, so it looks like I will be changing subnets this weekend.
Rob WilliamsCommented:
DHCP for VPN clients is a little odd. It only passes the IP, gateway, and subnet mask. There is an other alternative; you can use the DHCP relay agent with-in RRAS. This requests an IP from the "normal" DHCP server and therefore inherits more of the scope options, such as WINS. You can't use DHCP reservations with this method, and I don't know what happens if you use this method and assign static IP's in the user profile in conjunction with the DHCP relay agent, but would be interesting to test.

Regardless,sStill need to change subnets.
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.