[Firehol-support] Changing activation policy

Phil Whineray phil.whineray at gmail.com
Sat May 19 17:53:15 BST 2012

For sanewall I think I should change the activation policy for the

Could people please let me know if this will adversely affect them and
if possible test what effect it has?

Just add to the top of your config:

If you are using firehol the equivalent would be to add:

There are two other policies for INPUT and OUTPUT, also set to ACCEPT
during activation. This as-designed, to avoid intefering with establish
connections whilst restarting and eliminated the risk that the host becomes
inaccessible to the admin if something goes wrong whilst restarting the
firewall remotely.

However, when using the "all" service the rules generated for the reverse
direction of flow ACCEPT any related packet, thus:
  route all accept
for an outgoing router creates a firewall which permits any _incoming_ traffic
for a connection which has already been established. As is necessary to
make the rule work.

In combination though, there is a short window when the firewall is being
constructed during which external hosts will be able to connect to a local
server and that that connection will not be severed once the firewall is

Individually specified services do not suffer from this problem because they
perform a check on the related traffic to ensure it belongs to an accepted
service, so the connection will be severed shortly after it was started,
which is how FireHOL is documented as working.

If anyone (me at home, for instance) is using "route all accept" on a
gateway this adds a same risk for ingress traffic. The FireHOL documentation
warns against using "client all" on production servers but not "route all".

By changing the forward activation policy I hope to close this gap where
it matters most (on gateway firewalls) but not add to the risk of failure
(since to restart the firewall remotely the connection in question must
have its traffic matched by INPUT and OUTPUT).

This will interfere with existing connections but my hope is that DROPing
will mean that the packets are retried as normal (for TCP, anyway) so
things should not be too badly affected.

The truly paranoid may want to set:
to be sure.


More information about the Firehol-support mailing list