Red Hat Bugzilla – Bug 1038959
samba browsing blocked even with the samba-client service enabled, works with connection/interface in 'trusted' zone
Last modified: 2016-01-10 18:37:35 EST
So I've kinda been noticing this bug forever, but only decided to dig into it today...and it looks pretty weird. The problem is samba browsing, and how it doesn't work. If I run 'smbtree -N' on any Fedora system on my network with firewalld enabled, I get either nothing or just the shares provided by the machine it's run on. I've verified this in a completely fresh environment: a clean VM booting a Fedora 20 Final TC5 live image. Run 'smbtree -N', nada. Open nautilus and try browsing 'Windows Network', you get an error. Okay, so firewalld has the 'samba-client' service. OK. Enable that for the appropriate zone, re-run smbtree -N, and...tada!...still nada. Hmm. Maybe we need 'samba' too? Nope. Doesn't help. Only if I put the network connection in the 'trusted' zone does it work. I'll attach wireshark captures of the mentioned configurations, to see if we can isolate what exactly is the difference. 192.168.1.13 is the test machine, 192.168.1.9 is my NAS (Thecus N5550) providing various shares, 192.168.1.2 is a Windows 7 machine on the network (SAMMY-PC). Anything else is likely noise. I felt like for sure someone must've reported or at least noticed this before, but I just can't find any discussion of it. But it's certainly completely broken for me, and I have multiple SMB/CIFS hosts on my network running a variety of server software, and I'm pretty sure I saw the same thing when I took my laptop to the UK and connected to my family's network; I couldn't browse there either.
So the obvious smoking gun I see in the wireshark output: in every failure log I've seen, there is an attempt by the client (machine trying to browse) to ping (ICMP) a server that just responded to its NBNS broadcast query, and that ping failing. In the success log, I see neither a successful nor a failed ping. See packet #5 in the 'samba-client service allowed' log.
Created attachment 833479 [details] stock.pcapng: wireshark capture of 'smbtree -N' attempt with completely stock settings
Created attachment 833480 [details] samba-client.pcapng: wireshark capture of 'smbtree -N' attempt with 'samba-client' service allowed in firewalld config
Created attachment 833481 [details] trusted.pcapng: wireshark capture of 'smbtree -N' attempt with interface in trusted zone
well, maybe it's not just a ping at that. I'm no expert at reading wireshark captures, but it looks like the ICMP packet has an NBNS packet inside it.
Ah, OK, I think I grok it better now. Compare packet #5 in 'samba-client' and #12 in 'trusted'. I think they're the same packet - some kind of NBNS setup stuff - getting incorrectly blocked in 'samba-client'. wireshark's identification of it as 'ICMP' in 'samba-client' is a result of it being blocked.
It looks like the packet is rejected as "Host administratively prohibited". I guess that lines up with the rules at the end of the INPUT and FORWARD chains of firewalld's iptables config: Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere INPUT_direct all -- anywhere anywhere INPUT_ZONES_SOURCE all -- anywhere anywhere INPUT_ZONES all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere FORWARD_direct all -- anywhere anywhere FORWARD_IN_ZONES_SOURCE all -- anywhere anywhere FORWARD_IN_ZONES all -- anywhere anywhere FORWARD_OUT_ZONES_SOURCE all -- anywhere anywhere FORWARD_OUT_ZONES all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-host-prohibited those are the only "reject-with icmp-host-prohibited" rules I see in iptables...
My guess is that there's some problem with the NetBIOS name service broadcast connection tracking helper - nf_conntrack_netbios_ns. Adam, could you make sure it's loaded (lsmod | grep nf_conntrack_netbios_ns) when you enable the samba-client service ?
The module appears to be loaded on boot - when I boot a live image it's loaded already. I don't see any kind of change in its status when I check/uncheck samba-client in firewall-config.
Hi, From https://sourceforge.net/p/smb4k/wiki/TroubleShooting_EmptyBrowser/ Open Ports in Your Firewall Open the ports 137 (TCP+UDP), 138 (UDP), 139 (TCP+UDP), and 445 (TCP +UDP) in your firewall. firewalld config don't have a couple of this rules from samba or samba-client , I add some ports and protocols in service samba like 137 TCP 139 UDP 445 UDP , but no luck ... after go to here: http://www.novell.com/coolsolutions/feature/11952.html Set the firewall to allow ICMP (Internet Control Message Protocol) with following types. 0 (Echo request) 8 (Echo Reply) 3 (Destination unreachable)(This one is optional but useful) Allow Traffic for the Windows network by opening the following ports for SMB both TCP and UDP Port Number Traffic Type 445 Microsoft-DS 135 DCE endpoint resolution 136 137 NETBIOS Name Service 138 NETBIOS Datagram Service 139 NETBIOS session service but still just works with "trusted" zone lsmod | grep nf_conntrack_netbios_ns nf_conntrack_netbios_ns 12665 0 nf_conntrack_broadcast 12527 1 nf_conntrack_netbios_ns nf_conntrack 86430 11 nf_conntrack_netbios_ns,ipt_MASQUERADE,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,nf_conntrack_broadcast,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6 The problem unless trusted zone , firewall blocks here : 11 13.536262000 10.0.2.15 192.168.1.253 ICMP 132 Destination unreachable (Host administratively prohibited) I can I unblock it ?
The problem is firewall blocks here : 11 13.536262000 10.0.2.15 192.168.1.253 ICMP 132 Destination unreachable (Host administratively prohibited) just don't block in "trusted" zone How I can unblock it ? for other zone
Thomas: is there anything more I can do to help with this? It seems like a significant bug and I was kinda happy to finally trace it out to some extent, I was hoping we could get it fixed fairly soon (for F20 final ideally, but I think that ship has sailed). Thanks!
So, we poked at this quite a bit in IRC today. We're not to the bottom of it yet, but it's not totally straightforward. This seems to be specific to F20, in some way. If I boot an F19 live image on a clean test system and run 'smbtree -N' - absolutely no configuration of anything required, not even the 'samba-client' firewalld service - I see my servers fine. If I boot an F20 RC1 live image on the same system, same servers, same everything, and try the same thing, I see nothing. Adding the network interface to the 'trusted' zone works fine every time, so it's definitely the firewall causing problems, but it's not as straightforward as some firewalld config being wrong. Right now we suspect that nf_conntrack_netbios_ns is behaving differently in F19 and F20 somehow...
Adding a rule to accept all from souce port 137/udp makes it work again, but this is not a good solution.
(In reply to Adam Williamson from comment #13) > So, we poked at this quite a bit in IRC today. > > We're not to the bottom of it yet, but it's not totally straightforward. > This seems to be specific to F20, in some way. > > If I boot an F19 live image on a clean test system and run 'smbtree -N' - > absolutely no configuration of anything required, not even the > 'samba-client' firewalld service - I see my servers fine. > > If I boot an F20 RC1 live image on the same system, same servers, same > everything, and try the same thing, I see nothing. > > Adding the network interface to the 'trusted' zone works fine every time, so > it's definitely the firewall causing problems, but it's not as > straightforward as some firewalld config being wrong. Right now we suspect > that nf_conntrack_netbios_ns is behaving differently in F19 and F20 > somehow... When you booted your "F19 live image", was that the original F19 GA live image? Because that has a different kernel (much older) kernel than F20. At this point F19 and F20 are on virtually identical kernels, so figuring out if this also impacts an updated F19 would be good. If it doesn't it's likely something elsewhere that changed between F19 and F20. If the kernel version does matter, then you can upgrade kernel major versions to see where the suspected change came in at. Though looking at the git tree, there hasn't been a change to net/netfilter/nf_conntrack_netbios_ns.c since 2011 (2.6.39) so I'm not sure that's really the culprit. Adding Neil, Jiri, and Jeff to CC.
Thomas mentioned on IRC that 3.12 from koji is working fine on F19. He's going to try the F20 kernel on F19 as well.
Thomas mentioned the F20 kernel on F19 works as well. This is looking like an issue in something other than the kernel.
jwb: when I tested a 19 live image it was GA, yeah, but a fully updated 19 install running 3.11.10-200.fc19 behaves the same (i.e. works). I'd tend to agree that as of now it doesn't look like the issue is in the kernel.
As this is actually a new bug in F20 and we didn't figure out a fix yet, we should document this...
I tested this in RHEL 7 public beta too, just for the heck of it. Bug seems to exist there too, nothing from 'smbtree -N' with OOTB config or 'samba-client' enabled, works if I stop firewalld.service (couldn't test putting it in 'restricted' zone easily because it seems incredibly RAM hungry, and when I boot it to GNOME the VM exhausts all RAM and freezes after like 2 minutes). Not sure how important this is to RHEL.
(In reply to Thomas Woerner from comment #14) > Adding a rule to accept all from souce port 137/udp makes it work again, but > this is not a good solution. Not sure why you are claiming it is not a good solution since it is a requirement: NetBT browsing requires 137/udp connectivity by design since 137/udp is the port used for name services in NetBIOS over TCP/IP. See this TechNet article for more details: http://technet.microsoft.com/en-us/library/cc940063.aspx
*** Bug 1023918 has been marked as a duplicate of this bug. ***
Samba browsing with Nautilus is working again for me since one week.
I have verified this a bit more. On a machine, where it is working, the incoming packets from port 137 are accepted with the RELATED,ESTABLISHED line in the firewall. On a system, where is not working the packet is not accepted by this line. The firewall configuration is the same on both machines. This is not a firewalld issue. It seems to be a problem somewhere in netfilter (kernel). Reassigning to kernel.
With the latest updates in F-20 (including kernel 3.12.6-300) samba browsing is working now as expected. There has not been an update of iptables or firewalld.
This was a bug in NetworkManager. The broadcast address of the interfaces has been set to 0.0.0.0. Using the latest NetworkManager update or fixing the broadcast address manually fixes the problem. Reassigning to NetworkManager. Closing as duplicate for 1032819. *** This bug has been marked as a duplicate of bug 1032819 ***