In Leap 42.3 I get this:
-A input_ext -p udp -m udp --sport 137 -m conntrack --ctstate RELATED -j ACCEPT
-A input_ext -p udp -m conntrack --ctstate RELATED -j ACCEPT
I think, in the second line the port is missing? I don’t know, how to change this
Spielmops
From what you’ve posted here I can see that your firewall is probably not configured to accept NetBIOS broadcasts. I had a quick look at the services defined for SuSEfirewall2, and can see that samba-client service is defined like this (which matches the iptables output you’ve posted)…
~> cat /etc/sysconfig/SuSEfirewall2.d/services/samba-client
## Name: Samba Client
## Description: Enables browsing of SMB shares
RELATED="0.0.0.0/0,udp,137"
MODULES="nf_conntrack_netbios_ns"
To allow broadcasts it would need to look like this…
## Name: Samba Client
## Description: Enables browsing of SMB shares
RELATED="0.0.0.0/0,udp,137"
MODULES="nf_conntrack_netbios_ns"
# space separated list of allowed UDP ports that accept broadcasts
BROADCAST="netbios-ns"
This would then take effect the next time you attempted to configure the firewall (with samba-client). The other way would be to just allow port 137 UDP manually (via YaST > SuSEfirewall2). Please Bare in mind that using NetBIOS is considered a security risk these days, but I accept that some users would miss the convenience factor of “automatic discovery”. One of many articles on the subject…
https://www.techrepublic.com/blog/it-security/the-problem-with-netbios/
Thank you for porting this problem.
I changed the file “samba-client” to the proposed lines, deleted samba-client in the firewall, restartet the firewall, inserted samba-client and restarted the firewall again.
iptables -S |grep -i accept
gives this output:
...
-A input_ext -p udp -m pkttype --pkt-type broadcast -m udp --dport 1764 -j ACCEPT
-A input_ext -p udp -m pkttype --pkt-type broadcast -m udp --dport 137 -j ACCEPT
-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A input_ext -p udp -m udp --sport 137 -m conntrack --ctstate RELATED -j ACCEPT
-A input_ext -p udp -m conntrack --ctstate RELATED -j ACCEPT
-A input_ext -p tcp -m tcp --dport 1714 -j ACCEPT
...
I’m no expert, but I assume, that the second line for post 137 overwrites the first?
Workgroup-discovery is not working - “This might be caused by an enabled firewall.”
Spielmops
No, the first two rules allow broadcast traffic from port 1764 UCP and port 137 UDP respectively. However, it’s only the latter that’s of relevance here for NetBIOS broadcsts.
Workgroup-discovery is not working - “This might be caused by an enabled firewall.”
Spielmops
For security reasons SMBv1 (NT1) is now disabled by default. Read this post for more background about that
https://forums.opensuse.org/showthread.php/528981-smb-doesn-t-show-workgroup?p=2868138#post2868138
It can be enabled to allow workgroup discovery by editing /etc/samba/smb.conf to include
[global]
client max protocol = NT1
…but I assume you already did that?
BTW, can you see the samba shares using the following command?
smbtree
Half an hour later:
I changed the firewall from Susefirewall to firewalld (Leap 15). It was very easy and workgroup-discovery works.
Enable service firewalld, start firewalld. Execute firewall-config, set configuration to permanent, add service samba-client, add protocol udp, restart firewall. Thats it …
Spielmops
I moved to using firewalld with Leap 42.3 (last year IIRC) as I wanted to familiarize myself with it (although I normally don’t have it active). Anyway, glad to read that workgroup discovery is now working for you as desired. 
I had some Leap 42.3 machines sudden stop showing shares in the WORKGROUP, so I’d have to specifically connect with SMB://NAS/etc. I assume after some update happened in the last few weeks. Using the smb.conf suggestion of
client max protocal = NT1
worked to get those machines seeing NAS shares in the Network / WORKGROUP browse.
I still have had a problem with my Leap 15 machine since day 1 with the different firewall. Even during fresh installs the firewalld gave what seemed like random errors when trying to launch it. I was finally able to get it configured properly by doing a fresh install and launching the firewall almost right away which prompts to install firewalld …BEFORE doing any other settings in Yast.
Still had the browsing shares problem since day 1 though, and was thinking about going back to 42.3.
I tried all the SAMBA settings suggestions from many posts, app armor, Mircosoft domain, smb nmb config, and setting the SMB protocal as NT1. Nothing worked. So now I just tried the option that somebody mentioned earlier in the posts --before this got moved to the new thread.
Changing from the home zone, to the trusted zone suddenly had the browse working again.
So even with the smb service checked in home zone it doesn’t seem to make a difference. Only trusted zone seems to work, since it’s allowing all connections.
Are there specific settings that work in the home zone to get the smb browse working?
I’m new, so wasn’t sure how to edit my post above.
Anyway, I was using the GUI for firewalld. It looks like the check-marks weren’t doing their job, even though the status line said configurations changes made.
using the command line I was able to add the samba service to the zone, and browsing the network shares in the WORKGROUP everything is working now with the home zone.
firewall-cmd --add-service=samba --zone=home
Enabling just the samba-client service should be sufficient, which allows incoming (NetBIOS broadcasts) on port 137 UDP.
Note that if you make a change to firewalld with permanent mode it will not be applied until the firewall is restarted, so perhaps that’s why it didn’t appear to work. The only difference between zones is the predefined services. You’re free to adjust as you require.