Windows – Cannot connect to Windows share via local network IP address, but can by localhost

file-sharingnetworkingsmbwindows 10

I'm stuck a bit in figuring out why can not I access Windows Shared Folder via my local network address even from the very computer that exposes the share.

When I try to see shared folder via \\localhost everything works out, I can see the files.

However, when I try to connect from the very same computer via my local network address (192.168.1.2) it shows the listing of folders but fails to open it.

I can ping my address (192.168.1.2) with no problems. Firewall is turned off. No antivirus. I have turned on both "File and printer sharing" and "network discovery".

Microsoft Windows [Version 10.0.15063]

Here is how my ipconfig looks like, nothing suspicious.

C:\Users\nrj>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : EUGENE-PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter local:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : <hidden>
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::c0cf:f044:74d2:c5ec%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Saturday, August 12, 2017 14:57:30
   Lease Expires . . . . . . . . . . : Sunday, August 13, 2017 14:57:30
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DHCPv6 IAID . . . . . . . . . . . : 190858699
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-9B-1E-0E-00-1F-C6-78-EC-28
   DNS Servers . . . . . . . . . . . : 192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Netstat for 445 port:

C:\Users\nrj>netstat -a | findstr /R /C:.*445.*
  TCP    0.0.0.0:445            EUGENE-PC:0            LISTENING
  TCP    [::]:445               EUGENE-PC:0            LISTENING

What else can I check to figure this out?

UPD. Network adapter properties shows that "File and Printer Sharing" is enabled.

Just to be clear, again, 192.168.1.2 is address of my computer from which I try to access my own file share and it does not work. Here is the routes table.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.2     35
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.1.0    255.255.255.0         On-link       192.168.1.2    291
      192.168.1.2  255.255.255.255         On-link       192.168.1.2    291 <- see here
    192.168.1.255  255.255.255.255         On-link       192.168.1.2    291
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       192.168.1.2    291
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       192.168.1.2    291

UPD 2. netcfg output here: https://pastebin.com/zRa7wi1t.

Best Answer

When you posted this question 6 months ago, in my efforts to reproduce your problem I disabled then later re-enabled NetBIOS over TCP/IP in the Advanced TCP/IP Settings of my network adapter. A few weeks later I discovered I was having the same problem described in the OP (except, I did it to myself). I ended up fixing the problem after hours of research which culminated in painstakingly comparing the Registries of a working computer with my non-working machine.

Here's the solution I discovered. (You might want to grab a beer first...)

Step A: Get the GUID of your network adapter

You will need your network adapter's GUID. It looks something like this:

{DED7C856-1234-5678-BA7E-FF9BF300F579}

Here are two ways to get it:

Via PowerShell:

Run this:

Get-NetAdapter | fl Name,Status,InterfaceDescription,Status,MacAddress,LinkSpeed,InterfaceGuid

Make note of the adapter's InterfaceGuid value.

Via Command Prompt (source):

If necessary, use the Services MMC snap-in (run services.msc) to start the Wired AutoConfig service (for wired network interfaces) or WLAN AutoConfig service (for wireless interfaces).
Run the command corresponding to your type of interface:

Wired: netsh lan show interfaces
Wireless: netsh wlan show interfaces
Make note of the GUID value (it will be displayed without the surrounding braces, which you need to add).

Step B: Edit the Registry

Run regedit to open the Registry Editor.
Navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Linkage
For each of the three values in the table below (Bind, Export, and Route), double-click the value to open the Value data editor.
Inspect the Value data for the strings shown in the Data column of the table below. When the table shows {GUID} replace that with the actual GUID of your network adapter, including the surrounding braces. For example, if your adapter's GUID is {DED7C856-1234-5678-BA7E-FF9BF300F579} according to the table below the Bind value in the Registry should have the following two entries:
```
\Device\Tcpip_{DED7C856-1234-5678-BA7E-FF9BF300F579}
\Device\Tcpip6_{DED7C856-1234-5678-BA7E-FF9BF300F579}
```
Add any Data values that are missing as new lines at the end of the text box. Do this for each value shown in the table.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Linkage

+--------+-----------------------------+
| Value  | Data                        |
+--------+-----------------------------+
| Bind   | \Device\Tcpip_{GUID}        |
|        | \Device\Tcpip6_{GUID}       |
+--------+-----------------------------+
| Export | \Device\NetBt_Tcpip_{GUID}  |
|        | \Device\NetBt_Tcpip6_{GUID} |
+--------+-----------------------------+
| Route  | "Tcpip" "{GUID}"            |
|        | "Tcpip6" "{GUID}"           |
+--------+-----------------------------+

Repeat steps 2 through 5 for each of the following tables (for this following table, you'll use the data table for both keys shown):

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Linkage
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage

+-------+-----------------------------+
| Value | Data                        |
+-------+-----------------------------+
| Bind  | \Device\Tcpip_{GUID}        |
|       | \Device\Tcpip6_{GUID}       |
|       | \Device\NetBT_Tcpip_{GUID}  |
|       | \Device\NetBT_Tcpip6_{GUID} |
+-------+-----------------------------+
| Route | "Tcpip" "{GUID}"            |
|       | "Tcpip6" "{GUID}"           |
|       | "NetBT" "Tcpip" "{GUID}"    |
|       | "NetBT" "Tcpip6" "{GUID}"   |
+-------+-----------------------------+

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Linkage

+--------+------------------------------------------+
| Value  | Data                                     |
+--------+------------------------------------------+
| Export | \Device\LanmanServer_Tcpip_{GUID}        |
|        | \Device\LanmanServer_Tcpip6_{GUID}       |
|        | \Device\LanmanServer_NetBT_Tcpip_{GUID}  |
|        | \Device\LanmanServer_NetBT_Tcpip6_{GUID} |
+--------+------------------------------------------+

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage

+--------+-----------------------------------------------+
| Value  | Data                                          |
+--------+-----------------------------------------------+
| Export | \Device\LanmanWorkstation_Tcpip_{GUID}        |
|        | \Device\LanmanWorkstation_Tcpip6_{GUID}       |
|        | \Device\LanmanWorkstation_NetBT_Tcpip_{GUID}  |
|        | \Device\LanmanWorkstation_NetBT_Tcpip6_{GUID} |
+--------+-----------------------------------------------+

Step C: Reboot

Reboot your computer for the changes to take effect.

Related Solutions

Resetting gone wrong

You have Teredo enabled, but your system hasn't correctly identified your public IPv4 address. This is due to a double NAT situation (you are behind two home routers both doing NAT, or you have one router and your ISP is also NATting your connection); Teredo addresses encode what should be the public IPv4 address, but yours encodes the address 192.168.1.100, a private address. This only happens in a double NAT setup.

Since this gives you a mostly-nonfunctional or completely broken IPv6 address, and IPv6 is preferred to IPv4, this will slow down your connectivity to any IPv6 enabled web site (Google, Facebook, many others).

I always recommend disabling Teredo, ISATAP and 6to4, all of which are IPv6 transition technologies with various pitfalls, unless you actually intend to use them.

Open an elevated command prompt by right-clicking the Command Prompt icon and selecting Run as Administrator, and enter the following commands:

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh int teredo set state disabled

Each should return The command completed successfully.

Then restart your computer.

Linux – Routing all traffic over VPN on Ubuntu Linux

Your local network is 192.168.1.0/24, as shown by this line in your routing table:

 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.32  metric 1

Your VPN network is 10.0.0.0/8, as shown by this line:

 10.0.0.0/8 dev tun0  scope link

Currently, your default router is:

 default via 192.168.1.254 dev eth0  proto static

which is of course what you do not want, because it belongs to your local LAN: thus all of your stuff is routed through your local gateway, as if the VPN did not exist.

 You do have however, the all-important statement

 128.122.252.68 via 192.168.1.254 dev eth0  src 192.168.1.32

which is the route to your VPN-provider.

EDIT:

I had not realized that the routing table is simply the one that is obtained from your VPN, without your intervention. This may indicate (indirectly) that your service provider is willing to forward only the traffic explicitly allowed in your table through the interface tun0, and may have taken further steps to block all other traffic, in which case your efforts will be futile.

However, assuming that your provider is willing to forward all of your traffic, what you need to do is the following.

First, you need to find out whether there is a gateway willing to accept your connection on the other side, because we need its IP address. I will give you four methods to do this.

1) With the pc connected to the VPN, try the following command:

   sudo dhclient -v tun0

If everything goes well, you should see a reply containing this line:

 DHCPOFFER of a.b.c.d from x.y.w.z

x.y.w.z is the IP address of the local gateway. You may have to shutdown your VPN after this test, and maybe even to reboot your pc, because we will have just messed up the routing table pretty well.

2) Alternatively, you may try navigating to one of the allowed sites (those that appear in your routing table as going through the tun0 interface), then issuing the command:

  ip neigh show

You should get a list of pcs contacted through the ARP protocol, with MAC and IP address; most likely, you will receive either zero or one reply. If you get a single reply, then that's your router.

3) If you get no such reply, then you may try with

  sudo nmap -sn 10.0.0.0/8

(which is going to be very slow). Your gateway will be one of the pcs listed, most likely the one with address ending in .1 or in .254, if any such exist.

4) Use the tcpdump command:

  sudo tcpdump -n -i tun0

and see the IP addresses spewed out by the command.

If you get no proper reply to this test either, it means someone has really tightened the screws in his network.

But let us be optimistic, and suppose you now have a candidate IP address x.w.y.z for the remote router. You will need to delete the default gateway, (as sudo!):

  ip route del default via 192.168.1.254

an add the new one:

  ip route add default via x.w.y.z

and try to navigate.

Let me repeat: since your provider has allowed traffic only to a few selected IP addresses through his VPN, it is possible he may have taken extra measures (=firewall) to prevent a smart user to force his generic traffic through his VPN. In this case, there is nothing you can do. But if he did not, the above steps should help you find a solution.