[Bug 1109302] New: firewalld blocks iscsi firmware interfaces

newer
[Bug 1110708] New: gdb does not...

older
[Bug 1109738] usbutils: outdated...

bugzilla_noreply＠novell.com

21 Sep 2018 21 Sep '18

12:50

http://bugzilla.suse.com/show_bug.cgi?id=1109302 Bug ID: 1109302 Summary: firewalld blocks iscsi firmware interfaces Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team@suse.de Reporter: thomas.blume@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I have an systemd root on iscsi setup where the iscsi information is provided via firmware. The network interfaces are named accordingly, e.g. ibftX. When firewalld starts it blocks the connection on the ibft interfaces. Since they provide system root, the whole machine starts to hang. In my opinion firewalld should not filter access to ibft interfaces in any way as they are configured via firmware and not via system configuration. At least it should automatically unblock the iscsi port access on these interfaces as they are usually provide system root. -- You are receiving this mail because: You are on the CC list for the bug.

Attachments:

attachment.htm (text/html — 2.6 KB)

Show replies by date

bugzilla_noreply＠novell.com

21 Sep 21 Sep

13:03

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c1 Matthias Gerstner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matthias.gerstner@suse.com, | |security-team@suse.de Assignee|security-team@suse.de |markos.chandras@suse.com --- Comment #1 from Matthias Gerstner --- Markos, can you do something here? Would it be possible not to "whitelist" these interfaces based on the their names but based on their types? Maybe another approach could be to add suitable firewalld rules once such an iscsi setup is created in the first place? This could be done in YaST or wherever that happens. How this this work before with SuSEfirewall2? The default rules of firewalld are not that much different to what SuSEfirewall2 did so I wonder where the problem lies. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

24 Sep 24 Sep

08:54

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c2 --- Comment #2 from Markos Chandras --- (In reply to Thomas Blume from comment #0)

...

I have an systemd root on iscsi setup where the iscsi information is provided via firmware. The network interfaces are named accordingly, e.g. ibftX. When firewalld starts it blocks the connection on the ibft interfaces. Since they provide system root, the whole machine starts to hang. In my opinion firewalld should not filter access to ibft interfaces in any way as they are configured via firmware and not via system configuration. At least it should automatically unblock the iscsi port access on these interfaces as they are usually provide system root.

This is the second time you report a problem with iscsi and firewalld :) https://bugzilla.suse.com/show_bug.cgi?id=1094979 So how did you solve it the other day? Well the interface name could be anything right? I am not sure if hardcoding stuff would make sense. But I don't understand the problem. If you create suitable rules in firewalld, then on the next boot, when the service starts it should work fine no? You can also use the firewall-offline-cmd tool to program the firewall without running the service. So when you start it, the rules are there. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

10:01

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c3 --- Comment #3 from Thomas Blume --- (In reply to Markos Chandras from comment #2)

...

This is the second time you report a problem with iscsi and firewalld :)

https://bugzilla.suse.com/show_bug.cgi?id=1094979

So how did you solve it the other day?

Oops, I completely forgot about that. :( The solution then, was just to restore the shipped configuration of firewalld. But in this setup it is a bit different. The system root is on iscsi only, consequently the system gets stuck when the iscsi connection fails. And I didn't do any change to the shipped configuration. It will just hang at reboot after a fresh installation.

...

Well the interface name could be anything right? I am not sure if hardcoding stuff would make sense.

AFAIK, firmware provided interfaces should always be named ibft, not sure if there is an exception from this rule.

...

But I don't understand the problem. If you create suitable rules in firewalld, then on the next boot, when the service starts it should work fine no? You can also use the firewall-offline-cmd tool to program the firewall without running the service. So when you start it, the rules are there.

Actually, I'm even unsure how to configure the rule. I only see a rule to configure the iscsi target. Tried this: --> public target: default icmp-block-inversion: no interfaces: sources: services: ssh dhcpv6-client iscsi-target ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: --< but it didn't help. The iscsi client side has no fixed port (see the attached ss -6 output from my iscsi client). How to configure that? -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

10:02

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c4 --- Comment #4 from Thomas Blume --- Created attachment 783977 --> http://bugzilla.suse.com/attachment.cgi?id=783977&action=edit iscsi-connection.txt iscsi connection from my testmachine with root on iscsi -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

10:17

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c5 --- Comment #5 from Markos Chandras --- (In reply to Thomas Blume from comment #3)

...

Actually, I'm even unsure how to configure the rule. I only see a rule to configure the iscsi target. Tried this:

--> public target: default icmp-block-inversion: no interfaces: sources: services: ssh dhcpv6-client iscsi-target ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: --<

but this rule misses the interface name so I am not sure if it's active at all did you try 'firewall-cmd --zone=public --permanent --change-interface=ibft0' or something like this? Because this is a permanent change, it needs a reload (or system reboot) you can check the active zone with 'firewall-cmd --get-active'. But iscsi-target normally refers to the server. It has little value when you add this service to the client. What's the zone of the ibftX interface? I am not sure about how iscsi works, but firewalld allows established and related connections. So I am guessing, that your host first talks to the remote server (so this connection is NEW) and when the server replies back (state changed to ESTABLISHED) and firewalld should allow further communication. It's similar to every other outbound connection no? -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

1 Oct 1 Oct

12:22

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c6 --- Comment #6 from Thomas Blume --- Meanwhile I got the issue back on a machine similar to the one reported in bug#1094979. The boot process just stalls shortly after firewalld starts, even though this system has a softraid spanning a local disk and iscsi. I didn't change the firewalld setup on this machine but I made a package update. The system stops with the know error: [ 69.339822] connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4294907086, last ping 4294908353, now 4294909632 [ 69.339834] connection1:0: detected conn error (1022) [ 69.339836] connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4294907086, last ping 4294908344, now 4294909632 [ 69.339838] connection2:0: detected conn error (1022) That causes multipath failures and some scsi errors: --> [ 104.553438] sd 6:0:0:0: timing out command, waited 30s [ 104.553441] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK [ 104.553443] sd 6:0:0:0: [sdb] tag#0 CDB: Test Unit Ready 00 00 00 00 00 00 [ 104.561429] sd 7:0:0:0: timing out command, waited 30s [ 104.561430] sd 7:0:0:0: [sdd] tag#1 FAILED Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK [ 104.561432] sd 7:0:0:0: [sdd] tag#1 CDB: Test Unit Ready 00 00 00 00 00 00 [ 105.570312] device-mapper: multipath: Failing path 8:16. [ 105.570373] device-mapper: multipath: Failing path 8:32. [ 105.570419] device-mapper: multipath: Failing path 8:48. [ 105.570464] device-mapper: multipath: Failing path 8:64. [ 134.565149] sd 6:0:0:0: timing out command, waited 30s [ 134.565152] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK [ 134.565154] sd 6:0:0:0: [sdb] tag#0 CDB: Test Unit Ready 00 00 00 00 00 00 [ 134.573116] sd 7:0:0:0: timing out command, waited 30s [ 134.573119] sd 7:0:0:0: [sdd] tag#1 FAILED Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK [ 134.573120] sd 7:0:0:0: [sdd] tag#1 CDB: Test Unit Ready 00 00 00 00 00 00 --> I'm not sure whether the scsi subsystem behaves correctly here, but that's out of scope for this bug. (In reply to Markos Chandras from comment #5)

...

did you try 'firewall-cmd --zone=public --permanent --change-interface=ibft0' or something like this? Because this is a permanent change, it needs a reload (or system reboot) you can check the active zone with 'firewall-cmd --get-active'.

I did that and it shows: kvm133:~ # firewall-cmd --get-active public interfaces: ibft0 ibft1 Still the machine hangs at reboot.

...

But iscsi-target normally refers to the server. It has little value when you add this service to the client.

...

What's the zone of the ibftX interface?

It's public.

...

I am not sure about how iscsi works, but firewalld allows established and related connections. So I am guessing, that your host first talks to the remote server (so this connection is NEW) and when the server replies back (state changed to ESTABLISHED) and firewalld should allow further communication. It's similar to every other outbound connection no?

Even with the above setup, the boot hangs after firewalld starts. When I suppress the firewalld start and start it manually after the machine is up, there is no issue and the iscsi connection works just fine. I'm wondering whether there is a context with wicked which starts just before firewalld. At this point, the iscsi connection via firmware is already active. Maybe wicked triggers a reconnect that firewalld blocks? -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

14:02

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c7 --- Comment #7 from Markos Chandras --- Could you post the iptables and nftables rules from that system? Also what is the default zone (firewall-cmd --get-default-zone). Wicked does not seem to do anything disrupting. If ibft0/1 managed by a wicked ifcfg file? If yes, what's the ZONE attribute in it? -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

2 Oct 2 Oct

09:52

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c8 --- Comment #8 from Thomas Blume --- (In reply to Markos Chandras from comment #7)

...

Could you post the iptables and nftables rules from that system? Also what is the default zone (firewall-cmd --get-default-zone). Wicked does not seem to do anything disrupting. If ibft0/1 managed by a wicked ifcfg file? If yes, what's the ZONE attribute in it?

Here you go: --> kvm133:~ # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 INPUT_direct all -- 0.0.0.0/0 0.0.0.0/0 INPUT_ZONES_SOURCE all -- 0.0.0.0/0 0.0.0.0/0 INPUT_ZONES all -- 0.0.0.0/0 0.0.0.0/0 DROP all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 FORWARD_direct all -- 0.0.0.0/0 0.0.0.0/0 FORWARD_IN_ZONES_SOURCE all -- 0.0.0.0/0 0.0.0.0/0 FORWARD_IN_ZONES all -- 0.0.0.0/0 0.0.0.0/0 FORWARD_OUT_ZONES_SOURCE all -- 0.0.0.0/0 0.0.0.0/0 FORWARD_OUT_ZONES all -- 0.0.0.0/0 0.0.0.0/0 DROP all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination OUTPUT_direct all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD_IN_ZONES (1 references) target prot opt source destination FWDI_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] FWDI_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] FWDI_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] Chain FORWARD_IN_ZONES_SOURCE (1 references) target prot opt source destination Chain FORWARD_OUT_ZONES (1 references) target prot opt source destination FWDO_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] FWDO_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] FWDO_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] Chain FORWARD_OUT_ZONES_SOURCE (1 references) target prot opt source destination Chain FORWARD_direct (1 references) target prot opt source destination Chain FWDI_public (3 references) target prot opt source destination FWDI_public_log all -- 0.0.0.0/0 0.0.0.0/0 FWDI_public_deny all -- 0.0.0.0/0 0.0.0.0/0 FWDI_public_allow all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 Chain FWDI_public_allow (1 references) target prot opt source destination Chain FWDI_public_deny (1 references) target prot opt source destination Chain FWDI_public_log (1 references) target prot opt source destination Chain FWDO_public (3 references) target prot opt source destination FWDO_public_log all -- 0.0.0.0/0 0.0.0.0/0 FWDO_public_deny all -- 0.0.0.0/0 0.0.0.0/0 FWDO_public_allow all -- 0.0.0.0/0 0.0.0.0/0 Chain FWDO_public_allow (1 references) target prot opt source destination Chain FWDO_public_deny (1 references) target prot opt source destination Chain FWDO_public_log (1 references) target prot opt source destination Chain INPUT_ZONES (1 references) target prot opt source destination IN_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] IN_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] IN_public all -- 0.0.0.0/0 0.0.0.0/0 [goto] Chain INPUT_ZONES_SOURCE (1 references) target prot opt source destination Chain INPUT_direct (1 references) target prot opt source destination Chain IN_public (3 references) target prot opt source destination IN_public_log all -- 0.0.0.0/0 0.0.0.0/0 IN_public_deny all -- 0.0.0.0/0 0.0.0.0/0 IN_public_allow all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 Chain IN_public_allow (1 references) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3260 ctstate NEW ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:3260 ctstate NEW Chain IN_public_deny (1 references) target prot opt source destination Chain IN_public_log (1 references) target prot opt source destination Chain OUTPUT_direct (1 references) target prot opt source destination --< --> kvm133:~ # nft list ruleset kvm133:~ # --< --> kvm133:~ # firewall-cmd --get-default-zone public --< My network devices are: --> kvm133:~ # ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:97:81:9e brd ff:ff:ff:ff:ff:ff inet 192.168.57.133/24 brd 192.168.57.255 scope global ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe97:819e/64 scope link valid_lft forever preferred_lft forever 3: ibft0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:be:37:42 brd ff:ff:ff:ff:ff:ff inet6 2620:113:80c0:8080:10:160:68:246/64 scope global dynamic valid_lft 10363sec preferred_lft 10363sec inet6 2620:113:80c0:8080:35a3:8667:afe0:652e/64 scope global temporary dynamic valid_lft 3234sec preferred_lft 1434sec inet6 2620:113:80c0:8080:5054:ff:febe:3742/64 scope global dynamic mngtmpaddr valid_lft 3234sec preferred_lft 1434sec inet6 fe80::5054:ff:febe:3742/64 scope link valid_lft forever preferred_lft forever 4: ibft1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:dd:ca:2c brd ff:ff:ff:ff:ff:ff inet6 2620:113:80c0:8000:c::7ea/64 scope global dynamic valid_lft 13963sec preferred_lft 8563sec inet6 fe80::5054:ff:fedd:ca2c/64 scope link valid_lft forever preferred_lft forever --< There are no config files for the ibft devices: --> kvm133:~ # ls -l /etc/sysconfig/network/ insgesamt 60 drwxr-xr-x 1 root root 60 18. Sep 14:47 bck -rw-r--r-- 1 root root 9692 17. Sep 17:29 config -rw-r--r-- 1 root root 13381 17. Sep 17:29 dhcp -rw-r--r-- 1 root root 179 19. Sep 14:55 ifcfg-ens3 -rw------- 1 root root 147 17. Sep 17:29 ifcfg-lo -rw-r--r-- 1 root root 21738 9. Jun 08:26 ifcfg.template drwxr-xr-x 1 root root 40 17. Sep 17:27 if-down.d drwxr-xr-x 1 root root 40 17. Sep 17:27 if-up.d drwx------ 1 root root 0 25. Mai 22:22 providers drwxr-xr-x 1 root root 164 17. Sep 17:27 scripts --< -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

10:50

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c9 --- Comment #9 from Markos Chandras --- I can't see anything obviously wrong there to be honest. ESTABLISHED/RELATED connection are allowed which means existing connections to iscsi target should be fine. When firewalld starts, it flushes all tables and chains before it builds its rules but it should not make any difference to you because you have no rules before firewalld starts anyway. Could you attach the iptables -L -v output as well so we can see interface information in the chains? -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

11:53

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c10 --- Comment #10 from Thomas Blume --- (In reply to Markos Chandras from comment #9)

...

I can't see anything obviously wrong there to be honest. ESTABLISHED/RELATED connection are allowed which means existing connections to iscsi target should be fine. When firewalld starts, it flushes all tables and chains before it builds its rules but it should not make any difference to you because you have no rules before firewalld starts anyway.

Could you attach the iptables -L -v output as well so we can see interface information in the chains?

--> kvm133:~ # iptables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 45 3276 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- lo any anywhere anywhere 222 46284 INPUT_direct all -- any any anywhere anywhere 222 46284 INPUT_ZONES_SOURCE all -- any any anywhere anywhere 222 46284 INPUT_ZONES all -- any any anywhere anywhere 0 0 DROP all -- any any anywhere anywhere ctstate INVALID 221 46144 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- lo any anywhere anywhere 0 0 FORWARD_direct all -- any any anywhere anywhere 0 0 FORWARD_IN_ZONES_SOURCE all -- any any anywhere anywhere 0 0 FORWARD_IN_ZONES all -- any any anywhere anywhere 0 0 FORWARD_OUT_ZONES_SOURCE all -- any any anywhere anywhere 0 0 FORWARD_OUT_ZONES all -- any any anywhere anywhere 0 0 DROP all -- any any anywhere anywhere ctstate INVALID 0 0 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 38 packets, 4712 bytes) pkts bytes target prot opt in out source destination 45 5756 OUTPUT_direct all -- any any anywhere anywhere Chain FORWARD_IN_ZONES (1 references) pkts bytes target prot opt in out source destination 0 0 FWDI_public all -- ibft1 any anywhere anywhere [goto] 0 0 FWDI_public all -- ibft0 any anywhere anywhere [goto] 0 0 FWDI_public all -- + any anywhere anywhere [goto] Chain FORWARD_IN_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination Chain FORWARD_OUT_ZONES (1 references) pkts bytes target prot opt in out source destination 0 0 FWDO_public all -- any ibft1 anywhere anywhere [goto] 0 0 FWDO_public all -- any ibft0 anywhere anywhere [goto] 0 0 FWDO_public all -- any + anywhere anywhere [goto] Chain FORWARD_OUT_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination Chain FORWARD_direct (1 references) pkts bytes target prot opt in out source destination Chain FWDI_public (3 references) pkts bytes target prot opt in out source destination 0 0 FWDI_public_log all -- any any anywhere anywhere 0 0 FWDI_public_deny all -- any any anywhere anywhere 0 0 FWDI_public_allow all -- any any anywhere anywhere 0 0 ACCEPT icmp -- any any anywhere anywhere Chain FWDI_public_allow (1 references) pkts bytes target prot opt in out source destination Chain FWDI_public_deny (1 references) pkts bytes target prot opt in out source destination Chain FWDI_public_log (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public (3 references) pkts bytes target prot opt in out source destination 0 0 FWDO_public_log all -- any any anywhere anywhere 0 0 FWDO_public_deny all -- any any anywhere anywhere 0 0 FWDO_public_allow all -- any any anywhere anywhere Chain FWDO_public_allow (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public_deny (1 references) pkts bytes target prot opt in out source destination Chain FWDO_public_log (1 references) pkts bytes target prot opt in out source destination Chain INPUT_ZONES (1 references) pkts bytes target prot opt in out source destination 23 10520 IN_public all -- ibft1 any anywhere anywhere [goto] 109 14714 IN_public all -- ibft0 any anywhere anywhere [goto] 1 140 IN_public all -- + any anywhere anywhere [goto] Chain INPUT_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination Chain INPUT_direct (1 references) pkts bytes target prot opt in out source destination Chain IN_public (3 references) pkts bytes target prot opt in out source destination 133 25374 IN_public_log all -- any any anywhere anywhere 133 25374 IN_public_deny all -- any any anywhere anywhere 133 25374 IN_public_allow all -- any any anywhere anywhere 0 0 ACCEPT icmp -- any any anywhere anywhere Chain IN_public_allow (1 references) pkts bytes target prot opt in out source destination 1 140 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh ctstate NEW 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:iscsi-target ctstate NEW 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:iscsi-target ctstate NEW Chain IN_public_deny (1 references) pkts bytes target prot opt in out source destination Chain IN_public_log (1 references) pkts bytes target prot opt in out source destination Chain OUTPUT_direct (1 references) pkts bytes target prot opt in out source destination --< This time, I could also see a short interruption in the iscsi connection on one path when starting firewalld in the running system: --> [ 575.851408] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 586.086100] connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295036200, last ping 4295037456, now 4295038720 [ 586.086168] connection1:0: detected conn error (1022) [...] [ 591.206104] session1: session recovery timed out after 5 secs [ 591.206507] sd 2:0:0:0: rejecting I/O to offline device [ 591.206888] sd 2:0:0:0: [sda] killing request [ 591.207251] sd 2:0:0:0: rejecting I/O to offline device [ 591.207598] sd 2:0:0:0: [sda] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 591.207946] sd 2:0:0:0: [sda] CDB: Read(10) 28 00 00 4a 4c d8 00 00 18 00 [ 591.208298] print_req_error: I/O error, dev sda, sector 4869336 [ 591.208663] device-mapper: multipath: Failing path 8:0. [...] [ 596.671644] device-mapper: multipath: Reinstating path 8:0. --< But that only causes a short term i/o blockage. Afterwards the machine continues to run smoothly. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

13:17

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c11 --- Comment #11 from Markos Chandras --- I just noticed that you are using ipv6 to connect to iscsi target and the iptables rules we are looking at are just for ipv4. Any chance you paste the ip6tables -L -v output? Could the IPv6_rpfilter=yes option in firewalld.conf possibly affect your system? I also see the following warning bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. maybe worth checking that your initrd loads this module? -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

14:14

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c12 --- Comment #12 from Thomas Blume --- (In reply to Markos Chandras from comment #11)

...

I just noticed that you are using ipv6 to connect to iscsi target and the iptables rules we are looking at are just for ipv4. Any chance you paste the ip6tables -L -v output?

I haven't configured any ipv6 rules: --> kvm133:~ # ip6tables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination --<

...

Could the IPv6_rpfilter=yes option in firewalld.conf possibly affect your system?

I also see the following warning

bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.

maybe worth checking that your initrd loads this module?

Ah, looks like you are on the right track. I've enabled LogDenied logging and found this when starting firewalld: --> Okt 02 16:05:30 kvm133 kernel: rpfilter_DROP: IN=ibft0 OUT= MAC=52:54:00:be:37:42:00:08:02:ed:8f:15:86:dd SRC=2620:0113:80c0:8000:0010:0161:0063:0045 DST=2620:0113:80c0:8080:0010:0160:0068:0246 LEN=120 TC=0 HOPLIMIT=64 FLOWLBL=222566 PROTO=TCP SPT=3260 DPT=57784 WINDOW=5183 RES=0x00 ACK PSH URGP=0 Okt 02 16:05:30 kvm133 kernel: rpfilter_DROP: IN=ibft0 OUT= MAC=52:54:00:be:37:42:00:08:02:ed:8f:15:86:dd SRC=2620:0113:80c0:8000:0010:0161:0063:0045 DST=2620:0113:80c0:8080:0010:0160:0068:0246 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=222566 PROTO=TCP SPT=3260 DPT=57784 WINDOW=5183 RES=0x00 ACK URGP=0 Okt 02 16:05:31 kvm133 kernel: rpfilter_DROP: IN=ibft0 OUT= MAC=52:54:00:be:37:42:00:08:02:ed:8f:15:86:dd SRC=2620:0113:80c0:8000:0010:0161:0063:0045 DST=2620:0113:80c0:8080:0010:0160:0068:0246 LEN=120 TC=0 HOPLIMIT=64 FLOWLBL=150315 PROTO=TCP SPT=3260 DPT=57784 WINDOW=5183 RES=0x00 ACK PSH URGP=0 Okt 02 16:05:31 kvm133 kernel: rpfilter_DROP: IN=ibft0 OUT= MAC=52:54:00:be:37:42:00:08:02:ed:8f:15:86:dd SRC=2620:0113:80c0:8000:0010:0161:0063:0045 DST=2620:0113:80c0:8080:0010:0160:0068:0246 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=150315 PROTO=TCP SPT=3260 DPT=57784 WINDOW=5183 RES=0x00 ACK URGP=0 Okt 02 16:05:31 kvm133 kernel: FINAL_REJECT: IN=ibft1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:42:8a:0e:05:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 Okt 02 16:05:32 kvm133 kernel: rpfilter_DROP: IN=ibft0 OUT= MAC=52:54:00:be:37:42:00:08:02:ed:8f:15:86:dd SRC=2620:0113:80c0:8000:0010:0161:0063:0045 DST=2620:0113:80c0:8080:0010:0160:0068:0246 LEN=120 TC=0 HOPLIMIT=64 FLOWLBL=1017940 PROTO=TCP SPT=3260 DPT=57784 WINDOW=5183 RES=0x00 ACK PSH URGP=0 Okt 02 16:05:33 kvm133 kernel: FINAL_REJECT: IN=ibft1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:42:8a:0e:05:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=16 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 Okt 02 16:05:33 kvm133 kernel: rpfilter_DROP: IN=ibft0 OUT= MAC=52:54:00:be:37:42:00:08:02:ed:8f:15:86:dd SRC=2620:0113:80c0:8000:0010:0161:0063:0045 DST=2620:0113:80c0:8080:0010:0160:0068:0246 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=1017940 PROTO=TCP SPT=3260 DPT=57784 WINDOW=5183 RES=0x00 ACK URGP=0 Okt 02 16:05:35 kvm133 kernel: FINAL_REJECT: IN=ibft1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0f:b7:11:14:77:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=556 Okt 02 16:05:36 kvm133 kernel: FINAL_REJECT: IN=ibft1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0f:b7:11:18:64:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=556 --< So, it is obviously rpfilter that drops it. But if I change the rpfilter setting: --> kvm133:~ # grep IPv6_rpfilter /etc/firewalld/firewalld.conf # IPv6_rpfilter IPv6_rpfilter=no --< I get a nasty error messages are firewalld start: --> Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore: line 2 failed Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore: line 2 failed Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: Failed to apply rules. A firewall reload might solve the issue if the firewall has been modified using ip*tables or ebtables. Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: '/usr/sbin/ebtables -t broute -N BROUTING_direct -P RETURN' failed: Chain BROUTING_direct already exists. Okt 02 16:11:16 kvm133 audit: NETFILTER_CFG table=filter family=7 entries=2 Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: Failed to apply rules. A firewall reload might solve the issue if the firewall has been modified using ip*tables or ebtables. Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: '/usr/sbin/ebtables -t filter -X FORWARD_direct -P RETURN' failed: No extra options allowed with -X. Okt 02 16:11:16 kvm133 firewalld[3923]: ERROR: COMMAND_FAILED: '/usr/sbin/ip6tables-restore -w -n' failed: ip6tables-restore: line 2 failed --< and the session from where I've started firewalld freezes. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

14:26

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c13 Markos Chandras changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS --- Comment #13 from Markos Chandras --- OK there are a couple of backports that are not in the 0.6.X branch which may improve the situation. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

14:28

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c14 --- Comment #14 from Markos Chandras --- Actually, what firewalld version are you using? in 0.6.2 there should be no BROUTING table anymore and the other ebtables failure you are seeing should also be fixed in that version. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

15:08

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c15 --- Comment #15 from Thomas Blume --- (In reply to Markos Chandras from comment #14)

...

Actually, what firewalld version are you using? in 0.6.2 there should be no BROUTING table anymore and the other ebtables failure you are seeing should also be fixed in that version.

I've just used the one shipped with tumbleweed: https://download.opensuse.org/tumbleweed/repo/oss/noarch/firewalld-0.6.1-4.1... I saw version 0.6.2 in obs. Will give it a try. -- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

4 Oct 4 Oct

07:11

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c16 --- Comment #16 from Thomas Blume --- (In reply to Thomas Blume from comment #15)

...

(In reply to Markos Chandras from comment #14)

...
Actually, what firewalld version are you using? in 0.6.2 there should be no BROUTING table anymore and the other ebtables failure you are seeing should also be fixed in that version.

I've just used the one shipped with tumbleweed:

https://download.opensuse.org/tumbleweed/repo/oss/noarch/firewalld-0.6.1-4.1. noarch.rpm

I saw version 0.6.2 in obs. Will give it a try.

Unfortunately still the same behaviour with firewalld-0.6.2-1.1. But now I get an output with ip6tables: -->

...

kvm133:~ # ip6tables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 35 2760 ACCEPT all any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all lo any anywhere anywhere 0 0 INPUT_direct all any any anywhere anywhere 0 0 INPUT_ZONES_SOURCE all any any anywhere anywhere 0 0 INPUT_ZONES all any any anywhere anywhere 0 0 LOG all any any anywhere anywhere ctstate INVALID LOG level warning prefix "STATE_INVALID_DROP: " 0 0 DROP all any any anywhere anywhere ctstate INVALID 0 0 LOG all any any anywhere anywhere LOG level warning prefix "FINAL_REJECT: " 0 0 REJECT all any any anywhere anywhere reject-with icmp6-adm-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all lo any anywhere anywhere 0 0 FORWARD_direct all any any anywhere anywhere 0 0 FORWARD_IN_ZONES_SOURCE all any any anywhere anywhere 0 0 FORWARD_IN_ZONES all any any anywhere anywhere 0 0 FORWARD_OUT_ZONES_SOURCE all any any anywhere anywhere 0 0 FORWARD_OUT_ZONES all any any anywhere anywhere 0 0 LOG all any any anywhere anywhere ctstate INVALID LOG level warning prefix "STATE_INVALID_DROP: " 0 0 DROP all any any anywhere anywhere ctstate INVALID 0 0 LOG all any any anywhere anywhere LOG level warning prefix "FINAL_REJECT: " 0 0 REJECT all any any anywhere anywhere reject-with icmp6-adm-prohibited

Chain OUTPUT (policy ACCEPT 7 packets, 792 bytes) pkts bytes target prot opt in out source destination 45 77496 OUTPUT_direct all any any anywhere anywhere

Chain FORWARD_IN_ZONES (1 references) pkts bytes target prot opt in out source destination 0 0 FWDI_public all ibft1 any anywhere anywhere [goto] 0 0 FWDI_public all ibft0 any anywhere anywhere [goto] 0 0 FWDI_public all + any anywhere anywhere [goto]

Chain FORWARD_IN_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination

Chain FORWARD_OUT_ZONES (1 references) pkts bytes target prot opt in out source destination 0 0 FWDO_public all any ibft1 anywhere anywhere [goto] 0 0 FWDO_public all any ibft0 anywhere anywhere [goto] 0 0 FWDO_public all any + anywhere anywhere [goto]

Chain FORWARD_OUT_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination

Chain FORWARD_direct (1 references) pkts bytes target prot opt in out source destination

Chain FWDI_public (3 references) pkts bytes target prot opt in out source destination 0 0 FWDI_public_log all any any anywhere anywhere 0 0 FWDI_public_deny all any any anywhere anywhere 0 0 FWDI_public_allow all any any anywhere anywhere 0 0 ACCEPT ipv6-icmp any any anywhere anywhere

Chain FWDI_public_allow (1 references) pkts bytes target prot opt in out source destination

Chain FWDI_public_deny (1 references) pkts bytes target prot opt in out source destination

Chain FWDI_public_log (1 references) pkts bytes target prot opt in out source destination

Chain FWDO_public (3 references) pkts bytes target prot opt in out source destination 0 0 FWDO_public_log all any any anywhere anywhere 0 0 FWDO_public_deny all any any anywhere anywhere 0 0 FWDO_public_allow all any any anywhere anywhere

Chain FWDO_public_allow (1 references) pkts bytes target prot opt in out source destination

Chain FWDO_public_deny (1 references) pkts bytes target prot opt in out source destination

Chain FWDO_public_log (1 references) pkts bytes target prot opt in out source destination

Chain INPUT_ZONES (1 references) pkts bytes target prot opt in out source destination 0 0 IN_public all ibft1 any anywhere anywhere [goto] 0 0 IN_public all ibft0 any anywhere anywhere [goto] 0 0 IN_public all + any anywhere anywhere [goto]

Chain INPUT_ZONES_SOURCE (1 references) pkts bytes target prot opt in out source destination

Chain INPUT_direct (1 references) pkts bytes target prot opt in out source destination

Chain IN_public (3 references) pkts bytes target prot opt in out source destination 0 0 IN_public_log all any any anywhere anywhere 0 0 IN_public_deny all any any anywhere anywhere 0 0 IN_public_allow all any any anywhere anywhere 0 0 ACCEPT ipv6-icmp any any anywhere anywhere

Chain IN_public_allow (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp any any anywhere anywhere tcp dpt:ssh ctstate NEW,UNTRACKED 0 0 ACCEPT udp any any anywhere fe80::/64 udp dpt:dhcpv6-client ctstate NEW,UNTRACKED 0 0 ACCEPT tcp any any anywhere anywhere tcp dpt:iscsi-target ctstate NEW,UNTRACKED 0 0 ACCEPT udp any any anywhere anywhere udp dpt:iscsi-target ctstate NEW,UNTRACKED

Chain IN_public_deny (1 references) pkts bytes target prot opt in out source destination

Chain IN_public_log (1 references) pkts bytes target prot opt in out source destination

Chain OUTPUT_direct (1 references) pkts bytes target prot opt in out source destination --<

-- You are receiving this mail because: You are on the CC list for the bug.

bugzilla_noreply＠novell.com

08:25

New subject: [Bug 1109302] firewalld blocks iscsi firmware interfaces

http://bugzilla.suse.com/show_bug.cgi?id=1109302 http://bugzilla.suse.com/show_bug.cgi?id=1109302#c17 --- Comment #17 from Markos Chandras --- Not sure what to suggest from now on. Does the LogDenied option give any further clues with respect to ipv6_rpfilter? -- You are receiving this mail because: You are on the CC list for the bug.

2038

Age (days ago)

2051

Last active (days ago)

List overview

Download

17 comments

1 participants

participants (1)

bugzilla_noreply＠novell.com

[Bug 1109302] New: firewalld blocks iscsi firmware interfaces

tags

participants (1)