Intended Audience
This guide will be useful to you if you’re working in a predominantly Windows 10 workgroup with some legacy Windows and third-party devices employing SMB1. You have at least one FreeNAS server in the workgroup. Authentication is achieved without the use of a domain controller.
In the network I’m referring to in this guide, there are several FreeNAS servers, with one of the servers located remotely across the WAN on a second subnet. At the time of writing, my PCs are running the Windows 10 Fall Creator Update (build 1709) and my servers are running FreeNAS 11.1-U4.
Background
All MS Windows networking uses SMB-based messaging. To the average user, network browsing means they can see SMB servers in the network neighbourhood. When a server icon is clicked, the shares and printers served from the target computer are shown.
Computer browsing in a Windows workgroup environment has always been a bit hit and miss. The list of network neighbours is often incomplete, slow to update and doesn’t work across subnets. Microsoft appears intent on phasing out browsing. Current incarnations of Windows 10 have all but killed off network browsing. Why?
The EternalBlue exploit of SMB1 led to the WannaCry and NotPetya ransomware epidemics in 2017. The network browser service depends on SMB1. Windows 10 switches off SMB1 effectively disabling network browsing. Two issues arise as a consequence:
- There’s a heap of current and older third-party devices that rely heavily on SMB1. Microsoft has taken to identifying vendors of these devices in an attempt to get them to shift away from SMB1. This, of course, is unlikely to help you if you are actively using non-current or discontinued devices that utilise SMB1.
- The bigger issue at present is that Microsoft hasn’t provided an effective, replacement network browsing solution for home and small businesses that can ill afford complex IT infrastructure and ongoing support. While Microsoft has suggested a way to continue to browse, it isn’t universal. It won’t work for legacy Windows systems nor with third-party devices employing SMB1. Microsoft’s preference is that you forget about network browsing and instead map resources.
Map resources!? The whole idea of browsing is to be able to look for useful resources, much like browsing for a book on a bookshelf. The inability to browse the local network is a bit like groping in the dark. I personally think mapping resources is a poor second cousin to browsing.
Caveat Emptor!
Disabling network browsing adversely affects home and small businesses operating in a workgroup. There are risks in reintroducing legacy network browsing. As this article points out, SMB1 and NetBIOS over TCP/IP, features of legacy network browsing are vulnerable network protocols. It is a difficult predicament. However, as long as you have adopted adequate measures to mitigate the risks (ideally implementing ZFS snapshots), the likelihood of an exploit occurring is low and the consequences manageable. In light of this, and in my humble opinion, the benefits of network browsing outweigh the risks. Proceed at your own risk though!
Objectives
The aim here is to bring back efficient and effective network browsing. To achieve this, the following objectives will be met:
- Use of a reliable browse master;
- Set up WINS for name resolution and browsing support; and
- Enable cross-subnet browsing.
Pivotal to meeting these objectives is FreeNAS, more specifically Samba on FreeNAS. Samba implements NetBIOS, as do legacy Windows systems, by encapsulating it over TCP/IP. Network browsing relies on NetBIOS-based messaging. Microsoft appears intent on phasing out NetBIOS as well. SMB messaging over TCP/IP can now be implemented without NetBIOS. However, more sophisticated technologies such as AD and DNS need to be employed to take advantage of this in providing directory services. This is likely to be beyond the scope of home users and small business. Until something simpler comes along, NetBIOS, SMB1, and network browsing are an irresistible attraction for smaller workgroups.
Note: Of the four steps described below, only the first two are required for reliable network browsing. The last two steps extend this by providing some network optimisations as well as cross-subnet browsing.
Step 1: Re-enable SMB1 on Windows 10
Network browsing is reliant on SMB1. A computer that wishes to participate as an SMB server or to browse SMB resources in the network neighbourhood needs to have SMB1 enabled.
Under Windows Settings, click Apps.
Under Apps & features, click Program and Features.
Under Program and Features, click Turn Windows features on or off.
Under Turn Windows features on or off, scroll down to and expand SMB 1.0/CIFS File Sharing Support. Uncheck the SMB 1.0 automatic removal checkbox, and check the client and server checkboxes.
Click OK for the changes to take effect. A reboot will be required.
Step 2: Nominate a Reliable Master Browser
The role of the master browser is to maintain a browse list of computers that are acting as SMB servers. How is a master browser chosen? It gets elected through quite an elaborate election process. How is the master browse list populated? In a nutshell, computers announce their presence through lossy, non-routable broadcasts every 12 minutes. The master browser uses these broadcasts to populate the master browse list. The interaction between SMB servers and the master browser is limited to announcing when they join or leave the network and requesting a list of backup browsers. What is a backup browser? A backup browser maintains a copy of the browse list and responds to client requests for it. In a workgroup of fewer than 32 computers, there will be one backup browser. Backup browsers have their browse lists updated from the master browser every 12 minutes. (Note: Samba and Microsoft documentation differ on this point. Samba documentation suggests the interval is 15 minutes). How are computers removed from the browse list? The master browser removes a computer’s entry from the browse list if a computer announces it is leaving or if it misses three announcements in a row. If the latter occurs, as it will if a computer crashes or is shut down inelegantly, ghosted entries remain in the master browse list for 36 minutes! As the backup browser list may not be updated for a further 12 minutes, it may take up to 48 minutes for computers on the local subnet to be informed of a failed SMB server. Note that the time is halved to 24 minutes if the SMB server announces it is leaving instead of bombing out.
It now becomes clear why network discovery is so unreliable. It can take a considerable amount of time to populate a stable browse list. The larger the workgroup, the more unreliable the view of the network neighbourhood. This is because the likelihood of computers being started, shut down, rebooted or crashing increases. The issue is further exacerbated if one of the client computers is the master browser. When it is shut down or rebooted, a new election process begins, a new master browser is elected and the browse list is rebuilt from scratch.
A FreeNAS server makes an ideal master and backup browser. Unlike a client computer, it is expected to be up for considerable periods of time, ideally 24/7. Using a FreeNAS server as a master browser serves two purposes. It eliminates frequent elections on a subnet as well as frequent rebuilds of the browse list. This would tend to make network discovery more reliable particularly for network resources such as legacy printers and NAS that are not attached to and served by client computers.
To make a FreeNAS server the master browser for a workgroup, in the FreeNAS GUI, under the active SMB service, ensure that Local Master is ticked and add the lines shown to the Auxiliary parameters section. Once saved, an election process occurs to promote the FreeNAS server to master browser.
The parameter os level = 255 ensures that the FreeNAS server wins in any election process to becomes the master browser. The parameter preferred master = yes forces a browser election when the FreeNAS server is started or restarted.
If you have additional FreeNAS servers on the subnet, don’t add the lines in the Auxiliary parameters, but do ensure that Local Master is ticked. While servers on the local subnet won’t win in an election process, for larger workgroups with more than 32 computers, they become candidates for backup browsers.
If applicable, repeat step 2 for each subnet the workgroup spans. Once complete, you will have a reliable browse master on each subnet resulting in a stable local computer browser service on your Windows clients. Only proceed to step 3 if you want to eliminate broadcast traffic arising from the computer browser service, and to step 4 if you want the service to operate across subnet boundaries.
Edit: Network browsing breaks in the upgrade to FreeNAS 11.1-U6. The instruction here re-enables it. The instruction is restated below.
SMB1 has been disabled by default for security reasons. If legacy clients are no longer able to connect, type this command in the Shell, then restart the SMB service:
sysctl freenas.services.smb.config.server_min_protocol=NT1
If that resolves the issue, you can make that setting permanent by going to System → Tunables →Add Tunable and creating a Tunable with these settings:
Variable: freenas.services.smb.config.server_min_protocol
Value: NT1
Type: Sysctl
Step 3A: Set up a WINS Services under FreeNAS
Name resolution and registration in a simple Windows workgroup is achieved using the NetBIOS naming service and broadcast messages. As this article points out, broadcasting has three main disadvantages:
- Poor network performance. For instance, the name registration process involves sending a broadcast message out and then waiting a few seconds for a response. If a response is not received, it is assumed the name isn’t in use. The wait timeout makes name registration a very lengthy process.
- Each host on the network has to accept every broadcast message to decide whether to respond to it. This consumes computer CPU.
- Broadcast packets aren’t forwarded by routers. This limits name resolution to the local subnet.
A NetBIOS name server can be used to record all name registrations. Windows Internet Naming Service (WINS) is an implementation of a NetBIOS name server that maps NetBIOS hostnames to their network IP addresses. WINS eliminates the need for broadcasts to resolve computer names to IP addresses and provides a dynamic database that maintains mappings of computer names to IP addresses. This is essential for cross-subnet browsing since broadcast name resolution can’t occur across network segments.
Why not set up a local DNS server instead for name resolution? WINS is NetBIOS aware; standard DNS is not. WINS has been deprecated, but the ease of setting it up in a Windows workgroup with a FreeNAS server compared to implementing local DNS services makes it very attractive.
To make the FreeNAS server a WINS server for a workgroup, in the FreeNAS GUI, under the SMB service, add the line wins support = yes to the Auxiliary parameters section.
Believe it or not, that’s all that is required to turn a FreeNAS server into a WINS server! There is no ongoing management.
Much like Windows clients, if you have other FreeNAS servers on your network, they need to be WINS-enabled. To do this, within their FreeNAS GUI, under the SMB service, specify the wins server address in the Auxiliary parameters section. Refer to the example in the screenshot below. Note: Do not add this parameter to the FreeNAS server providing the WINS service.
In addition, if a FreeNAS server exists in a secondary subnet that doesn’t have a WINS server, it can act as a proxy for the real WINS server on the primary subnet. To do this, in the FreeNAS GUI for the proxy, under the SMB service, add the line wins proxy = yes to the Auxiliary parameters section.
Step 3B: Configure all Windows computers as WINS clients.
This step is trivial if your DHCP server has a DHCP option to specify the WINS server address. If not, and manually configuring clients isn’t an option, check out my next post, which turns a FreeNAS server into a DHCP/DNS server on the network.
If you only have a few client machines, you can manually configure the relevant network adapters on each. This is manageable for a small number of Windows PCs. Note that multihomed computers will have more than one network adapter. For instance, a Windows notebook may have a LAN port and a Wi-Fi adapter. Each will need to be configured separately. The example below traces the configuration of the active LAN adapter on a Windows 10 PC.
Under Settings, select Network & Internet.
Under Status, click Change adapter options.
In this example, the properties of the Local Area Connection adapter will be modified. Under Network Connections, double-click the active Local Area Connection.
Under Local Area Connection Status, click Details.
Under Network Connection Details, note that the IPV4 WINS Server is not defined and confirm that NetBIOS over Tcpip Enabled is set to Yes. Click Close to return to the previous dialogue box and then click Properties.
Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
Click Advanced.
Select the WINS tab and click Add.
Enter the IP address of your WINS server and then click Add to close the TCP/IP WINS Server dialogue box.
Click OK to close the Advanced TCP/IP Settings dialogue box.
Close the remaining boxes until you are out of Settings. The adapter is now WINS-enabled. The client is now able to query the WINS server directly instead of broadcasting queries.
Broadcast traffic on the network will continue to reduce as more and more PCs are configured to be WINS-enabled. Broadcast queries won’t be completely eliminated because non-WINS clients may continue to broadcast queries.
Note that PCs on secondary subnets should be configured to use the WINS proxy. The WINS proxy will relay name registration and resolution services from itself to the real WINS server on the primary subnet.
Step 4: Enable Cross-Subnet Browsing
Skip this step if your workgroup doesn’t span subnets.
On the primary subnet, nominate a FreeNAS server to be the domain master browser. In an environment with only one FreeNAS server on the subnet, the server performs dual roles of master browser and domain master browser. As this article states:
‘The domain master browser propagates browse lists across each subnet in the workgroup. This works because each local master browser periodically synchronizes its browse list with the domain master browser. During this synchronization, the local master browser passes on the name of any server that the domain master browser does not have in its browse list, and vice versa. Each local master browser eventually holds the browse list for the entire domain.’
The significance of step 3 now starts to become clear. In the case where there is no WINS server, synchronisation of browse lists across subnet boundaries between the local master browser and the domain master browser will not occur because of the non-routable nature of broadcast messages. When a WINS server is employed, every local master and the domain master register with the WINS server and are able to find each other across subnet boundaries using unicast messages, which can be routed. In addition, the ability to connect to a resource in the network neighbourhood that is located on another subnet depends on the ability to resolve the resource’s name. WINS-enabled computers support this adequately.
To make the FreeNAS server a domain master browser for a workgroup, in the FreeNAS GUI, under the SMB service, add the line domain master = yes to the Auxiliary parameters section.
Once saved, it won’t take long for the network neighbourhood to include SMB servers from other subnets. WINS enables the computer browser service to collect and distribute browse lists across subnet boundaries.
Network Browser Tools
How does the master browser nominate a backup browser? How do I identify the backup browser? These questions were not answered well through my research. The closest I got came from this article, which suggested that backup domain controllers are backup browsers in a domain. Not a very helpful answer if we’re talking about an environment, such as a workgroup without domain controllers.
The built-in command line tool nbtstat can confirm that the nominated FreeNAS server in a subnet is the master browser. However, it is not able to identify a server that is the backup browser. The format of the command is:
c:\> nbtstat -a <server name>
Refer to this article for more information on its usage. This tool is clumsy to use if you’re not sure which server is the master browser in the first place.
Nirsoft’s NetBScanner held some promise in identifying the master browser in a subnet if the nominated server was not known. However, it did not work for me as it only showed a spattering of client computers on my network and wasn’t able to identify the FreeNAS servers.
Microsoft provided the browstat and browcon tools for Windows 2000 for monitoring the browser service. The latter can be downloaded here. However, as I found out the hard way, it doesn’t work with workgroups, only domains. It is used as a wrapper around the command line tool browstat, which is included in the package. Browstat does work with workgroups so this is one way of getting the utility. If you have a copy of the Windows 2000/NT4 Resource Kit, the browstat utility is included in the resource kit as well.
There is still the problem that browstat will not run on later Windows platforms such as Windows 10. Fortunately, I had Windows 2000 workstation installed in a VM so I could use browstat. If you do not have access to a networked Windows platform that will run browstat, then, unfortunately, you’ve lucked out. In foraging around the web, I’ve found nothing else that replaces browstat for monitoring the browser service. Here you will find an easy to follow guide for browstat and this is a more detailed reference from Microsoft.
I was curious to find out which computer would be chosen to be the backup browser. Using browstat, I was able to establish that the FreeNAS server that was the master browser advertised itself as the backup browser so it would respond directly to client requests for the browse list. See the screenshot below.
So it turns out that the FreeNAS server I had set up as domain master browser and the master browser was also my backup browser. This makes sense for small workgroups, but it does contradict somewhat what all the research was suggesting about clients obtaining their browse list from the backup browser rather than the master browser.
References
- EternalBlue
- SMB1 Product Clearinghouse
- Explorer Network Browsing under Windows 10
- How Computer Browser Service Works
- Browser Elections
- NetBIOS over TCP/IP
- Name Resolution and Browsing
- Combating WannaCry and Other Ransomware with OpenZFS Snapshots
- Nirsoft’s NetBScanner
- NetBIOS Browsing Console (Browcon)
- Browstat | IT Pro
- MS Windows NT Browser
- What is WINS?
- How NetBIOS name resolution really works
- Ace Fekay blog. (Best reference!)
- DHCP/DNS Server on FreeNAS
- Principles of NetBIOS names
- SMB1 and the computer browser service
- Forbes: Decades-Old Network Protocol Puts Companies At Risk And Refuses To Die
- FreeNAS 11.1-U6
Excellent article Basil. Clearly written & illustrated. I found it very helpful!