Firewall blocks netbios name resolution after updates

I have two virtual Linux machines running under VirtualBox (one is Leap 42.1, the other SUSE 13.2) on separate windows PCs (one Win 7 the other Win 10). Both Linuxs systems have been working fine along with samba behind their local firewalls. I did a batch update and suddenly there was no name resolution working anymore using either nmblookup or smbtree -N (my system for a number of reasons has no local DNS update service added to the DHCP server so nslookup has and still fails).

Turning off the firewall makes everything work again, turning it back on (and rebooting to clear cached entries) makes it all fail. I have checked the firewall, deleted the services for Samaba and NetBIOS and then readded them but still the only thing that makes it work is turning off the firewall altogether. Aparmor is not enabled and other windows machines on my network can see shares on both Linux boxes. I tried explicitly opening the required ports in the firewall but still to no avail.

All I can tell is that it is an update since Feb 3rd this year as I have Snapshots that I can roll back too and it’s all working again. Both boxes are acting as servers (one web and one SQL) and so nothing else has changed to then since Feb. Comparing iptables -L I can see no difference between the chains lists before and after the snapshot.

Has anyone else seen this? Any ideas anyone?

Thanks.

PS Yes, I have tried rolling back and doing selective updates (there are nearly a 100!). I held back all samba, Yast and firewall updates in an attempt to isolate the culprit but it all got very long winded and appears not to be associated with an obvious update.

If you’re deploying SAMBA 3, then you’re likely still using NetBIOS name resolution, open in your FW Private zone if necessary, but also consider whether your firewall is incorrectly facing the wrong way…
TCP port 138
UDP port 137

If you’re deploying SAMBA 4, then I’d ask why you’re still using NetBIOS name resolution, AFAIK the default and common configuration is to use Hostname resolution and not NetBIOS name resolution although I assume there may be an optional config to support.

TSU

I am using Samba 4. I am using NetBIOS because my DHCP server is in a Draytek router and does not support the adding of hostnames to its DNS server and DNS forwarding to the internet. I need to redirect a web page to a RaspberryPi which is monitoring aircraft traffic and running a samba service. There was no issue as the redirection fell back to use NetBIOS for name resolution. But then these updates killed NetBIOS name resolution on both virtual serves. It looks like I have to either remove the firewall or go for static IP references which I really dislike.

If you have any servers running (on all the time), it’s really easy to set up your own DNS server, and unless you support at least hundreds of simultaneous connections the additional load on that machine is negligible, which means it won’t noticeably affect anything else running on that machine.

Or, I wonder how expensive a replacement router would be. I assume anything that doesn’t support Hostname resolution has to be really ancient… I don’t know of any devices that prioritizes or supports only NetBIOS name resolution sold in the last 15 years at least. Even MSWindows which was the foremost practitioner of NetBIOS name resolution started phasing it out in 2000 and pretty much killed it off nearly completely by 2005.

Also, you’re severely limited by NetBIOS naming conventions when it’s used to support websites, since strictly speaking it has a very short name length limitation, doesn’t support some special characters including the “dot” in Hostnames.

TSU

I appreciate your comments BUT the point here is that something that was working just broke because of an update and it has done this on two totally differently configured systems running different versions of SUSE. As I can roll back the virtual machines I can see and demonstrate that the regression is totally repeatable.

Although anything is possible,
I’d suggest you open the FW ports I specified to be absolutely certain that an update somehow radically modified a FW configuration… It’s possible but I’ve never seen that happen.

Did you explicitly open ports in your “before” configuration?
Are you certain that your LAN Hosts are in the “Private” zone or might they be in another zone?

The other possibility is that because nowadays no one should really be using NetBIOS name resolution except in very rare circumstances that the ports became closed by default but I still would think that’s an extraordinary decision in the highly permissive Private zone.

TSU

Originally I simply opened the ports by adding “NetBIOS server” set as an “Allowed Service”, I did not explicitly open the ports. Since it stopped working I have tried explicitly opening the ports but Yast will not acknowledge them being opened while I have “NetBIOS server” set as an “Allowed Service”. I have tried removing “NetBIOS server” set as an “Allowed Service” and then explicitly opening the ports but that did not work either.

Given they are virtual machines and I have a working snapshot I compared the working and non-working outputs of iptables -L. They are identical (like for like comparison i.e. when not explicitly trying to open the ports) so I don’t think its the actual configuration of the firewall but I may be missing something here.

Not quite sure what you mean by “Private Zone”. I have the interface configured in YaST/firewall as the “External Zone” and to be honest don’t quite understand the significance of the zones. Happy to be educated :wink:

Tomorrow I will try a fresh install of a basic system and see if I can configure the firewall to the point that smbtree -N gives sensible output. This may just be that as you say that NetBIOS name resolution is used so little (behind a firewall) that the regression has not yet been noticed by others.

You should verify your SAMBA NetBIOS name cache server is running in the first place, if it’s not already running determine why.

systemctl status nmbd.service

If the service is already running, you may need to purge the existing cache by restarting the service

systemctl restart nmbd.service

TSU

Did a completely fresh clean install (on Virtual Box) of Leap 42.1 over the net overnight. Added “NetBIOS server”, “Samba Server” and “Samba Client” set as “Allowed Service” to the firewall and a very basic (virtually default but enabled ‘Use Wins for Hostname Resolution’) Samba config, all done via YaST GUI. A simple “smbtree -N” worked perfectly and listed all my shares on my network.

Then the automatic updates kicked in and updated the system. Now “smbtree -N” gives nothing in the way of output. Toggling the firewall off and on allows me to change the functionality from working to not working.

I compared “/etc/sysconfig/SuSEfirewall2” on both the working and not working snapshots of my SUSE13.1 system and they were identical.

I do not know how to proceed. Looks definitely like a regression.

Did you try the suggestion in my last post?
The idea is that although you may have opened the NetBIOS port, the service behind the port may not be running.

TSU

Yes, I checked the service was running with

service nmb status

and it was. Restarting it made no difference.

Again toggling the firewall changes the functionality. So I really think it has to be firewall related.

Check your iptables configuration

cat /etc/sysconfig/system-**config**-firewall

TSU

Today a single recommended update was installed to wicked (claimed to be a bug fix and now is version 0.6.31-33.1) and now it is working again after a reboot on both virtual machines. Previous versions were installed April 5 and Feb 22 so that could have been the source of the regression.

All’s well that ends well rotfl!-