I came here to report the same problem and found there was already this bug, so consider this a confirmation. I am certain that /etc/default/firehol did work as documented at some point in the past.
Probably a better title for this bug might have been “/etc/defaults/firehol is ignored” since that is the actual problem. I hit this bug on a desktop and was merely annoyed at the sudden blast of netfilter logs on the console as soon as the package installed. So the current title does not apply to my situation at all even though it is really the exact same problem. ;-) A default policy like suggested would have terrible security implications, as people with other filtering already in place could unintentionally open up their machine just by installing the package. Best to just fix the default start-up behaviour. It looks like this bug is probably a result of migration from init.d script to systemd unit. The init.d script is where the check for START_FIREHOL happen(s/ed) but the systemd unit doesn’t contain anything equivalent. Not sure what fix would be correct. I.e., fix things so that /etc/default/firehol works again, or change the systemd unit to not start by default (or both)? Either would restore the desired previous behaviour of not starting by default. I’m assuming there’s likely some sort of Debian policy relevant to how default behaviour should happen.
