From d21158b424154f4b44cce286318cb5083b1eef82 Mon Sep 17 00:00:00 2001
From: Maximilian Wank <59979728+maximilianwank@users.noreply.github.com>
Date: Thu, 25 Jul 2024 15:46:30 +0200
Subject: [PATCH] Add fix for Docker deployments with Fail2Ban v1.1.1.dev1

---
 Fail2Ban-Setup.md | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Fail2Ban-Setup.md b/Fail2Ban-Setup.md
index bb3a599..74397dc 100644
--- a/Fail2Ban-Setup.md
+++ b/Fail2Ban-Setup.md
@@ -155,14 +155,21 @@ findtime = 14400
 
 ###### Note for Docker Users
 
-Docker uses the FORWARD chain instead of the default INPUT chain. If the machine receiving requests is mapping them straight to a Docker container, then chain will need to be set appropriately regardless of what is in the container (reverse proxy, Vaultwarden, etc). The default `action` is set to `action_` (which uses `banaction`, which we alias to `banaction_allports`). `action_` already takes the chain into account. Thus, simply set the `chain`. See [this similar issue](https://forum.openwrt.org/t/resolved-fail2ban-and-iptables-ip-bans-not-blocked/90057).
+Docker uses the `FORWARD` chain instead of the default INPUT chain. If the machine receiving requests is mapping them straight to a Docker container, then chain will need to be set appropriately regardless of what is in the container (reverse proxy, Vaultwarden, etc). The default `action` is set to `action_` (which uses `banaction`, which we alias to `banaction_allports`). `action_` already takes the chain into account. Thus, simply set the `chain`. See [this similar issue](https://forum.openwrt.org/t/resolved-fail2ban-and-iptables-ip-bans-not-blocked/90057).
 
 ```ini
 chain = FORWARD
 ```
 
+###### Note for Docker Users with Fail2Ban v1.1.1.dev1 (and possibly newer)
+
+With Fail2Ban v1.1.1.dev1 the default `banactions` for Debian changed from iptables to nftables (see [here](https://github.com/fail2ban/fail2ban/commit/d0d07285234871bad3dc0c359d0ec03365b6dddc)). Docker (at least version 25.0.3) on the other hand still uses iptables. Hence, the requests to the Docker containers are not blocked with `banaction = %(banaction_allports)s`. In this scenario, use
+```ini
+banaction = iptables
+``` 
+
 **Tip**: If you are using systemd to manage vaultwarden, you can use systemd-journal for fail2ban:
-```
+```ini
 backend = systemd
 filter = vaultwarden[journalmatch='_SYSTEMD_UNIT=your_vaultwarden.service']
 ```