General Networking/Lan/Wan/Windows 7 VPN - unable to resolve network host names
QUESTION: I have created an incoming VPN network connection (using Windows 7 'incoming' connection') on the host computer and an outgoing VPN connection on the remote computer (also with Win7). The connection is successful and I can map a network drive on the host if I use \\<ip address>\share. If I try to access the host via \\<NBT name>\share, it fails to connect and ping fails as well. If I disable the win7 firewall on the remote, then I can resolve the NBT name via ping and \\<NBT name>\share. I don't know what else I need to add to the "add programs to communicate through Windows Firewall" list, but I have the following enabled:
- File and Printer sharing
- Network Discovery
- Routing and remote access (even though that only applies to incoming connections)
- Secure Socket Tunneling Protocol (same as above)
Also, network discovery never works, whether or not I have the firewall enabled or disabled.
ANSWER: since you are not using dns, your pc wants a way to resolve netbios names to IP. You can use the lmhosts file to do this. It's what we call "old scool" :-)
After creating the lmhosts file (should be located in something like windows/system32/drivers/etc), you'll need to either restart your PC or disable/re-enable your NIC, so that the file will be read by your system.
This should fix things so that you can use a name instead of IP.
[an error occurred while processing this directive]---------- FOLLOW-UP ----------
QUESTION: Thanks for the reply - I'm familiar with LMHOSTS, but I thought that was disabled in Win7. Wish there was an answer as to why a complete disabling of the Win7 firewall allows resolution of netbios names, but when I enable the firewall (with the above-mentioned exceptions).
What about network discovery?
ANSWER: No you can still use LMHOSTS. But you'll merely need to make a new file from scratch or copy lmhosts.sam and then modify that - and rename it to just "lmhosts", without that silly .sam extension.
On the other half of your question, it's pretty clear that if things work when the firewall is disabled that it's dropping packets that you wish to be "not dropped" :-) Probably netbios broadcasts and perhaps more. To find out WHAT is getting dropped, just enable logging, then enable it, try it again so that it doesn't work, check the log and you should see what kind of rule you could create to allow it to work with the firewall enabled. You also may wish to use something other than the windows firewall, to provide you with more flexibility and such, if you like.
---------- FOLLOW-UP ----------
QUESTION: Thanks for the reply. I'm not sure how to enable logging, or do I need to download and install a network sniffing utility?
I assume I'm hosed as far as getting network discovery to work (it fails whether or not the firewall is enabled).
Windows default firewall may or may not have the level of logging that you'd need. I'm not sure on that. A good 3rd party firewall would for sure. But that's a lot of trouble I think, when the bottom line is that you CAN get it working so ... isn't that the main thing?
As to discovery ... you can manually map it anyway so ... who cares really? If it works, it works. You have better things to do than worry about Windows silly discovery thing, right?
Anyway - have a great night!