Good morning, I am contacting you as I have a weird issue. I upgraded firewalld from 4.1.2 to 4.3.3; in 4.1.2 I never had problems with Samba shares, but, with the last update, I can't access my Samba server. I tried disabling and re-enabling the samba service in the firewalld configuration, but I didn't have success. The only way I can access my Samba server is to disable firewalld... I can't figure out why it won't work using the proper service. Thanks in advance.
On 08/30/2016 11:13 AM, Giovanni 'ItachiSan' Santini wrote:
Good morning, I am contacting you as I have a weird issue. I upgraded firewalld from 4.1.2 to 4.3.3; in 4.1.2 I never had problems with Samba shares, but, with the last update, I can't access my Samba server. I tried disabling and re-enabling the samba service in the firewalld configuration, but I didn't have success. The only way I can access my Samba server is to disable firewalld... I can't figure out why it won't work using the proper service. Thanks in advance.
Hello Giovanni,
this might be related to this issue that is already fixed in git repo:
https://github.com/t-woerner/firewalld/commit/42faa017bdf89ea4d050ee7a5d5a28...
Helper modules for services that are enabled in the default zone before starting firewalld are loaded, but not for services that are enabled in an already active zone.
This happened because for these zones the FirewallZoneTransaction is used directly and because of this the added modules are simply not used.
Please verify if the nf_conntrack_netbios_ns is loaded after enabling the samba or sambe-client service:
lsmod | grep nf_conntrack_netbios_ns
You can manually load the module with
modprobe nf_conntrack_netbios_ns
If your issue is then solved, then the upstream fix will help you.
If not then there is another issue.
Regards, Thomas
Il 30/08/2016 13:58, Thomas Woerner ha scritto:
Hello Giovanni,
this might be related to this issue that is already fixed in git repo:
https://github.com/t-woerner/firewalld/commit/42faa017bdf89ea4d050ee7a5d5a28...
Helper modules for services that are enabled in the default zone before starting firewalld are loaded, but not for services that are enabled in an already active zone.
This happened because for these zones the FirewallZoneTransaction is used directly and because of this the added modules are simply not used.
Please verify if the nf_conntrack_netbios_ns is loaded after enabling the samba or sambe-client service:
lsmod | grep nf_conntrack_netbios_nsYou can manually load the module with
modprobe nf_conntrack_netbios_nsIf your issue is then solved, then the upstream fix will help you.
If not then there is another issue.
The module is properly loaded, lsmod gives me this output: $ lsmod | grep nf_conntrack_netbios_ns nf_conntrack_netbios_ns 16384 0 nf_conntrack_broadcast 16384 1 nf_conntrack_netbios_ns nf_conntrack 90112 8 nf_conntrack_netbios_ns,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_conntrack_broadcast,nf_conntrack_ipv4,nf_conntrack_ipv6
I am using the home zone for my WiFi connection. The default zone is the public one though. I sincerely have no idea of why Samba is completely blocked. ^^"
Hello Giovanni,
On 08/30/2016 04:22 PM, Giovanni 'ItachiSan' Santini wrote:
Il 30/08/2016 13:58, Thomas Woerner ha scritto:
Hello Giovanni,
this might be related to this issue that is already fixed in git repo:
https://github.com/t-woerner/firewalld/commit/42faa017bdf89ea4d050ee7a5d5a28...
Helper modules for services that are enabled in the default zone before starting firewalld are loaded, but not for services that are enabled in an already active zone.
This happened because for these zones the FirewallZoneTransaction is used directly and because of this the added modules are simply not used.
Please verify if the nf_conntrack_netbios_ns is loaded after enabling the samba or sambe-client service:
lsmod | grep nf_conntrack_netbios_nsYou can manually load the module with
modprobe nf_conntrack_netbios_nsIf your issue is then solved, then the upstream fix will help you.
If not then there is another issue.
The module is properly loaded, lsmod gives me this output: $ lsmod | grep nf_conntrack_netbios_ns nf_conntrack_netbios_ns 16384 0 nf_conntrack_broadcast 16384 1 nf_conntrack_netbios_ns nf_conntrack 90112 8 nf_conntrack_netbios_ns,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_conntrack_broadcast,nf_conntrack_ipv4,nf_conntrack_ipv6
I am using the home zone for my WiFi connection. The default zone is the public one though. I sincerely have no idea of why Samba is completely blocked. ^^"
More tests are needed now:
1) Are the samba related rules in place for ports 137/udp, 138/udp, 139/tcp and 445/tcp?
2) Is the zone assignment correct in the output of "firewall-cmd --get-active-zones"?
3) Is samba working if firewalld is turned off temporarily?
Regards, Thomas
Il 31/08/2016 11:43, Thomas Woerner ha scritto:
Hello Giovanni, ... More tests are needed now:
- Are the samba related rules in place for ports 137/udp, 138/udp,
139/tcp and 445/tcp?
As you can see, the service is untouched:
$ firewall-cmd --info-service=samba samba ports: 137/udp 138/udp 139/tcp 445/tcp protocols: source-ports: modules: nf_conntrack_netbios_ns destination:
Also, I made an additional service, as I saw that some implementation (Windows, maybe?) requires all (TCP+UDP) ports on range 137-139:
$ firewall-cmd --info-service=samba-additional samba-additional ports: 137/tcp 138/tcp 139/udp protocols: source-ports: modules: destination:
- Is the zone assignment correct in the output of "firewall-cmd
--get-active-zones"?
My WiFi card (iface wlp3s0) use the "home" zone:
$ firewall-cmd --get-active-zones public interfaces: enp0s20u3u2 home interfaces: wlp3s0 sources: 192.168.0.1/24
and in the "home" zone, the service is activated properly:
$ firewall-cmd --info-zone=home home (active) target: default icmp-block-inversion: no interfaces: wlp3s0 sources: 192.168.0.1/24 services: dhcpv6-client mdns ntp samba samba-additional ssdp ssh steam transmission ports: 4321/tcp 4321/udp protocols: masquerade: no forward-ports: sourceports: icmp-blocks: rich rules:
- Is samba working if firewalld is turned off temporarily?
Yup. Test with ping:
$ systemctl start firewalld $ LANG=C ping -c 5 ubuntu_server ping: ubuntu_server: Name or service not known $ systemctl stop firewalld $ LANG=C ping -c 5 ubuntu_server PING ubuntu_server (192.168.0.69) 56(84) bytes of data. 64 bytes from 192.168.0.69 (192.168.0.69): icmp_seq=1 ttl=64 time=3.89 ms 64 bytes from 192.168.0.69 (192.168.0.69): icmp_seq=2 ttl=64 time=3.08 ms 64 bytes from 192.168.0.69 (192.168.0.69): icmp_seq=3 ttl=64 time=4.12 ms 64 bytes from 192.168.0.69 (192.168.0.69): icmp_seq=4 ttl=64 time=2.66 ms 64 bytes from 192.168.0.69 (192.168.0.69): icmp_seq=5 ttl=64 time=2.89 ms
--- ubuntu_server ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 8025ms rtt min/avg/max/mdev = 2.666/3.334/4.129/0.572 ms $ systemctl start firewalld $ LANG=C ping -c 5 ubuntu_server ping: ubuntu_server: Name or service not known
Test with nmblookup: $ systemctl stop firewalld $ nmblookup ubuntu_server 192.168.0.69 ubuntu_server<00> $ systemctl start firewalld $ nmblookup ubuntu_server name_query failed to find name ubuntu_server
I hope to have replied properly to all the questions :)
Thanks in advance
Il 31/08/2016 11:43, Thomas Woerner ha scritto:
Hello Giovanni,
...
More tests are needed now:
...
Regards, Thomas
Is there any progress? :)
Hello Giovanni,
On 09/15/2016 10:18 AM, Giovanni 'ItachiSan' Santini wrote:
Il 31/08/2016 11:43, Thomas Woerner ha scritto:
Hello Giovanni,
...
More tests are needed now:
...
Regards, Thomas
Is there any progress? :)
Not yet, but I think that I will have to time to test this in the end of the week.
I would need a bit more information on this like the system/distribution that is used on both ends. Are there additional firewall configuration settings on these machines?
Regards, Thomas
Il 21/09/2016 13:56, Thomas Woerner ha scritto:
Hello Giovanni,
On 09/15/2016 10:18 AM, Giovanni 'ItachiSan' Santini wrote:
Is there any progress? :)
Not yet, but I think that I will have to time to test this in the end of the week.
I would need a bit more information on this like the system/distribution that is used on both ends. Are there additional firewall configuration settings on these machines?
No problem :) My 'client' has ArchLinux as OS and use firewalld as firewall. The 'server' has Ubuntu 12.04 as OS and use ufw as firewall. The server is fully configured to allow Samba traffic, from all my OSes. In fact, I have also Windows 10 and Ubuntu 12.04 on 'client' side and they both work flawlessly with the server. Also, firewalld is configured to allow Samba traffic, as you can see:
$ firewall-cmd --list-services ntp dhcpv6-client ssh transmission samba steam
If you need more information, just ask :)
On 09/23/2016 03:14 PM, Giovanni 'ItachiSan' Santini wrote:
Il 21/09/2016 13:56, Thomas Woerner ha scritto:
Hello Giovanni,
On 09/15/2016 10:18 AM, Giovanni 'ItachiSan' Santini wrote:
Is there any progress? :)
Not yet, but I think that I will have to time to test this in the end of the week.
I would need a bit more information on this like the system/distribution that is used on both ends. Are there additional firewall configuration settings on these machines?
No problem :) My 'client' has ArchLinux as OS and use firewalld as firewall. The 'server' has Ubuntu 12.04 as OS and use ufw as firewall. The server is fully configured to allow Samba traffic, from all my OSes. In fact, I have also Windows 10 and Ubuntu 12.04 on 'client' side and they both work flawlessly with the server. Also, firewalld is configured to allow Samba traffic, as you can see:
Are you using IPv4 or IPv6?
As you are using samba on the client side, then samba-client should be enough.
Please enable LogDenied in the firewalld.conf file and add the system log entries that are related to samba and your server.
Please also add the output of these commands:
firewall-cmd --get-active-zones firewall-cmd --list-all route -n
If you additionally have direct rules, then also these.
$ firewall-cmd --list-services ntp dhcpv6-client ssh transmission samba steam
If you need more information, just ask :)
Hello there, sorry for such a late reply. It has been a long time since I could make these tests.
Il 27/09/2016 13:12, Thomas Woerner ha scritto:
Are you using IPv4 or IPv6?
As you are using samba on the client side, then samba-client should be enough.
In my local networking, IPv4 is used. I've enabled the *samba-client* rule on my computer.
Please enable LogDenied in the firewalld.conf file and add the system log entries that are related to samba and your server.
I've enabled the *LogDenied* option, with value *all*, but I had no useful output in the log file. I've some output in the system log, when giving $ ping netbios_server I got this: nov 26 18:53:39 antergos_E1-570G kernel: FINAL_REJECT: IN=wlp3s0 OUT= MAC=48:d2:24:66:ab:ec:00:11:32:3b:7b:60:08:00 SRC=192.168.0.50 DST=192.168.0.112 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=41467 LEN=70
Additionally, printing iptables (with *sudo iptables -L*): Chain IN_home_allow (1 references) target prot opt source destination ... ACCEPT udp -- anywhere anywhere udp spt:ssdp ctstate NEW ACCEPT udp -- anywhere anywhere udp dpt:netbios-ns ctstate NEW ...
I've noticed that I should consider 137 also as source port, as reply from the broadcast... At least, I think so.
Please also add the output of these commands:
firewall-cmd --get-active-zones
$ firewall-cmd --get-active-zones home interfaces: wlp3s0 sources: 192.168.0.1/24
firewall-cmd --list-all
$ firewall-cmd --list-all --zone=home home (active) target: default icmp-block-inversion: no interfaces: wlp3s0 sources: 192.168.0.1/24 services: transmission dhcpv6-client ntp steam mdns ssh ssdp samba-client ports: 4321/tcp 4321/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
route -n
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 600 0 0 wlp3s0 192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
If you additionally have direct rules, then also these.
No, no active rules for me.
Il 27/09/2016 13:12, Thomas Woerner ha scritto:
...
If you additionally have direct rules, then also these.
So, found a workaround for this. After ages, my computer is fully perfectly working. So I made some debugging, trying to ping a NetBIOS reachable machine. This was the output from journalctl when having enabled firewalld:
... dic 07 19:06:17 antergos_E1-570G kernel: FINAL_REJECT: IN=wlp3s0 OUT= MAC=48:d2:24:66:ab:ec:00:11:32:3b:7b:60:08:00 SRC=192.168.0.50 DST=192.168.0.103 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=48412 LEN=70 ...
As you can see, the port UDP 137 (used for NetBIOS resolution) is read as source port and not as destination one! So I just added the port 137/udp to the source ports of the samba-client service and it fixed all my problems.
Should I fix it upstream? I can make a patch easily.
Waiting feedback!
Hello,
On 12/07/2016 07:20 PM, Giovanni Santini wrote:
Il 27/09/2016 13:12, Thomas Woerner ha scritto:
...
If you additionally have direct rules, then also these.
So, found a workaround for this. After ages, my computer is fully perfectly working. So I made some debugging, trying to ping a NetBIOS reachable machine. This was the output from journalctl when having enabled firewalld:
... dic 07 19:06:17 antergos_E1-570G kernel: FINAL_REJECT: IN=wlp3s0 OUT= MAC=48:d2:24:66:ab:ec:00:11:32:3b:7b:60:08:00 SRC=192.168.0.50 DST=192.168.0.103 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=48412 LEN=70 ...
As you can see, the port UDP 137 (used for NetBIOS resolution) is read as source port and not as destination one! So I just added the port 137/udp to the source ports of the samba-client service and it fixed all my problems.
to allow the source port is a solution, but this is allowing all connections using this port as a source.
Should I fix it upstream? I can make a patch easily.
Waiting feedback!
There is a new firewalld version in testing for F-23 and in stable for F-24+: firewalld-0.4.4.2.
Please give this a try. It is providing a fix for selinux-policy to enable firewalld to use the connection tracking modules provided by the kernel.
Please report back on this.
Regards, Thomas
Il 08/12/2016 15:30, Thomas Woerner ha scritto:
There is a new firewalld version in testing for F-23 and in stable for F-24+: firewalld-0.4.4.2.
Please give this a try. It is providing a fix for selinux-policy to enable firewalld to use the connection tracking modules provided by the kernel.
Please report back on this.
Hello Thomas, I've deleted hand-made tweaks made to the various samba services and updated the package. Samba now works flawlessly. Thanks a lot for your support!
Hello Giovanni,
On 12/11/2016 10:33 PM, Giovanni Santini wrote:
Il 08/12/2016 15:30, Thomas Woerner ha scritto:
There is a new firewalld version in testing for F-23 and in stable for F-24+: firewalld-0.4.4.2.
Please give this a try. It is providing a fix for selinux-policy to enable firewalld to use the connection tracking modules provided by the kernel.
Please report back on this.
Hello Thomas, I've deleted hand-made tweaks made to the various samba services and updated the package. Samba now works flawlessly. Thanks a lot for your support!
you are welcome.
Regards, Thomas
firewalld-users@lists.fedorahosted.org
-
Giovanni Santini -
Thomas Woerner