Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 7F50078015A for <~alpine/devel@lists.alpinelinux.org>; Fri, 2 Sep 2022 10:48:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id F03F667B47; Fri, 2 Sep 2022 13:48:21 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id X4sqqrCY1hA9; Fri, 2 Sep 2022 13:48:20 +0300 (EEST) Received: from kanala.kunkku.net (178-75-143-27.bb.dnainternet.fi [178.75.143.27]) by welho-smtp3.welho.com (Postfix) with ESMTP id DFC572315; Fri, 2 Sep 2022 13:48:17 +0300 (EEST) Received: from kanala.kunkku.net (kanala.kunkku.net [127.0.0.1]) by kanala.kunkku.net (8.17.1/8.15.2) with ESMTP id 282AmGgP674352; Fri, 2 Sep 2022 13:48:16 +0300 Received: from localhost (kaarle@localhost) by kanala.kunkku.net (8.17.1/8.17.1/Submit) with ESMTP id 282AmEXB674349; Fri, 2 Sep 2022 13:48:16 +0300 X-Authentication-Warning: kanala.kunkku.net: kaarle owned process doing -bs Date: Fri, 2 Sep 2022 13:48:14 +0300 (EEST) From: Kaarle Ritvanen To: "W. Michael Petullo" cc: ~alpine/devel@lists.alpinelinux.org Subject: Re: Strange behavior in "awall activate -f" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Sun, 28 Aug 2022, W. Michael Petullo wrote: > I find that "awall activate -f" fails on a fresh install unless I run > "awall activate" at least once in interactive mode first. The failure > message is: > > host:~# (Deploy firewall rules ...) > host:~# awall activate -f > Warning: firewall not enabled for inet6 > Warning: firewall not enabled for inet > awall: Firewall not enabled in kernel > > It turns out this is because the ip_tables and ip6_tables kernel > modules are not loaded. It seems "awall activate" will load the required > modules. Indeed, the first "awall activate" is quite chatty about doing > this and a number of other things: > > Warning: firewall not enabled for inet6 > Warning: firewall not enabled for inet > Firewall is not active > Press RETURN to perform initial configuration and activation: > * rc-update: ip6tables already installed in runlevel `default'; skipping > * Caching service dependencies ... > [ ok ] > * Loading ip6tables state and starting firewall ... > [ ok ] > * Enabling forwarding ... > [ ok ] > * rc-update: iptables already installed in runlevel `default'; skipping > * Caching service dependencies ... > [ ok ] > * Loading iptables state and starting firewall ... > [ ok ] > * Enabling forwarding ... > [ ok ] The normal function of "awall activate" is to 1) replace the in-kernel iptables configuration with the one derived from the current awall policies and 2) persist this configuration to /etc/iptables once the user has confirmed it (interactively or with the -f flag). In case "awall activate" detects that the kernel modules are not loaded, it behaves differently: After setting up /etc/iptables, it enables and starts the iptables services. It also sets the SAVE_ON_STOP option to "no" to prevent the init scripts from overwriting the awall-generated rules on shutdown. This feature is not well documented nor currently works with the -f flag. So in your first example, awall does nothing. In the second example, awall performs the initial setup. It tries to add the iptables services to the default runlevel but they have already been added. The services just get started, resulting in loading the kernel modules and configuring the in-kernel rules. > If I do start a new system, load ip_tables and ip6_tables, and run > "awall activate -f", then awall runs without error. However, I do not > see evidence of the other configuration going on, as with the output from > "awall activate" above. > > My questions: > > Should "awall activate -f" be changed to load the kernel modules, as > interactive mode does? Is there a reason for the inconsistency? Allowing the -f flag with the initial setup mode is one option. However, maybe it would be better to add a new command (e.g. "awall init") for this purpose to make sure the user understands what he is doing. > Does running "awall activate -f" after manually loading the modules > perform all the steps to activate the firewall for the first time? > Put another way, does "awall activate -f" do everything "awall activate" > does, albeit in a much less verbose mode? If the modules were loaded manually prior to running "awall activate -f", the rules are set up in both /etc/iptables and the kernel, but no runlevel changes take place. SAVE_ON_STOP neither gets updated in /etc/conf.d. > Having a fully-automated install motivates my questions. For now, you could use: awall translate /usr/libexec/awall-init iptables /usr/libexec/awall-init ip6tables Alternatively, you could check out the setup-firewall command, which is included in the awall-policies package. BR, Kaarle