3

I have a samba share, and the network my devices are on blocks communication over port 445 (the standard SMB TCP port). Linux devices and Macs can connect to this device because they can communicate with the server using port 139 (NBT over IP), which is not blocked Windows devices, however, seem to insist they communicate over port 445.

Is there any way for me to tell Windows 10 to use port 139 without relying on port 445?

3

I got this working by disabling SMBv2/v3 on Windows 10:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled

then Restart the computer. To reverse this change and re-enable SMBv3 run the following commands at at the elevated command prompt

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb20 start= auto

UPDATE: I've renabled SMBv2 on Windows 10 and tried all the protocols limits on the server. NT1 works. So you can just add the following line to the server main smb.conf file instead of the above. I prefer this method because it will affect all my Windows 10 machines centrally:

server max protocol = NT1
0

I had the same problem with a fresh install of Windows 10 (v1709) not attempting to use port 139 when connecting to SMB servers.

Turns out that the LanmanWorkstation service registry settings under

HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage

were missing a few entries, first I had to find out the GUID of my NIC using

wmic nicconfig get description,index,TcpipNetbiosOptions,SettingID

and then I had to make sure all the necessary entries are present.

Bind:

\Device\Tcpip_{GUID}
\Device\NetBT_Tcpip_{GUID}

Export:

\Device\LanmanWorkstation_Tcpip_{GUID}
\Device\LanmanWorkstation_NetBT_Tcpip_{GUID}

Route:

"Tcpip" "{GUID}"
"NetBT" "Tcpip" "{GUID}"

Restart is needed and 'Enable NetBIOS over TCP/IP' must be enabled, obviously.

Note: Windows 10 is not happy about connecting to an SMB v2 server over port 139, I only needed to connect to SMB v1 servers or SMB v2 servers with port 445 open, so I did not need to disable SMB v2 on the client side.

I suggest accessing a share and using an IP address (e.g. \\192.168.1.11\share) to test if SMB1 is working.

p.s. credit goes to gwjwin and Momominta

-1

Sounds like you are using naked SMB (CIFS) over public networks -- not good. At least use VPN tunneling to add security. That also solves the blocked port 445 as every port is encrypted and hidden inside the VPN tunnel. Run a VPN server program on the machine with the share. Run VPN client software to connect to the share-VPN Server machine.

If you want to avoid the technical and its only a few easily anticipated files -- store them in DropBox or similar online storage using HTTPS web interface.

HTTPS file transfers and many other better protocols exist to cross the internet. WebDAV has more or less turnkey HTTPS file server solutions.

Yes SMBv3 uses only port 445 (UDP/TCP) on Windows (and I think the latest SAMBA). Port 445 is blocked because despite many security improvements to version 3 of the SMB protocol. SMBv3 is still quite vulnerable to malware infections or data theft when exposed to anonymous users on Internet or LANs not secured from the public.

Worse the use of Ports 137, 138, and 139 are mostly linked to older versions of SMB.

Even on supposedly secure LANs, SMBv1 should be disabled if its possible to use SMBv2 or higher. SMBv3 is strongly preferred over SMBv2. Older SMB versions can be a fast way to spread problems from any infected computer across all LAN connected machines. Effectively a BIG Hole in the onboard firewalls.

P.S. Yup it will use CPU power to encrypt data in a VPN so you need a little extra CPU room while files are being exchanged. Not really an issue if editing small files by hand. But mass data exchange for large file transfers or database access could be an issue on machines already near acceptable performance limits. If practical separate work into downloading a local copy first then operating on local copy before transferring the altered files back to the share.

As a rule of thumb a dedicated Pentium D with 2GB of RAM can push 10-15Mbps/sec continuously through a VPN. that is old 2005-2006 tech.

Any i3 gen4+ CPU or any i5 or i7 except Generation 1 CPU have special AES encryption hardware that will let them do VPN encryption literally 100 times faster. So plenty of power to do other tasks while doing VPN. File transfer speed will not be slowed by CPU considerations.

  • ISP screwed up in not blocking ports 137-139...or they are intentionally trying to kill off machines of people too ***** to update to something less vulnerable. – Curious Oct 24 '18 at 7:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.