Change:
Describe the bug when configured to use ipset actions fail2ban fails to ban because the action script cannot find the ipset binary. To Reproduce Steps to reproduce the behavior: configure fail2ban to use actions, then cause a ban (eg invalid ssh logins) Expected behavior iptables rules and ipsets for the ban are created. Screenshots Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
The fail2ban derivation doesn't bring in ipset, it's also going to need some patching of the fail2ban conf files. Need to research if ipset protocol 6 is availble in nixpkgs, ipset v4 does seem to exist.
unstable has ipset 7.11, 20.03 has ipset 7.5, 20.09 has ipset 7.6. all of those should be protocol version 7 and thus work with the v6 actions i think?
fwiw adding ipset to the fail2ban service path in seems sufficient to get this to work.
In ! lets see if the practise matches up! :-) wow, you joined github 2 days ago... welcome to github!
we've applied that setting locally and so far haven't seen any problems across quite a few restarts and ban/unban actions. seems good! :)
what would be a good way to solve this for the next person? there's two things we could think of: add ipset to path when using iptables as the firewall backend (like sshguard does) extend firewallPackage to firewallPackages and let people who want ipset add it there second one sounds cleaner, not least because using nftables already requires changing firewallPackage. that would require deprecating firewallPackage though, and i don't feel qualified to do that
is extra packages the way to go? ipset is needed by fail2ban, so should it be a dependency by default? I've been flat out working so not had time to look at this. These are just questions not demands!
ipset isn't needed by the default configuration of fail2ban, only if you choose a different ban action. if the default action and ipset were the only options i'd totally agree that ipset should be a dependency, but there's quite a few more actions: some send mail, some call into shorewall, or curl something to cloudflare, or even call into BIND to update a dns zone. since we'd need some extraPackages mechanism to support those properly anyway it didn't feel quite right to elevate one action to default-dependency and leaving out all the others (especially since nftables doesn't even need ipset to provide the same functionality). but i've got no feelings on this. if y'all want ipset to be a default dependency i'm perfectly fine doing that instead. would very much like to keep extraPackages though for the stated reasons.

Discussion:
description = "The firewall package used by fail2ban service."; }; <ins> extraPackages = mkOption { default = []; type = types.listOf types.package; example = lib.literalExample "[ pkgs.ipset ]"; description = '' Extra packages to be made available to the fail2ban service. The example contains the packages needed by the `iptables-ipset-proto6` action. ''; }; maxretry = mkOption { default = 3; type = types.ints.unsigned; description = "Number of failures before a host gets banned."; }; </ins> banaction = mkOption { default = "iptables-multiport"; type = types.str;

restartTriggers = [ fail2banConf jailConf pathsConf ]; reloadIfChanged = true; <del> path = [ cfg.package cfg.packageFirewall pkgs.iproute2 ]; </del> <ins> path = [ cfg.package cfg.packageFirewall pkgs.iproute2 ] ++ cfg.extraPackages; </ins> unitConfig.Documentation = "man:fail2ban(1)";

''} # Miscellaneous options ignoreip    = 127.0.0.1/8 ${optionalString config.networking.enableIPv6 "::1"} ${concatStringsSep " " cfg.ignoreIP} <del> maxretry    = 3 </del> <ins> maxretry    = ${toString cfg.maxretry} </ins> backend     = systemd # Actions banaction   = ${cfg.banaction}