Red Hat Bugzilla – Bug 120719
Default firewall rules block NMB traffic
Last modified: 2007-11-30 17:10:40 EST
The default firewall rules in this tool block NMB traffic, which
prevents Windows Network Neighbourhood browsing from working
correctly. The best fix is not the proposed patch, but this is the
best that can be done in the short term. Given that the most likely
effect of this problem is users disabling the firewall entirely, I
think it should be applied.
Created attachment 99360 [details]
A "cannonball" approach: Enable all incoming traffic on UDP port 137.
Eek, a SMB/NMB checkbox is better.
That's fine, as long as it's not blocked by default. I'd guess most
users could not link "nothing appears in windows network browsing" to
"NMB is checked in the firewall config program".
Mike: When you enable the firewall, all ports and services are blocked
by default. The user has to intentionally select those checkboxes to
open those ports. Being "secure by default" has its advantages even
if it means losing a bit of convenience out of the box.
Alright, I understand that. In that case there needs to be some
ultra-clear way of letting the user know that the reason they are
seeing nothing in the NetHood is because of the firewall. At the
moment it silently fails, which is really bad.
Unfortunately code which accesses the SMB network is all over the
place. For instance, in gnome-vfs, in system-config-printer, and so
on. So it's probably better to add a checkbox and warn the user inside
system-config-securitylevel that if this box is checked they won't be
able to browse windows networks.
Created attachment 99431 [details]
patch to lokkit to create an SMB checkbox
notting: This is a patch to add a SMB checkbox to lokkit. Can you take a look
at it and see if it's sane? If this is ok, I'll add a SMB checkbox to the
a) you probably need more than just TCP
b) ideally, the kernel's stateful firewall would catch this
c) this unintentionally opens up any local SMB server for general access.
notting: what would be a better way?
Technically, this is a dup of #58004, one way or another. The kernel
fix is the 'preferred' one, but that may take a while.
*** This bug has been marked as a duplicate of 58004 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.