firehol-defaults.conf(5)

📦
version 3.1.8 · 4 versions
, in debian trixie, ubuntu resolute, ubuntu stonking

✨ NAME ✨

firehol-defaults.conf — it's the file that holds all the control variables for FireHOL. That's it, that's the whole job. 💅

(You're reading firehol-defaults.conf(5), version 3.1.8, bestie — pull up a chair.)

🌸 SYNOPSIS 🌸

Okay so these are the defaults, living their best life in /etc/firehol/firehol-defaults.conf:

  • DEFAULT_INTERFACE_POLICY="DROP"
  • DEFAULT_ROUTER_POLICY="RETURN"
  • UNMATCHED_INPUT_POLICY="DROP"
  • UNMATCHED_OUTPUT_POLICY="DROP"
  • UNMATCHED_FORWARD_POLICY="DROP"
  • FIREHOL_INPUT_ACTIVATION_POLICY="ACCEPT"
  • FIREHOL_OUTPUT_ACTIVATION_POLICY="ACCEPT"
  • FIREHOL_FORWARD_ACTIVATION_POLICY="ACCEPT"
  • FIREHOL_LOG_MODE="LOG"
  • FIREHOL_LOG_LEVEL=see notes
  • FIREHOL_LOG_OPTIONS="--log-level warning"
  • FIREHOL_LOG_FREQUENCY="1/second"
  • FIREHOL_LOG_BURST="5"
  • FIREHOL_LOG_PREFIX=""
  • FIREHOL_DROP_INVALID="0"
  • DEFAULT_CLIENT_PORTS="1000:65535"
  • FIREHOL_NAT="0"
  • FIREHOL_ROUTING="0"
  • FIREHOL_AUTOSAVE=see notes
  • FIREHOL_AUTOSAVE6=see notes
  • FIREHOL_LOAD_KERNEL_MODULES="1"
  • FIREHOL_TRUST_LOOPBACK="1"
  • FIREHOL_DROP_ORPHAN_TCP_ACK_FIN="1"
  • FIREHOL_DROP_ORPHAN_TCP_ACK_RST="1"
  • FIREHOL_DROP_ORPHAN_TCP_ACK="1"
  • FIREHOL_DROP_ORPHAN_TCP_RST="1"
  • FIREHOL_DROP_ORPHAN_IPV4_ICMP_TYPE3="1"
  • WAIT_FOR_IFACE=""

🦋 DESCRIPTION 🦋

From FireHOL 3 onwards, all the variables that control how FireHOL behaves got moved out into their own separate little home: /etc/firehol/firehol-defaults.conf. Glow-up era, honestly. ✨

You can also set some of these variables in the main firehol.conf file, but don't — that's not recommended, because they might get used before the main config has even been processed. It's giving chaos. 🙈

FireHOL also sets some variables before it processes the config file, and you can absolutely use those as part of your own configuration. Those ones are documented over in firehol.conf(5).

👑 VARIABLES 👑

DEFAULT_INTERFACE_POLICY

This one controls the default action taken on traffic that didn't get matched by any rule inside an interface. You can override it with firehol-policy(5), no cap.

Packets that hit the end of an interface without an action of return or accept get logged. Want to control how often that logging happens? Change FIREHOL_LOG_FREQUENCY. Easy.

Example:

DEFAULT_INTERFACE_POLICY="REJECT"

DEFAULT_ROUTER_POLICY

Same energy, different chain: this controls the default action for traffic not matched by any rule inside a router. Overridable with firehol-policy(5).

Packets that reach the end of a router without an action of return or accept are logged. Again, FIREHOL_LOG_FREQUENCY is your girl for controlling how often.

Example:

DEFAULT_ROUTER_POLICY="REJECT"

UNMATCHED_{INPUT|OUTPUT|FORWARD}_POLICY

These three control the default action taken on traffic that wasn't matched by any interface or router definition — incoming, outgoing, or forwarding respectively. Any supported value from firehol-actions(5) is fair game.

Real talk: all packets that reach the end of a chain get logged, no matter what you set here. And yep, FIREHOL_LOG_FREQUENCY controls the frequency of that logging too.

Example:

UNMATCHED_INPUT_POLICY="REJECT"
UNMATCHED_OUTPUT_POLICY="REJECT"
UNMATCHED_FORWARD_POLICY="REJECT"

FIREHOL_{INPUT|OUTPUT|FORWARD}_ACTIVATION_POLICY

These control the default action taken on traffic during firewall activation — for incoming, outgoing and forwarding respectively. The acceptable values are ACCEPT, DROP and REJECT. That's the whole menu.

FireHOL defaults every single one of these to ACCEPT so your connections keep vibing uninterrupted while everything swaps over. 🫶

But if you want to block connections while the new firewall is activating, set these to DROP. This matters a lot if you're using all or any to match traffic — because connections established during activation will keep on going even if they wouldn't have been allowed once the firewall is fully established. Periodt.

Example:

FIREHOL_INPUT_ACTIVATION_POLICY="DROP"
FIREHOL_OUTPUT_ACTIVATION_POLICY="DROP"
FIREHOL_FORWARD_ACTIVATION_POLICY="DROP"

FIREHOL_LOG_MODE

Controls the method FireHOL uses to log. That's it.

Acceptable values are LOG (normal syslog) and ULOG (netfilter ulogd). Heads up: when you pick ULOG, FIREHOL_LOG_LEVEL gets ignored entirely.

Example:

FIREHOL_LOG_MODE="ULOG"

Wanna see what options exist? Run: /sbin/iptables -j LOG --help or /sbin/iptables -j ULOG --help

FIREHOL_LOG_LEVEL

This sets the level at which events get logged to syslog.

So that your packet logs don't go feral all over your console, make sure klogd only logs traffic that's more important than the stuff FireHOL produces. Use the option below to pick an iptables(8) log level (alpha or numeric) that's higher than the -c of klogd.

Levels, iptables ↔ klogd, the whole lineup:

  • emerg (0) / klogd 0 — system is unusable
  • alert (1) / klogd 1 — action must be taken immediately
  • crit (2) / klogd 2 — critical conditions
  • error (3) / klogd 3 — error conditions
  • warning (4) / klogd 4 — warning conditions
  • notice (5) / klogd 5 — normal but significant condition
  • info (6) / klogd 6 — informational
  • debug (7) / klogd 7 — debug-level messages
Note 💀 The default for klogd is generally to log everything (7 and lower), and the default level for iptables(4) is to log as warning (4). So yeah, know your numbers.

FIREHOL_LOG_OPTIONS

Controls the way events get logged to syslog. Vibe check on your log output, basically.

Example:

FIREHOL_LOG_OPTIONS="--log-level info \
                     --log-tcp-options --log-ip-options"

To see the available options run: /sbin/iptables -j LOG --help

FIREHOL_LOG_FREQUENCY; FIREHOL_LOG_BURST

These two control how often each logging rule is allowed to write events to syslog. FIREHOL_LOG_FREQUENCY gets set to the maximum average frequency, and FIREHOL_LOG_BURST specifies the maximum initial number. Rate limiting, but make it cute. 🔥

Example:

FIREHOL_LOG_FREQUENCY="30/minute"
FIREHOL_LOG_BURST="2"

To see the available options run: /sbin/iptables -m limit --help

FIREHOL_LOG_PREFIX

This value gets added to the contents of every logged line, so you can spot FireHOL lines in your system logs at a glance. Iconic for grepping. By default it's empty.

Example:

FIREHOL_LOG_PREFIX="FIREHOL:"

FIREHOL_DROP_INVALID

If you set this to 1, FireHOL will drop all packets matched as INVALID by the iptables(8) connection tracker. Bye. 👋

Honestly though? You might be better off using firehol-protection(5) to control matching of INVALID packets (and others) on a per-interface and per-router basis.

Note 🌸 Care must be taken on IPv6 interfaces, because ICMPv6 packets like Neighbour Discovery are not tracked — which means they get marked as INVALID. Not a drill.

Example:

FIREHOL_DROP_INVALID="1"

DEFAULT_CLIENT_PORTS

This controls the port range used when a remote client is specified. But for clients on the local host, FireHOL doesn't guess — it finds the exact client ports by querying the kernel options. She did her research. 💅

Example:

DEFAULT_CLIENT_PORTS="0:65535"

FIREHOL_NAT

If you set this to 1, FireHOL loads the NAT kernel modules. And plot twist: if you make use of the NAT helper commands, the variable gets set to 1 automatically. It handles itself.

Example:

FIREHOL_NAT="1"

FIREHOL_ROUTING

If you set this to 1, FireHOL enables routing in the kernel. Same deal as NAT — if you use router definitions or certain helper commands, it gets set to 1 automatically. ✨

Example:

FIREHOL_ROUTING="1"

FIREHOL_AUTOSAVE; FIREHOL_AUTOSAVE6

These specify the file of IPv4 / IPv6 rules that gets created when firehol(1) is called with the save argument.

If the variable isn't set, a system-specific value is used — one that was defined at configure-time. And if no value was chosen? Then the save fails. So, like, set it.

Example:

FIREHOL_AUTOSAVE="/tmp/firehol-saved-ipv4.txt"
FIREHOL_AUTOSAVE6="/tmp/firehol-saved-ipv6.txt"

FIREHOL_LOAD_KERNEL_MODULES

If you set this to 0, FireHOL is forced to not load any kernel modules. You only need this if the kernel has modules statically included, and in the rare event that FireHOL can't access the kernel configuration.

Example:

FIREHOL_LOAD_KERNEL_MODULES="0"

FIREHOL_TRUST_LOOPBACK

If you set this to 0, the loopback device lo will not be trusted, and you can write standard firewall rules for it. Main character energy, you're in charge now.

Warning 😭 If you do not set up appropriate rules, local processes will not be able to communicate with each other — which can result in serious breakages. Be so serious about this one.

By default lo is trusted, and all INPUT and OUTPUT traffic is accepted (forwarding is not included — don't get it twisted).

Example:

FIREHOL_TRUST_LOOPBACK="0"

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN

If you set this to 1, FireHOL will drop all orphan such packets without logging them. Silent treatment. 🙈

Why does this exist? In busy environments, the iptables(8) connection tracker removes connection tracking list entries the second it receives a FIN. That makes the ACK FIN show up as an invalid packet — which would normally get logged by FireHOL.

Example:

FIREHOL_DROP_ORPHAN_TCP_ACK_FIN="1"

FIREHOL_DROP_ORPHAN_TCP_ACK_RST

If you set this to 1, FireHOL will drop all orphan such packets without logging them.

Same story, different flag: in busy environments, the iptables(8) connection tracker removes connection tracking list entries as soon as it receives a RST. This makes the ACK RST appear as an invalid packet — which, yep, would normally be logged by FireHOL.

Example, bestie, so you can see it in the wild:

FIREHOL_DROP_ORPHAN_TCP_ACK_RST="1"

FIREHOL_DROP_ORPHAN_TCP_ACK

Set this to 1 and FireHOL will drop all orphan such packets without logging them. No receipts, no drama. 💅

Here's the tea though: in busy environments the iptables(8) connection tracker removes unneeded connection tracking list entries. That little glow-up makes ACK packets show up looking like an invalid packet, which — normally — FireHOL is gonna log. Every time. So if you don't wanna hear about it:

FIREHOL_DROP_ORPHAN_TCP_ACK="1"

FIREHOL_DROP_ORPHAN_TCP_RST

Same energy, different packet. Set it to 1 and FireHOL will drop all orphan such packets without logging them. ✨

And again, the lore: in busy environments the iptables(8) connection tracker removes unneeded connection tracking list entries. This makes RST packets appear as an invalid packet which will normally be logged by FireHOL. Not anymore if you say so:

FIREHOL_DROP_ORPHAN_TCP_RST="1"

FIREHOL_DROP_ORPHAN_IPV4_ICMP_TYPE3

You guessed it — set this to 1 and FireHOL will drop all orphan ICMP destination unreachable packets without logging them. 🫶

And yes, the same situation applies: in busy environments the iptables(8) connection tracker removes unneeded connection tracking list entries. This makes ICMP destination unreachable appear as an invalid packet which will normally be logged by FireHOL. Silence it like this:

FIREHOL_DROP_ORPHAN_IPV4_ICMP_TYPE3="1"

WAIT_FOR_IFACE

Okay this one is giving patience. Set it to the name of a network device (like eth0) and FireHOL will wait until the device is up (or until 60 seconds have elapsed) before continuing. Sixty seconds, then it moves on regardless. ⏳

Fr fr, don't just slap this in because it sounds responsible. A device does not need to be up in order to have firewall rules created for it, so this option should only be used if you have a specific need to wait (e.g. the network must be queried to determine the hosts or ports which will be firewalled).

Example, since you know I always come with the receipts:

WAIT_FOR_IFACE="eth0"

🌈 SEE ALSO 🌈

Sis, go read these too, they're all part of the same universe:

👑 AUTHORS 👑

FireHOL Team. That's it, that's the whole crew. Respect. 🫡

And that's a wrap on firehol-defaults.conf(5), bestie — FireHOL Reference, built 13 Apr 2025, and you just read the whole thing. Not everyone can say that. Go configure something iconic. 💖✨🎀

📦 where this page comes from