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 ]

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?

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?

Having a fully-automated install motivates my questions.

-- 
Mike

:wq

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