Trouble with DNS/NetBIOS name resolution over VPN

Question

_{Monday, December 30, 2013 9:19 PM}

I’ve got one for the DNS/WINS gurus out there who are also familiar with VPN connections.

We have a VPN setup on our Mikrotik RouterBoard 532 for a number of employees running Windows 7 Pro laptops. Unfortunately the Mikrotik is maintained by our ISP so I don’t have access to it, but I can call them to make changes. Anyhow, I do not believe it is a problem with the Mikrotik.

The problem is with resolving NetBIOS names (UNC paths, drive letters, etc…) over the VPN from remote locations, and ONLY with laptops joined to our abc.local domain. If I use my home PC or disjoin the domain laptop from the abc.local domain and return it to WORKGROUP, keeping the same Windows VPN client settings, I am able to resolve paths just fine.

For example, when I type \server1 from Start>Run, it fails and tells me “server1 is not accessible. You might not have permission to use this network resource.” Using the FQDN is no problem at all, which makes me believe the problem is with NetBIOS resolution and takes me to the WINS servers on the network.

The VPN hands out primary and secondary WINS servers, and they appear to be configured correctly in our Server 2003/2008/2012 environment. When I run nbtstat –A IPAddressOfLaptop from a WINS server it resolves the laptop, and the same command from the laptop looking to the server resolves OK too.

What’s strange is that when I ping “server1” I get a valid response from server1.abc.local, as expected, but for some reason I still can’t browse to it from start>Run… “\server1”.

The DNS suffix abc.local is in the “DNS suffix or this connection” field in the properties of the VPN client since the Mikrotik VPN is unable to deal this to clients.

I have ruled out Group Policy as the culprit because even after removing any group policy from applying to one of the laptops the result was the same.

I’ve used every resource and tool that I could to try and find where the problem lies and can’t seem to solve it. Everything looks properly configured.

I would greatly appreciate some assistance!

All replies (7)

_{Thursday, January 2, 2014 8:07 PM ✅Answered}

Ace,

More and more this looks like a cached credential problem in Windows. Following the advice from others experiencing similar issues (see here, here and here), all I have to do to get NetBIOS-named connections restored is run the command cmdkey /delete /ras. Immediately after running the command I can access those resources using \server1 without ".domain.local". This also tells me there’s no problem with WINS or DNS, as I first suspected. And to answer your questions, yes there are WINS servers listed and a connection-specific DNS suffix of domain.local. The VPN client is the Microsoft Windows 7 client. DHCP is on the Mikrotik. Again, I can ping NetBIOS names and they resolve the FQDN so name resolution seems OK. Unfortunately, I have to run the cmdkey /delete /ras command each time I connect to the VPN and I would have to instruct everyone to do the same. I was hoping to find a server-level setting or policy that I could push to fix this but from what I’m finding there doesn’t seem to be one. Any ideas?

_{Thursday, January 2, 2014 8:31 PM ✅Answered}

As I hought resolution is fine. Four options:

1. Use Windows RRAS for the VPN server
2. Configure the Microtik to use AD accounts
3. Configure a logon script for VPN users to run that command to clear credentials when they connect. 
4. Create a .bat file with that command and place it on their  desktops and instruct them to double click on it after they connect.

Ace Fekay
MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

This post is provided AS-IS with no warranties or guarantees and confers no rights.

_{Tuesday, December 31, 2013 8:56 AM}

Hi,

NetBIOS traffic is usually blocked in VPN tunnel. Check you firewall if NetBIOS service is enabled and the ports are open.

You can try telnet the port that is used for NetBIOS service.

 nbname            137/UDP

 nbname            137/TCP

 nbdatagram        138/UDP

 nbsession         139/TCP

Hope this helps.

_{Tuesday, December 31, 2013 4:31 PM}

Daniel,

Thank you for the input. I can telnet server1 on port 139 from home on both a domain laptop and one on a workgroup. That’s why I don’t believe it’s related to the firewall or port blocking because (as stated in the first post) it’s only an issue with laptops that are on the domain and not ones in a workgroup. Or is it possible that the domain laptops are trying different ports than the workgroup laptops are?

With that said, I can call the ISP to verify 137, 138 and 139 are open if you think that might still be part of our problem.

_{Tuesday, December 31, 2013 10:41 PM}

  The fact that the Netbios ports are available over the Internet (which is a very worrying security risk) does not mean that they will necessarily go through the VPN tunnel.

Bill

_{Wednesday, January 1, 2014 2:30 AM}

The ISP has confirmed that those ports are not being blocked on the tunnel. One new development though is that on the domain-connected laptop if I go into the Windows 7 Credential Manager in Control Panel and remove the *Session entry from the vault while connected to the VPN I can immediately connect to \server1 from Start>Run. Once the *Session reappears in the vault, I can no longer connect to the server without adding .domain.local.

I began looking into this being a cached credentials issue because when I’m at a command prompt and type net use \server1 I receive “System error 2221. The user name could not be found.” But if I type net use \server1 /u:administrator adminpassword it completes successfully.

If I type \IPAddressOfServer1 in Start>Run, I receive a credentials prompt with the VPN user name and password auto-filled.

I should mention that the VPN credentials do not match an account in AD and the laptop is logging into Windows as the domain admin (the same login info that’s used in the net use command).

Does any of this new information help? I just made these discoveries today so I didn’t have much time to research more but I did want to post the update. Thanks again guys.

_{Thursday, January 2, 2014 7:14 PM}

When you run an ipconfig /all, do you see the WINS server addresses being provided? How about the connection specific suffix for the domain, domain.local (or whatever it is called)?

I assume that you are using the Microtik as the VPN server and you are not using AD accounts for authentication. I would highly suggest to do that, otherwise, there will be a mismatch.

What VPN client is being used?

What is offering DHCP, a Windows Server or the Microtik?

FYI, using NetBIOS connection method, such as \server1, will use the current logged on account for authentication. If the VPN credentials are not AD credentials, but the VPN client is setting the logged on credentials account (some of them do that), then it will cause issues.

From what I see that NetBIOS is not being blocked, so that doesn't appear to be an issue, but it's coming down to credentials. Maybe in the mapped drive you can preset the credentials, and might be one way around it.

Ace Fekay
MVP, MCT, MCITP/EA, MCTS Windows 2008/R2 & Exchange 2007, Exchange 2010 EA, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
Technical Blogs & Videos: http://www.delawarecountycomputerconsulting.com/

This post is provided AS-IS with no warranties or guarantees and confers no rights.