#51 Make the INPUT chain configurable


Currently, the default iptables-* actions of fail2ban always add a rule to the INPUT chain. This rule jumps to the relevant fail2ban chain which contains the actual bans, so not everything ends up in the INPUT chain, but the main entrypoint for fail2ban does.

This conflicts with my firewall, vuurmuur (and will probably conflict with others as well, see Debian #515599). When vuurmuur restarts, it flushes the INPUT chain, removing the fail2ban rule as well. I could fix this by restarting fail2ban as well, but I was hoping for a slightly more elegant solution.

Vuurmuur exposes a number of "hooking" chains, which are empty user defined chains which are called by Vuurmuur, but their contents are never touched. In this case, I'm interested in the PRE-VRMR-INPUT chain, which is called by Vuurmuur at the start of the INPUT chain, before any rules are processed. To make fail2ban play nicely with Vuurmuur, it should just add its rules to this chain.

So, for the actual feature request: I would like to have some easier way to change the chain that fail2ban operates on. Currently, I have to copy the iptables action I'm using and change the chain in there. Making this configurable in the default iptables-*.conf actions would be preferable.

For this to work, a few changes would be needed. First, every action.d/iptables*.conf file needs to add the following line to their [Init] section:

# Option: chain
# Notes specifies the iptables chain to which the fail2ban rules
# should be
# added
# Values: STRING Default: INPUT
chain = INPUT

Furthermore, all occurences of "INPUT" should be replaced with

Now, we can change the chain used for any service by changing the
corresponding action= line in jail.conf. This is still not entirely
convenient, so it might be even better to use the approach that the
Debian package takes by defining a action_ variable that interpolates
the needed variables.

I've tried this approach for just the iptables.conf action and it works,
but I don't have time for providing a full patch.


  • Nobody/Anonymous

    Alternative way is to use [INCLUDES] and define
    common.conf (.local) under actions.d (now we have only under
    filters.d) which would define smth like


    # Load customizations if any available
    after = common.local


    _hook_chain = INPUT

    and then in iptables-* actions to actually include common.conf


    # Load customizations if any available
    after = common.conf

    and then instead of

    -I INPUT


    -I %(_hook_chain)s


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks