NetBIOS Name Service requests not being sent or answered

Question

I have serious inconsistency on my systems of whether NetBIOS name service requests are working on endpoints. I'm testing with Win7 and Server 2008R2 systems. We do not have a WINS server and don't want to have one, but I'm most interested in the differing behavior. The driver here is our Nessus scanner, which obtains the name of a system by querying the device for its NetBIOS name using its plugin 10150, which apparently does the same thing as nbtscan.

The way I understand and observe it, Nessus, nbtscan, and running nbtstat -A XX.XX.XX.XX send a netbios-ns packet to UDP port 137 on the target, which should respond with a UDP port 137 response back to the requestor. When I watch this with Wireshark on a problem machine, I see the packets come in, but no response is sent. But some systems reply as expected. I think I've eliminated the host firewall as the culprit here, so lets assume that for now.

Also--and here's the arguably stranger thing--on these systems that don't respond, they also don't seem to try to send the UDP packets when I issue nbtstat -A XX.XX.XX.XX commands. They exit immediately with "Host not found", and Wireshark shows no outgoing packets (working systems generate up to three packets before giving up).

It is as if the NetBIOS-NS subsystem is disabled on these systems, and it doesn't try to use it, but I can't find evidence of a setting that would cause this. Further frustrating, none of Microsoft's documentation seems to even admit to this unicast name resolution method existing--everything you read talks only about broadcast or WINS server messaging. Speaking of which, both working and non-working systems are in Hybrid mode per ipconfig /all, and I have explicitly set the interfaces to enable NetBIOS over TCP/IP, which didn't help. I see via netstat -an that the kernel is listening on UDP port 137, but these messages are going unanswered.

Is there a setting somewhere which causes the behavior I'm seeing? This seems like the most likely answer but my search has turned up nothing.

Update

I now also observe that the UDP packets are transmitted if the query is to another IP in the same subnet. So, that's material. But again I don't know why the behavior is different on some hosts. Why do some of my systems send (and respond to) UDP packets for NetBIOS-NS only for IPs on the local subnet?

Answer 1

I had a problem that several computers could not access SMB share on old Windows 95 (yep, I know...) machine networked on a separate VLAN without internet connectivity. Few computers were able to connect the shares but gradually over time just stopped working.

I dug deep with wireshark to see that the last working computer sends out NBNS queries which the non-working computers do not. Exactly like this case as nbstat -A immediately returned "host not found". Moving computers to same VLAN made it work again but was not really a solution since internet connectivity is a must on a computer that connects to the old PC.

After several months of on-off research I finally cracked this:

https://support.microsoft.com/en-us/kb/3161949

NETBIOS communication outside of the local subnet is hardened. Therefore, by default, some features that depend on NETBIOS (such as SMB over NETBIOS) will not work outside the local subnet. To change this new default behavior, create the following registry entry:

SUBKEY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters Value Name: AllowNBToInternet Type: Dword Value: 1 Default value of the flag: 0

After adding the key to registry and rebooting, the nbtstat -A xx.xx.xx.xx began sending out queries and the SMB share works again. Hope this helps if someone stumbles upon this in the future.