README for firewalld ==================== firewalld provides a dynamically managed firewall with support for network or firewall zones to define the trust level of network connections or interfaces. It has support for IPv4, IPv6 firewall settings and for ethernet bridges and a separation of runtime and permanent configuration options. It also provides an interface for services or applications to add ip*tables and ebtables rules directly. Development ----------- To check out the source repository, you can use: git clone https://github.com/firewalld/firewalld.git This will create a local copy of the repository. Language Translations --------------------- Firewalld uses GNU gettext for localization support. Translations can be done using Fedora's Weblate instance [1]. Translations are periodically merged into the main firewalld repository. [1] https://translate.stg.fedoraproject.org/projects/firewalld/ Dependencies ------------ These are the runtime dependencies: linux >= 5.3 python3-dbus python3-gobject python3-nftables >= 0.9.4 Note: python2 is _not_ supported. Optional Dependencies --------------------- These dependencies may enhance firewalld's functionality, but they are not required. ebtables ipset iptables polkit python3-capng (libcap-ng-python3) Working With The Source Repository ---------------------------------- In addition to the runtime dependencies some others are needed to build from source: desktop-file-utils: /usr/bin/desktop-file-install gettext intltool glib2: /usr/bin/glib-compile-schemas glib2-devel: /usr/share/aclocal/gsettings.m4 systemd-units To be able to create man pages and documentation from docbook files: docbook-style-xsl libxslt Use the usual autoconf/automake incantation to generate makefiles ./autogen.sh ./configure You can use a specific python interpreter by passing the PYTHON variable. This is also used by the testsuite. ./configure PYTHON=/path/to/python3 Use make to create the documentation and to update the po files. Use make check to run the testsuite. Tests are run inside network namespaces and do not interfere with the host's running firewalld. They can also be run in parallel by passing flags to autotest. make check TESTSUITEFLAGS="-j4" The testsuite also uses keywords to allow running a subset of tests that exercise a specific area. For example: make check TESTSUITEFLAGS="-k rich -j4" 24: rich rules audit ok 25: rich rules priority ok 26: rich rules bad ok 53: rich rules audit ok 23: rich rules good ok 55: rich rules bad ok 74: remove forward-port after reload ok You can get a list of tests and keywords make -C src/tests check TESTSUITEFLAGS="-l" Or just the keywords make -C src/tests check TESTSUITEFLAGS="-l" \ |awk '/^[[:space:]]*[[:digit:]]+/{getline; print $0}' \ |tr ' ' '\n' |sort |uniq There are integration tests. Currently this includes NetworkManager. These may be _destructive_ to the host. Run them in a disposable VM or container. make check-integration There is also a check-container target that will run the testsuite inside various podman/docker containers. This is useful for coverage of multiple distributions. It also runs tests that may be destructive to the host such as integration tests. make check-container TESTSUITEFLAGS="-j4" OCI Container Image ------------------- As part of the `dist` build target an OCI container image is generated. This is distributed alongside the normal release tarball. It can be used to run firewalld from a container. To manually load the container image into your environment: # podman load -i .../path/to/firewalld-oci-<ver>.tar To fetch the image from quay.io: # podman pull quay.io/firewalld/firewalld:<ver> where <ver> is optional. latest will be used if omitted. To start the daemon/container: # podman run -d -v /run/dbus/system_bus_socket:/run/dbus/system_bus_socket \ --network host --privileged \ --name my-firewalld firewalld The volume mount is needed to access the host's running system dbus. The source path of the socket may vary depending on distribution. Firewalld's configuration will live inside the container. Therefore users may want to occasionally `podman commit` the image. Using firewalld's CLI should be done via podman exec after the daemon/container has been started: # podman exec my-firewalld firewall-cmd ... RPM package ----------- For Fedora and RHEL based distributions, there is a spec file in the source repo named firewalld.spec. This should be usable for Fedora versions >= 16 and RHEL >= 7. Links ----- Homepage: http://firewalld.org Report a bug: https://github.com/firewalld/firewalld/issues Git repo browser: https://github.com/firewalld/firewalld Git repo: https://github.com/firewalld/firewalld.git Documentation: http://firewalld.org/documentation/ Mailing lists ------------- For usage: https://lists.fedorahosted.org/archives/list/[email protected]/ For development: https://lists.fedorahosted.org/archives/list/[email protected]/ Directory Structure ------------------- config/ Configuration files config/icmptypes/ Predefined ICMP types config/services/ Predefined services config/zones/ Predefined zones config/ipsets/ Predefined ipsets doc/ Documentation doc/man/ Base directory for man pages doc/man/man1/ Man(1) pages doc/man/man5/ Man(5) pages po/ Translations shell-completion/ Base directory for auto completion scripts src/ Source tree src/firewall/ Import tree for the sevice and all applications src/icons/ Icons in the sizes: 16, 22, 24, 32, 48 and scalable src/tests/ Testsuite
Firewall daemon with D-Bus interface
README for firewalld ==================== firewalld provides a dynamically managed firewall with support for network or firewall zones to define theCategory: Python / Networking |
Watchers: 38 |
Star: 517 |
Fork: 197 |
Last update: Jan 11, 2022 |
What happened:
systemctl start firewalld.service
journalctl -xe -u firewalld
Jul 09 13:28:02 omv-rockpro64 firewalld[135537]: ERROR: 'handle'
Jul 09 13:28:02 omv-rockpro64 firewalld[135537]: ERROR: COMMAND_FAILED: 'handle'
Jul 09 13:28:03 omv-rockpro64 firewalld[135537]: ERROR: 'handle'
Jul 09 13:28:03 omv-rockpro64 firewalld[135537]: ERROR: COMMAND_FAILED: 'handle'
What you expected to happen: No errors
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
[[email protected] tpg]# rpm -qf /usr/bin/firewall-cmd
firewalld-0.9.4-2.noarch
[[email protected] tpg]# rpm -qf /usr/lib64/libmnl.so.0
lib64mnl0-1.0.4-5.aarch64
[[email protected] tpg]# rpm -qf /usr/lib64/libnftnl.so.11
lib64nftnl11-1.2.0-2.aarch64
[[email protected] tpg]# rpm -qf /usr/lib64/libnftables.so.1
lib64nftables1-0.9.9-4.aarch64
[[email protected] tpg]# rpm -qf /usr/lib64/libjansson.so.4
lib64jansson4-2.13.1-7.aarch64
[[email protected] tpg]# uname -a
Linux omv-rockpro64 5.12.13-server-clang-1omv4050 #1 SMP Fri Jun 25 13:46:02 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
Environment:
- Firewalld Version (if Fedora based
dnf info firewalld
or commit hash if developing from gitgit log -n1 --format=format:"%H"
): 0.9.4 - Firewalld Backend (
cat /etc/firewalld/firewalld.conf | grep FirewallBackend
): nftables - OS (e.g:
cat /etc/os-release
): OpenMandriva LX cooker - Others:
Hello, I am having trouble since I've upgraded a CentOS 7.6 container to CentOS 7.7 running on ProxMox 6.0. The problem is that firewalld no more starts complaining about nf_conntrack module as follows. ERROR: Failed to load nf_conntrack module: modprobe: ERROR: could not find module by name='nf_conntrack' modprobe: ERROR: could not insert 'nf_conntrack': Function not implemented modprobe: ERROR: Error running install command for nf_conntrack... ERROR: Raising SystemExit in run_server
The output of modinfo nf_conntrack is modinfo: ERROR: Module alias nf_conntrack not found.
While on a VPS running at french provider OVH, i have as output: filename: /lib/modules/3.10.0-1062.1.1.el7.x86_64/kernel/net/netfilter/nf_conntrack.ko.xz license: GPL retpoline: Y rhelversion: 7.7 srcversion: 03A8408E58BFA6E173F2FE6 depends: libcrc32c intree: Y vermagic: 3.10.0-1062.1.1.el7.x86_64 SMP mod_unload modversions signer: CentOS Linux kernel signing key sig_key: 34:1A:1E:7B:06:D6:87:15:3E:3A:E9:8D:3E:B5:6E:0E:CD:30:DB:79 sig_hashalgo: sha256 parm: tstamp:Enable connection tracking flow timestamping. (bool) parm: acct:Enable connection tracking flow accounting. (bool) parm: nf_conntrack_helper:Enable automatic conntrack helper assignment (default 1) (bool) parm: expect_hashsize:uint
On the ProxMox server side, i have also a positive output: filename: /lib/modules/5.0.21-2-pve/kernel/net/netfilter/nf_conntrack.ko license: GPL alias: nf_conntrack-10 alias: nf_conntrack-2 alias: ip_conntrack srcversion: ECF2FC78962840323375B8C depends: nf_defrag_ipv6,libcrc32c,nf_defrag_ipv4 retpoline: Y intree: Y name: nf_conntrack vermagic: 5.0.21-2-pve SMP mod_unload modversions parm: tstamp:Enable connection tracking flow timestamping. (bool) parm: acct:Enable connection tracking flow accounting. (bool) parm: nf_conntrack_helper:Enable automatic conntrack helper assignment (default 0) (bool) parm: expect_hashsize:uint
The output of rpm -qf /lib/modules/3.10.0-1062.1.1.el7.x86_64/kernel/net/netfilter/nf_conntrack.ko.xz on the centos 7.7 vps is kernel-3.10.0-1062.1.1.el7.x86_64
Now, on a proxmox container, there is no kernel installed as it is a container. As this is an urgent case, I removed firewalld firewalld-filesystem and python-firewall all 0.6.3-2 and reinstalled from centos vault those of the 7.6 version of centos (0.5.3-5). And now the firewalld service starts.
Now, on the centos 7.7 container: lsmod | grep nf_ nf_reject_ipv4 16384 1 ipt_REJECT nf_reject_ipv6 20480 1 ip6t_REJECT nf_nat_ipv6 16384 2 ip6table_nat,ip6t_MASQUERADE nf_nat_ipv4 16384 2 ipt_MASQUERADE,iptable_nat nf_nat 36864 2 nf_nat_ipv6,nf_nat_ipv4 nf_conntrack 139264 6 xt_conntrack,nf_nat,ip6t_MASQUERADE,nf_nat_ipv6,ipt_MASQUERADE,nf_nat_ipv4 nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack libcrc32c 16384 4 nf_conntrack,nf_nat,dm_persistent_data,btrfs
and on the proxmox hypervisor: lsmod | grep nf_ nf_reject_ipv4 16384 1 ipt_REJECT nf_reject_ipv6 20480 1 ip6t_REJECT nf_nat_ipv6 16384 2 ip6table_nat,ip6t_MASQUERADE nf_nat_ipv4 16384 2 ipt_MASQUERADE,iptable_nat nf_nat 36864 2 nf_nat_ipv6,nf_nat_ipv4 nf_conntrack 139264 6 xt_conntrack,nf_nat,ip6t_MASQUERADE,nf_nat_ipv6,ipt_MASQUERADE,nf_nat_ipv4 nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack libcrc32c 16384 4 nf_conntrack,nf_nat,dm_persistent_data,btrfs
So nf_conntrack seems to be loaded on both the hypervisor and the container and beeing useable by firewalld 0.5.3 but not by firewalld 0.6.3.
Could someone help me solve this issue please ? TIA Fathi Ben Nasr
I'm not sure if this is a bug in firewalld. The default firewalld.service
file which gets used in the Debian/Ubuntu package end up with this dependency loops involving firewalld.service
. (I have my theories, but I'm not sure why that is the case)
On stopping:
Oct 26 09:43:51 hostname systemd[1]: firewalld.service: Found ordering cycle on sysinit.target/stop
Oct 26 09:43:51 hostname systemd[1]: firewalld.service: Found dependency on cloud-init.service/stop
Oct 26 09:43:51 hostname systemd[1]: firewalld.service: Found dependency on networking.service/stop
Oct 26 09:43:51 hostname systemd[1]: firewalld.service: Found dependency on network-pre.target/stop
Oct 26 09:43:51 hostname systemd[1]: firewalld.service: Found dependency on firewalld.service/stop
Oct 26 09:43:51 hostname systemd[1]: firewalld.service: Job sysinit.target/stop deleted to break ordering cycle starting with firewalld.service/stop
On starting:
Oct 26 09:44:34 hostname kernel: [ 14.321552] systemd[1]: sysinit.target: Found ordering cycle on cloud-init.service/start
Oct 26 09:44:34 hostname kernel: [ 14.327144] systemd[1]: sysinit.target: Found dependency on networking.service/start
Oct 26 09:44:34 hostname kernel: [ 14.332163] systemd[1]: sysinit.target: Found dependency on network-pre.target/start
Oct 26 09:44:34 hostname kernel: [ 14.336991] systemd[1]: sysinit.target: Found dependency on firewalld.service/stop
Oct 26 09:44:34 hostname kernel: [ 14.341466] systemd[1]: sysinit.target: Found dependency on basic.target/start
Oct 26 09:44:34 hostname kernel: [ 14.345469] systemd[1]: sysinit.target: Found dependency on sockets.target/start
Fedora (and likely as a result RHEL and CentOS) have their own unit file, which does not exhibit this problem.
Replacing the unit file with this version (A mix of the default on and the Fedora one), seems to resolve the problem: (Mainly non-forking and keeping some of the dependencies)
[Unit]
Description=Firewall dynamic change handling daemon
After=syslog.target
After=dbus.service
After=polkit.service
Conflicts=iptables.service ip6tables.service ebtables.service ipset.service
Documentation=man:firewalld(1)
[Service]
EnvironmentFile=-/etc/sysconfig/firewalld
ExecStart=/usr/sbin/firewalld --nofork $FIREWALLD_ARGS
ExecReload=/bin/kill -HUP $MAINPID
# supress to log debug and error output also to /var/log/messages
StandardOutput=null
StandardError=null
Type=dbus
BusName=org.fedoraproject.FirewallD1
KillMode=mixed
[Install]
WantedBy=multi-user.target
Alias=dbus-org.fedoraproject.FirewallD.service
My guess of what might be a factor mainly involve these two lines: (I don't know systemd well enough to be certain)
Before=network-pre.target
Wants=network-pre.target
Another possibility is that some of the DefaultDependencies interact with the ones added...
I know that removing FirewallD solves the problem, as does dropping the Fedora-based unit file in /etc/systemd/system/firewalld.service
.
Hi,
I have to admit that I'm a bit of a iptables noob, but I believe I get the gist of it.
I run a router using firewalld and have a dial-up connection that needs to provide some services (HTTP, FTP, etc.). Some services are running on the router itself (HTTP), some need to be redirected to other machines (FTP). I have no problems with the services running on the router, but those running on other machines.
My router has 172.16.0.3 (internal zone) and a PPP connection + ethernet in the external zone.
$ firewall-cmd --info-zone internal
internal (active)
target: default
icmp-block-inversion: no
interfaces: ens192
sources:
services: ntp cockpit dhcpv6-client http mdns ssh https afp
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
$ firewall-cmd --permanent --info-zone external
external (active)
target: default
icmp-block-inversion: no
interfaces: ppp0 ens224
sources:
services: https ssh http
ports:
protocols:
masquerade: yes
forward-ports: port=10021:proto=tcp:toport=10021:toaddr=172.16.0.10
port=21:proto=tcp:toport=21:toaddr=172.16.0.10
source-ports:
icmp-blocks:
rich rules:
My first impression was that a some port forwarding should suffice to publish FTP to the outside world:
firewall-cmd --add-forward-port=port=21:proto=tcp:toport=21:toaddr=172.16.0.10 --zone=external
firewall-cmd --add-forward-port=port=10021:proto=tcp:toport=10021:toaddr=172.16.0.10 --zone=external
This makes the FTP service available to the outside world but I found that when I connect to any FTP server on the internet from a machine behind the router (e.g. not the router itself), I instead reach my own FTP server.
My second attempt has been to create a FTP service and add that to the external zone (removing the mapping beforehand). But now my FTP server is not reachable from the outside world:
cat /etc/firewalld/services/syno-ftp.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
<short>Synology FTP Server</short>
<description>Synology FTP Server on 172.16.0.10</description>
<port port="21" protocol="tcp"/>
<port port="10021" protocol="tcp"/>
<module name="ftp"/>
<destination ipv4="172.16.0.10"/>
</service>
$ firewall-cmd --zone=external --add-service=syno-ftp
success
$ iptables -L
...
Chain IN_external_allow (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:http ctstate NEW
ACCEPT tcp -- anywhere 172.16.0.10 tcp dpt:21 ctstate NEW
ACCEPT tcp -- anywhere 172.16.0.10 tcp dpt:10021 ctstate NEW
$ tcpdump -i ppp0 -n 'tcp port 21'
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:56:51.942657 IP 85.25.226.101.51740 > 91.41.223.49.ftp: Flags [S], seq 2162915807, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
...
My question is: What is the correct way to configure FTP to be available externally, but not "eat up" my outgoing FTP connections.
What happened: Version 1.0.0-1.1 of firewalld breaks inter-container networking, at least for Mastodon's docker-compose.yml.
Container mastodon_streaming_1
shows these errors repeatedly while trying to connect to the mastodon_redis_1
container:
WARN Starting worker 50
WARN Worker 50 now listening on 0.0.0.0:4000
ERR! Error: Redis connection to mastodon_redis_1:6379 failed - connect EHOSTUNREACH 172.24.0.3:6379
WARN Worker 50 exiting
What you expected to happen: Containers can still connect to each other.
How to reproduce it (as minimally and precisely as possible):
Update to firewalld 1.0.0-1.1
on openSUSE Tumbleweed. Previous version 0.9.3-3.3
works fine.
Anything else we need to know?: I didn't try to use the iptables backend, as the latest firewalld shows this new comment:
...
+# Note: The iptables backend is deprecated. It will be removed in a future
+# release.
FirewallBackend=nftables
...
Environment:
- Firewalld Version:
1.0.0-1.1
- Firewalld Backend:
FirewallBackend=nftables
- OS:
openSUSE Tumbleweed snapshot 20210818
- Others: This is on a ROCK64 SBC, aarch64 architecture.
I'd be glad to provide any additional information or logs.
I am running firewalld on Manjaro Linux with GNOME 3.18.3. System startup is really slow because firewalld is taking almost 20 seconds to start. Is there anything I can do to speed up firewalld?
systemd-analyze blame
19.929s firewalld.service
9.189s systemd-journald.service
4.505s dev-sda3.device
4.455s systemd-modules-load.service
4.076s ModemManager.service
2.821s [email protected]\x2duuid-fca3eb5c\x2d2981\x2d44c6\x2d8108\x2d9eef32e823a7.service
2.791s polkit.service
2.002s plymouth-quit-wait.service
1.922s avahi-daemon.service
1.784s systemd-vconsole-setup.service
1.679s thermald.service
1.486s systemd-journal-flush.service
1.149s systemd-logind.service
1.146s accounts-daemon.service
955ms systemd-sysctl.service
953ms gdm-plymouth.service
867ms systemd-tmpfiles-setup-dev.service
761ms bluetooth.service
701ms systemd-user-sessions.service
655ms systemd-binfmt.service
608ms sys-kernel-debug.mount
606ms dev-hugepages.mount
592ms [email protected]
487ms systemd-hostnamed.service
424ms home.mount
413ms systemd-udevd.service
387ms [email protected]
316ms tmp.mount
315ms systemd-remount-fs.service
313ms dev-mqueue.mount
266ms proc-sys-fs-binfmt_misc.mount
249ms udisks2.service
242ms systemd-rfkill.service
239ms packagekit.service
200ms colord.service
169ms NetworkManager.service
167ms systemd-timedated.service
164ms [email protected]:intel_backlight.service
149ms alsa-restore.service
134ms systemd-localed.service
131ms upower.service
128ms systemd-tmpfiles-setup.service
120ms sys-kernel-config.mount
107ms systemd-timesyncd.service
94ms systemd-udev-trigger.service
88ms systemd-random-seed.service
74ms wpa_supplicant.service
64ms [email protected]
49ms systemd-update-utmp.service
29ms rtkit-daemon.service
26ms plymouth-start.service
24ms geoclue.service
20ms kmod-static-nodes.service
13ms plymouth-read-write.service
3ms sys-fs-fuse-connections.mount
systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2015-11-15 15:35:35 CST; 2min 4s ago
Main PID: 606 (firewalld)
CGroup: /system.slice/firewalld.service
└─606 /usr/bin/python -Es /usr/bin/firewalld --nofork --nopid
Nov 15 15:35:35 ryan-linux-laptop systemd[1]: Started firewalld - dynamic firewall daemon.
Nov 15 15:37:07 ryan-linux-laptop /firewalld[606]: 2015-11-15 15:37:07 ERROR: UNKNOWN_INTERFACE: 'wlp10s0' is not in any zone
Under the firewalld.dbus(5) manual page, the interface org.fedoraproject.FirewallD1.ipset
has a method listed as getSettings()
but this is incorrect. The name of the method in the dbus interface is getIPSetSettings()
not getSettings()
. Trying to call getSettings()
results in unknown method errors.
This adds a new parameter to firewalld: --log-channel. It allows to configure firewalld to send log messages to only one output channel. I think this allows a much better integration with systemd journald and simplifies the usage in general.
Requiring logrotate on a systemd machine seems like a drawback to me.
Generating log messages and redirecting them to /dev/null looks more like a workaround than a great design.
The logrotate configuration file is still installed, but it is no longer needed if log files are not written. This could be improved by a follow-up commit.
~~Test case is more than likely incorrect, but I cannot figure out how to fix when using the other tests as references.~~
INVALID conntrack packets (TCP traffic with FIN, PSH and URG flags) are allowed, but not masqueraded
What happened:
Im seeing an issue with Firewalld v. 1.0.4 on Fedora 35 where outbound masquerade is applied via a policy, but malformed packets (with the FIN, PSH and URG flags set) are not being NATed. It appears that all other traffic is being properly NATed via the policy with masquerade enable. This is resulting in leaking of internal addresses to the outer network (out the WAN interface). The policy with masquerade enabled has the ingress zone set to ANY
and the egress zone set to external
. The external
zone has both the WAN interface assigned to it, and the WAN subnet definded as a source.
What you expected to happen:
I expect all traffic from that is sent from any zone to the external
zone to have masquerade NAT
applied to it.
How to reproduce it (as minimally and precisely as possible):
**From a host inside the network (on the LAN side, which will match the ANY
statement in the policy.) run nmap -v -sX <host outside the network>
Anything else we need to know?:
It appears that conntrack
might not be estabilishing a state for this traffic, but i need to do some additional testing in order to confirm that.
Environment: -Installed Packages Name : firewalld Version : 1.0.4 Release : 1.fc35 Architecture : noarch Size : 2.0 M Source : firewalld-1.0.4-1.fc35.src.rpm
-FirewallBackend=nftables
-Fedora Linux 35 (Thirty Five)
-This is the policy i should be hitting, and NAT is working for all traffic except TCP packets with the FIN, PSH and URG flags set
:
outbound (active)
priority: -60
target: CONTINUE
ingress-zones: ANY
egress-zones: external
services:
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="10.0.0.0/16" port port="137" protocol="tcp" drop
rule family="ipv4" source address="10.0.0.0/16" port port="138" protocol="tcp" drop
rule family="ipv4" source address="10.0.0.0/16" port port="139" protocol="tcp" drop
rule family="ipv4" source address="10.0.0.0/16" port port="137" protocol="udp" drop
rule family="ipv4" source address="10.0.0.0/16" port port="138" protocol="udp" drop
rule family="ipv4" source address="10.0.0.0/16" port port="139" protocol="udp" drop
What happened: removing passthroughts and doing reload wont remove the rules
What you expected to happen: on reload rules not appear
How to reproduce it (as minimally and precisely as possible):
firewall-cmd --permanent --direct --passthrough ipv4 -I FORWARD -o virbr0 -j ACCEPT firewall-cmd --direct --get-all-passthroughs firewall-cmd --permanent --direct --remove-passthrough ipv4 -I FORWARD -o virbr0 -j ACCEPT firewall-cmd --reload firewall-cmd --permanent --direct --remove-passthrough ipv4 -I FORWARD -o virbr0 -j ACCEPT
Anything else we need to know?:
workaround: systemctl restart firewalld.service
Environment:
- Firewalld Version (if Fedora based
dnf info firewalld
or commit hash if developing from gitgit log -n1 --format=format:"%H"
): 1.1.1 - Firewalld Backend (
cat /etc/firewalld/firewalld.conf | grep FirewallBackend
):nftables
- OS (e.g:
cat /etc/os-release
):
NAME="openSUSE Tumbleweed"
# VERSION="20220428"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20220428"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20220428"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed
- Others:
What would you like to be added: May we get a container image (Docker) for aarch64 (arm64) added to the release distribution?
Why is this needed: ARM64 systems are increasing and an image for aarch (arm64) would help those using these platforms to manage them. This would also help increase the firewall knowledge base for these systems. Thanks for your time.