Prevent Linux firewalls interfering with Samba commands in a home network that uses broadcast NetBIOS name resolution

Or “How come devices in a home network can browse SMB shares but Linux Samba commands and Windows nbtstat commands do not work properly?”

Introduction

In a previous post I explained how it is possible to browse SMB shares when using broadcast NetBIOS name resolution in a home network consisting of machines running Linux, Windows and other operating systems. Browsing SMB/Samba shares will work as expected, but Samba commands such as ‘smbtree‘, ‘smbclient‘ and ‘nmblookup‘ will not work properly if the Linux machines use a firewall that has not been configured for broadcast NetBIOS name resolution. This post is to explain how to do that.

If broadcast NetBIOS name resolution is being used and none of the Linux machines has a firewall enabled, or if their firewalls have been correctly configured, the output of e.g. the ‘smbtree‘ command on one of those machines would look something like the example below.

anne@akhanaten:~$ smbtree
Enter anne's password: 
HOME
        \\AKHANATEN                     Samba 4.3.11-Ubuntu
                \\AKHANATEN\IPC$                IPC Service (Samba 4.3.11-Ubuntu)
                \\AKHANATEN\guest               guest account
                \\AKHANATEN\matthew             matthew share
                \\AKHANATEN\marilla             marilla share
                \\AKHANATEN\anne                anne share
        \\TUTANKHAMUN                   Samba 4.5.10
                \\TUTANKHAMUN\Samsung_Xpress_C460FW     Samsung Xpress C460FW
                \\TUTANKHAMUN\Canon_MP560_Printer       Canon PIXMA MP560
                \\TUTANKHAMUN\Canon_MP510_Printer       Canon PIXMA MP510
                \\TUTANKHAMUN\Virtual_PDF_Printer       Virtual PDF Printer
                \\TUTANKHAMUN\IPC$              IPC Service (Samba 4.2.11)
                \\TUTANKHAMUN\Public
                \\TUTANKHAMUN\anne-share
                \\TUTANKHAMUN\print$
                \\TUTANKHAMUN\netlogon          Network Logon Service
        \\BTHUB5                        BT Home Hub 5.0A File Server
                \\BTHUB5\IPC$                   IPC Service (BT Home Hub 5.0A File Server)
        \\THUTMOSEIII                   Windows 10 computer

If Linux firewalls have not been correctly configured, the output would be missing some information about other machines in the network. For example, compare the output above with the output below from the same network, this time with the Linux firewalls configured using typical rules for Samba specified in Web articles, blog posts and forums.

anne@akhanaten:~$ smbtree
Enter anne's password: 
HOME
        \\AKHANATEN                     Samba 4.3.11-Ubuntu
                \\AKHANATEN\IPC$                IPC Service (Samba 4.3.11-Ubuntu)
                \\AKHANATEN\guest               guest account
                \\AKHANATEN\matthew             matthew share
                \\AKHANATEN\marilla             marilla share
                \\AKHANATEN\anne                anne share
        \\TUTANKHAMUN                   Samba 4.5.10
        \\BTHUB5                        BT Home Hub 5.0A File Server
        \\THUTMOSEIII                   Windows 10 computer

To avoid this problem you need to add a further Linux firewall rule to the set of rules usually used for Samba. Below I first list the usual firewall rules for Samba, then I give the additional rule necessary if using broadcast NetBIOS name resolution. In each case I give the applicable rules for a pure IPTABLES firewall and for UFW (Uncomplicated Firewall). The rules listed here assume the IP address range of the home network is 192.168.1.0/24, so change the range to suit the specific network.

Firewall rules typically specified for machines using Samba

IPTABLES

The rules listed below assume the machine uses interface eth0, so change the interface to suit the specific machine.

# NetBIOS Name Service (name resolution)
iptables -A INPUT -i eth0 -p udp --dport 137 -s 192.168.1.0/24 -j ACCEPT

# NetBIOS Datagram Service (BROWSER service)
iptables -A INPUT -i eth0 -p udp --dport 138 -s 192.168.1.0/24 -j ACCEPT

# NetBIOS Session Service (data transfer legacy SMB/NetBIOS/TCP)
iptables -A INPUT -i eth0 -p tcp --dport 139 -s 192.168.1.0/24 -j ACCEPT

# Microsoft Directory Service (data transfer SMB/TCP)
iptables -A INPUT -i eth0 -p tcp --dport 445 -s 192.168.1.0/24 -j ACCEPT

UFW

In some Linux distributions the ufw application allows a single command to add Samba support, such as:

user $ sudo ufw allow Samba

or

user $ sudo ufw allow CIFS

These ‘application profiles’ are specified in files in the directory /etc/ufw/applications.d/, so you could add application profiles or modify existing ones if you wish. In one of my installations the file /etc/ufw/applications.d/ufw-fileserver includes the following application profile for Samba, for example:

[CIFS]
title=SMB/CIFS server
description=SMB/CIFS server
ports=137,138/udp|139,445/tcp

If such an application profile does not exist in your installation, typical Samba rules can be added in UFW using the following two commands:

user $ sudo ufw allow from 192.168.1.0/24 to any port 137,138 proto udp
user $ sudo ufw allow from 192.168.1.0/24 to any port 139,445 proto tcp

The correct addition of the rules can be checked using the following command:

user $ sudo ufw status verbose
Password:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
137,138/udp (CIFS)         ALLOW IN    192.168.1.0/24
139,445/tcp (CIFS)         ALLOW IN    192.168.1.0/24

The extra rule required when using broadcast NetBIOS name resolution

The reason why an extra rule is required when using broadcast NetBIOS name resolution is because UFW (which is based on IPTABLES) is ‘stateful’, as is a purely IPTABLES firewall (unless explicitly configured not to be stateful). The firewall does not consider packets it receives in response to its broadcast to be ESTABLISHED or RELATED, and therefore drops those packets. So, despite the IPTABLES and UFW rules listed above including a rule to accept incoming UDP packets on Port 137, any UDP packets received on Port 137 that do not constitute a one-to-one, two-way communication flow are dropped by the firewall. The extra rule below overrules this and makes the firewall accept packets coming from other devices’ Port 137 in response to broadcast NetBIOS Name Service packets. To do this, the extra rule uses a CT (Connection Tracking) helper named ‘netbios-ns‘ (obviously meaning ‘NetBIOS Name Service’). In order to use this rule the kernel must have been configured to use the IPTABLES ‘raw‘ table and to use CT (see the section ‘Kernel configuration’ further on).

IPTABLES

# All NetBIOS clients must have the netbios-ns helper enabled for broadcast name resolution to work
iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns

By the way, in addition to flushing the usual tables, flush the ‘raw‘ table too when you restart the firewall:

iptables -t raw -F OUTPUT

UFW

Add the following lines to the end of the file /etc/ufw/before.rules

# The following is needed to enable Samba commands to
# work properly for broadcast NetBIOS name resolution
#
# raw table rules
*raw
:OUTPUT ACCEPT [0:0]
-F OUTPUT
-A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns
COMMIT

Note that the output of the command ‘ufw status verbose‘ will not include the above rule. This is not a bug.

Kernel configuration

If you are using a binary-based distribution such as Ubuntu Linux, the kernel will probably have been configured to include the needed modules (CONFIG_IP_NF_RAW=m, CONFIG_IP6_NF_RAW=m and CONFIG_NETFILTER_XT_TARGET_CT=m), and the installation configured to load the modules automatically. However, if you are using a source-based distribution such as Gentoo Linux make sure the kernel configuration includes these three options before you build the kernel, and also add the module names ‘iptable_raw‘ and ‘xt_CT‘ to the module list in the file /etc/conf.d/modules as shown in the example below, so that the modules are loaded at boot:

modules="r8169 nvidia agpgart fuse bnep rfcomm hidp uvcvideo cifs mmc_block rtsx_pci snd-seq-midi vboxdrv vboxnetadp vboxnetflt iptable_raw xt_CT"

You can use the following two commands to check if the two modules are loaded:

user $ sudo lsmod | grep iptable_raw
user $ sudo lsmod | grep xt_CT

How to check the additional rule is active

You can use the command below whether you are using pure IPTABLES or UFW.

user $ sudo iptables -nvL -t raw
Password: 
Chain PREROUTING (policy ACCEPT 2613 packets, 1115K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2773 packets, 475K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   16  1248 CT         udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:137 CT helper netbios-ns

The packet and byte counts will increase whenever you use a Samba command.

Bibliography

  1. The netfilter.org "iptables" project
  2. Iptables Tutorial
  3. Introduction to IPTables
  4. Gentoo Wiki : iptables
  5. Arch Linux Wiki : Samba : "Browsing" network fails with "Failed to retrieve share list from server"
  6. Ubuntu : Manpage : ufw-framework
  7. Gentoo Wiki : UFW

About Fitzcarraldo
A Linux user with an interest in all things technical.

27 Responses to Prevent Linux firewalls interfering with Samba commands in a home network that uses broadcast NetBIOS name resolution

  1. Fitzcarraldo says:

    Those of you who also read my earlier post on Samba/SMB may have noticed that all the machines in the home network in the example above are now in the Windows Workgroup ‘HOME‘ instead of ‘GREENGABLES‘, i.e. they are now in the same workgroup as the BT Home Hub (router + broadband modem) which is fixed as ‘HOME‘ and cannot be changed by the user. There were no problems using the original setup with the BT Home Hub in a separate Windows Workgroup to everything else in the network, but it is tidier to have everything in a single Windows Workgroup.

  2. mumblingfumbler says:

    Your snippet to add to /etc/ufw/before. rules doesn’t work for latest Debian (9.1.0) release of ufw. Here’s the error:

    ERROR: problem running ufw-init
    Bad argument `*raw’
    Error occurred at line: 82
    Try `iptables-restore -h’ or ‘iptables-restore –help’ for more information.

    Problem running ‘/etc/ufw/before.rules’

    • Fitzcarraldo says:

      Is the module iptable_raw loaded?

      • mumblingfumbler says:

        Thanks for replying:
        ——————————————————————————–
        sudo modinfo iptable_raw
        [sudo] password for dheintz:
        filename: /lib/modules/4.9.0-3-amd64/kernel/net/ipv4/netfilter/iptable_raw.ko
        license: GPL
        depends: x_tables,ip_tables
        intree: Y
        vermagic: 4.9.0-3-amd64 SMP mod_unload modversions
        ——————————————————————————–
        I found another way. I took your iptables rule:
        iptables -t raw -A OUTPUT -p udp -m udp –dport 137 -j CT –helper netbios-ns

        shoved it in a script, and dropped the script in:
        /etc/network/if-pre-up.d

        That did the trick for making the rule persist across boots.

        I’d still like to know what is wrong with the ufw solution.

        There was a BROADCAST,….RETURN rule in:
        /etc/ufw/before.rules
        I commented it out–no change.

        Without the iptables rule, smbtree fails to resolve the workgroup and shares and I get nada.

  3. mumblingfumbler says:

    Thanks. It looks like that was the problem. I need a commit both before and after raw rule? Why is that?
    Thanks for your help,
    David

    • Fitzcarraldo says:

      The COMMIT before pertains to the operations on the other table. That’s why my article specified to add the additional lines at the end of the file (i.e. after the existing COMMIT statement).

  4. quicktrick says:

    Hello! Could you please add the rules needed for SuSEfirewall2 and maybe some other smb.info and openSUSE settings (I’ve read your article here https://fitzcarraldoblog.wordpress.com/2016/10/17/a-correct-method-of-configuring-samba-for-browsing-smb-shares-in-a-home-network/). I can see the share in Windows but I cannot browse it.

  5. mumblingfumbler says:

    Well, your raw rule fixed smbtree not showing anything, but my debian firewall is still not allowing server access by netbios name via windows network. It is a name resolution problem, since I can access the server via ip address no problem. Server name shows up in network, but windows can’t access it. When I do ufw disable, it works. Any ideas? Shouldn’t ‘ufw Samba allow’ opened up the appropriate ports? Thanks for your help.

  6. mumblingfumbler says:

    Sorry, never mind. I figured out what was wrong. I had commented out the line:
    # if BROADCAST, RETURN
    -A ufw-not-local -m addrtype –dst-type BROADCAST -j RETURN
    in before.rules, and that broke NetBIOS name service.

  7. Paul B. says:

    Excellent series of articles. Very clear, as far as this Linux sophomore could take them. Added firewall rules. Disabled wins and winbind. But I’ve got the same problem as mumblingfumbler had, and I did not alter before.rules in any other way. I’m on MX17, which is debian 9.2.

    • Paul B. says:

      I can only shake my head. After several reboots, it finally begins to work. For now. Strange.

    • Fitzcarraldo says:

      mumblingfumbler had trouble because he did not follow the article to the letter. Once he did, he no longer had any trouble.

      Have you made sure the modules are loaded?:

      user $ sudo lsmod | grep iptable_raw
      [sudo] password for user: 
      iptable_raw            16384  1
      ip_tables              24576  2 iptable_filter,iptable_raw
      x_tables               40960  17 xt_comment,xt_LOG,xt_multiport,ipt_REJECT,ip_tables,iptable_filter,xt_tcpudp,iptable_raw,xt_limit,ip6t_REJECT,ip6table_filter,xt_addrtype,xt_CT,ip6t_rt,xt_conntrack,ip6_tables,xt_hl
      user $ sudo lsmod | grep xt_CT
      xt_CT                  16384  1
      nf_conntrack          131072  9 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_CT,xt_conntrack,nf_nat
      x_tables               40960  17 xt_comment,xt_LOG,xt_multiport,ipt_REJECT,ip_tables,iptable_filter,xt_tcpudp,iptable_raw,xt_limit,ip6t_REJECT,ip6table_filter,xt_addrtype,xt_CT,ip6t_rt,xt_conntrack,ip6_tables,xt_hl
      

      If the modules are not loaded, you need to load them. If your installation does not use systemd, you can configure your installation to load them automatically at boot by adding the module names to the appropriate file. As I use OpenRC in Gentoo Linux on my laptops, I have added them to the file /etc/conf.d/modules. If your installation uses systemd, you can configure your installation to load them automatically at boot by adding the module names to a new file /usr/lib/modules-load.d/anynameyouwant.conf. Check if a file already exists in directory /usr/lib/modules-load.d/ that contains the names of the two modules.

      • Paul B. says:

        It looks almost the same. The only difference I could see by eye is in this line:

        nf_conntrack          155648  11 nf_conntrack_irc,nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_nat_irc,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_CT,xt_conntrack,nf_nat
        

        The rest seems verbatim:

        paul@precision:~/Desktop$ sudo lsmod | grep iptable_raw
        iptable_raw            16384  1
        ip_tables              28672  2 iptable_filter,iptable_raw
        x_tables               40960  17 xt_comment,xt_LOG,xt_multiport,ipt_REJECT,ip_tables,iptable_filter,xt_tcpudp,iptable_raw,xt_limit,ip6t_REJECT,ip6table_filter,xt_addrtype,xt_CT,ip6t_rt,xt_conntrack,ip6_tables,xt_hl
        paul@precision:~/Desktop$  sudo lsmod | grep xt_CT
        xt_CT                  16384  1
        nf_conntrack          155648  11 nf_conntrack_irc,nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_nat_irc,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_CT,xt_conntrack,nf_nat
        x_tables               40960  17 xt_comment,xt_LOG,xt_multiport,ipt_REJECT,ip_tables,iptable_filter,xt_tcpudp,iptable_raw,xt_limit,ip6t_REJECT,ip6table_filter,xt_addrtype,xt_CT,ip6t_rt,xt_conntrack,ip6_tables,xt_hl
        

        I tried another reboot and it continues to work. This system does not use systemd.

        Thanks again!

  8. Animesh says:

    Thanks so much for this article. It is a needle in a haystack to find on the web but it is a real gem! I lost 2 days trying to bang my head on the wall as to why even with the ufw rules for ports 137 and 138 I was not able to successfully lookup my PCs on the intranet from my bionic server using ‘nmblookup’! All the articles on the web just talk about setting up the basic firewall rules but your article holds the key to the stateful issue.

  9. Stefano says:

    Thanks so clear, so usefull. Great!

  10. David says:

    So far, this hasn’t work for me. I’m using Debian 4.19.0-8-amd64. After adding the 2 modules I started seeing iptables-legacy are present, if that makes a difference.

  11. David says:

    Got it to work. The problem was I needed an extra COMMIT as per the mumblingfumbler reply above. Without that comment it’s not clear that an extra COMMIT is needed and my 1st and natural inclination was to just use the existing COMMIT.

  12. David says:

    Thanks for the great article.

  13. Pingback: Using WS-Discovery to enable Windows 10 to browse SMB shares in my home network of Linux computers | Fitzcarraldo's Blog

  14. Pingback: Moving from Lubuntu 18.04 to 20.10 | Fitzcarraldo's Blog

  15. Fitzcarraldo says:

    Unfortunately, to date a bug in Samba results in the Samba command smbtree only working with SMBv1 (i.e. with ‘client max protocol = NT1‘ in /etc/samba/smb.conf):

    http://samba.2283325.n4.nabble.com/smbtree-command-shows-nothing-with-SMB2-3-td4717529.html

    https://bugzilla.samba.org/show_bug.cgi?id=12876

    If you enter the command smbtree when using SMB2 or SMB3, the command will incorrectly return nothing.

    If your Linux distribution’s package repositories contain nbtscan (http://unixwiz.net/tools/nbtscan.html) and nmbscan (http://nmbscan.g76r.eu/), you could install and use those to provide some of the information that smbtree would provide. For example:

    $ nbtscan -v 192.168.1.1-254

    $ nmbscan -a

    Also, the smbclient command can get a list of shares available on a host. For example:

    $ smbclient -L 192.168.1.70

    $ smbclient -L AKHANATEN

    Irrespective of the above, note that the firewall configuration in this blog post is still required.

    • hashbrown117 says:

      My [debian bullseye] system doesn’t have the raw module it seems, but I don’t know whether I should install it as debian has since shifted from iptables to nftables.
      Is the solution in the blogpost still current for systems like mine? (I definitely cant figure out a way to install iptable_raw online)

      $ cat /etc/*release*
      PRETTY_NAME=”Debian GNU/Linux 11 (bullseye)”
      NAME=”Debian GNU/Linux”
      VERSION_ID=”11″
      VERSION=”11 (bullseye)”
      VERSION_CODENAME=bullseye
      ID=debian
      HOME_URL=”https://www.debian.org/”
      SUPPORT_URL=”https://www.debian.org/support”
      BUG_REPORT_URL=”https://bugs.debian.org/”
      $ sudo lsmod | ag ‘table’
      ip6_tables 36864 52
      nf_tables 245760 552 nft_ct,nft_compat,nft_fib_ipv6,nft_fib_ipv4,nft_counter,nft_chain_nat,nft_limit,nft_fib
      nfnetlink 16384 2 nft_compat,nf_tables
      ip_tables 32768 8
      x_tables 53248 16 xt_conntrack,nft_compat,xt_LOG,xt_multiport,xt_tcpudp,xt_addrtype,xt_recent,ip6t_rt,xt_comment,ip6_tables,ipt_REJECT,ip_tables,xt_limit,xt_hl,xt_MASQUERADE,xt_REDIRECT
      libcrc32c 16384 5 nf_conntrack,nf_nat,btrfs,nf_tables,xfs

      When appending to /etc/ufw/before.rules do you need to tell the ufw service in some way for it to take effect, and would I need to re-add the fix if I run ufw reset?

      • Fitzcarraldo says:

        I don’t use Debian, so cannot be of much help. According to the following blog post by a Debian developer:

        What to expect in Debian 11 Bullseye for nftables/iptables

        This is another step in deprecating iptables and welcoming nftables. But it does not mean that iptables won’t be available in Debian 11 Bullseye. If you need it, you will need to use aptitude install iptables to download and install it from the package repository.

        Therefore I suppose you could install iptables to see if you can then implement the steps.

        I think your best bet regarding using nftables is to ask in the Debian forums, as there should be Debian users who will know about iptables and nftables in Debian.

        Regarding your two remaining questions, if I recall correctly the answer is “yes” to both. As far as the first question is concerned, just use the usual UFW reload command.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.