[REQUEST] Win 10 VPN Client can't browse network with firewall up

nlinecomputers

Well-Known Member
Reaction score
8,594
Location
Midland TX
Hi.

I am trying to connect a Windows 10 PC to an SBS 2011 VPN. I can connect just fine but I am unable to connect to network shares by computer name.

\\server\share doesn't work, \\192.168.1.1\share does.

I can connect by the IP of the server. If I turn off the firewall I can access everything.

As I understand the ports I need are 135,139,445 and UDP 137 port. I assume that is inbound or should it be outbound as this is the client win 10 machine that needs to make the connection? I've tried but I can't seem to get this to work.

Also, would prefer to set up this so that the ports are only opened during and for the VPN connection. The client may use the laptop anywhere.
 
History? New? Worked and then stopped? Using the DNS on the SBS box? Domain or home version? I usually have 1701 and 1723 opened as well.
 
New client. New machine on the network. Also trying on my own Windows 10 machine. So this by default blocked. My win 7 machine will browse but I've set up VPNs on it before so something I probably have forgotten is setup on this....:(
 
SBS is running as a domain and clients computer is an AD member. My test machine is not. Both are win 10 pro. I've tried pointing DNS to the server but still does not work. Besides it works when the windows firewall on the client is off. So something by default is set to block.
 
I've never setup a Windows Server VPN, but DNS is port 53 (TCP and UDP), I try not to ever rely on NetBIOS.

It's funny that it would be blocked for the tunnel though. However I've found the Windows 10 firewall to be quite aggressive.
 
Netbios is 137, 138 & 139 as @Markverhyden said. Isn't there a checkbox somewhere in the VPN properties to disable Netbios over TCP? How is that set?

What are the DNS settings of the VPN connection? Is there anything OTHER than the DC address in there? I presume you've already tried flushing DNS...

Barring that - I know this doesn't fix the problem, but how important is it to browse by Netbios name? Typically, I would map a drive for the client anyway, so using IP address would let you do that. I've found less problems overall by using IP address anyway - way fewer callbacks because they can't open the shares for some reason. Especially if it is a laptop and they will be connecting via VPN from various places. Come to think of it, the last one of these I "fixed" by changing the maps from Netbios to IP addresses was a Win10 machine that stopped connecting to the shares after the creators update.
 
Last edited:
The windows firewall by default limits SMB access to the local IP network only. This basically means name resolution doesn't work either. The firewall you need to adjust is on the server, not the client. Also, most of the ports you just listed are terribly out of date.

How to fix it? Well, if the client and the server are both on a domain, you just need to go add the IP range the VPN uses to Active Directory Sites and Services. Wait for policy replication, and reconnect.

If you want names to work, you'd better make sure the client is getting the correct DNS to support AD. Sounds like you're having trouble with that too.
 
The firewall you need to adjust is on the server, not the client.
If that was the case then NONE of the client machines would connect. Windows 7 connects and can browse by name. Windows 10 cannot but if I disable the firewall on the WINDOWS 10 CLIENT it can see shares by name. It is the local firewall not the server.

I've added an entry to lmhosts to get this to work. Not my preferred solution but what will work for now.
 
If adding an entry to lmhosts solved the problem, the issue wasn't the local firewall and was instead the DNS configuration of that specific VPN client.
 
If adding an entry to lmhosts solved the problem, the issue wasn't the local firewall and was instead the DNS configuration of that specific VPN client.

True. But he did say that if he drops the local firewall then it does work. So that leads me to believe that the local firewall was blocking the DNS resolution. As other machines connect just fine.
 
It's not DNS. Because if check the use gateway box, I can still browse the internet. If I put the IP address of the server in the DNS settings manually for the VPN I can still browse the internet. If I use IP addresses I can access shares so SMB is working. That leaves NetBIOS name resolution as being blocked. Use NetBIOS over TCP is checked so it isn't that either. Inconstant crap like this is why I never mess with the Windows VPN. I inherited this mess and I am trying to make what they do work before I propose throwing out the baby and bath water for a better option like OneDrive and Sharepoint.
 
It's not DNS. Because if check the use gateway box, I can still browse the internet. If I put the IP address of the server in the DNS settings manually for the VPN I can still browse the internet. If I use IP addresses I can access shares so SMB is working. That leaves NetBIOS name resolution as being blocked. Use NetBIOS over TCP is checked so it isn't that either. Inconstant crap like this is why I never mess with the Windows VPN. I inherited this mess and I am trying to make what they do work before I propose throwing out the baby and bath water for a better option like OneDrive and Sharepoint.

Yes, NetBIOS can do weird things, which is why you don't rely on it anymore, you rely on DNS. Did you try using the FQDN? Maybe you didn't try the FQDN and the computer doesn't have the DNS suffix set?
 
I know the issue is DNS related, because the VPN client doesn't have a properly configured DNS resolver. If the FQDN works, the VPN adapter is missing the DNS suffix. If the FQDN doesn't work, the station isn't using the AD supporting DNS resolution path. That's really all there is to it. The Windows Firewall doesn't mess with DNS, but it will mess with SMB if it isn't local or from a trusted network. Domain IP ranges are default trusted, assuming they're actually inputted into sites and services as they're supposed to be.

Test resolution on the command line with nslookup. Make sure you ipconfig /flushdns between every adjustment.

It literally cannot be anything but a DNS issue because you "fixed" it by hacking up lmhosts. All that does is forcibly configure a NetBIOS lookup, which Windows won't even do if DNS is working properly.
 
Back
Top