I'm very confused where I am going wrong with setting up fail2ban on SWAG reverse proxy. I am using the fail2ban included with SWAG. I have looked up every guide I could find regarding SWAG, fail2ban, Docker, and tried all fixes to get fail2ban to work, to no avail. The fail2ban properly see's the login attempts to Vaultwarden, and after max retries bans the IP, but the IP is still able to access the service. I am using a Cloudflare tunnel to accept connection, so in SWAG I use Cloudflare real IP and have confirmed the banned IP's to be actual user IP's. I believe the problem resides somewhere with iptables, but lack the knowledge to know for sure. I've attached all images that could be of any use to solve this issue. Is there anything I am doing wrong? Thank you.

Edited December 14, 20241 yr by GayMan420

2 hours ago, GayMan420 said:

Thank you.

Please use the support thread from the container, go to your Docker page, click on the icon from the container and Support, or you can go directly to it here:

 

  

On 12/14/2024 at 3:44 AM, GayMan420 said:

I'm very confused where I am going wrong with setting up fail2ban on SWAG reverse proxy. I am using the fail2ban included with SWAG. I have looked up every guide I could find regarding SWAG, fail2ban, Docker, and tried all fixes to get fail2ban to work, to no avail. The fail2ban properly see's the login attempts to Vaultwarden, and after max retries bans the IP, but the IP is still able to access the service. I am using a Cloudflare tunnel to accept connection, so in SWAG I use Cloudflare real IP and have confirmed the banned IP's to be actual user IP's. I believe the problem resides somewhere with iptables, but lack the knowledge to know for sure. I've attached all images that could be of any use to solve this issue. Is there anything I am doing wrong? Thank you.

 

I believe I hit the same Problem. Check you fail2ban.log for any iptables Errors.

 

iptables error in `fail2ban.log`:

2025-01-09 21:23:55,807 149A58AACB38 ERROR 149a5a398030 -- exec: { iptables -w -C f2b-vaultwarden-auth -j RETURN >/dev/null 2>&1; } || { iptables -w -N f2b-vaultwarden-auth || true; iptables -w -A f2b-vaultwarden-auth -j RETURN; }
for proto in $(echo 'tcp' | sed 's/,/ /g'); do
{ iptables -w -C DOCKER-USER -p $proto -m multiport --dports http,https -j f2b-vaultwarden-auth >/dev/null 2>&1; } || { iptables -w -I DOCKER-USER -p $proto -m multiport --dports http,https -j f2b-vaultwarden-auth; }
done
 2025-01-09 21:23:55,807 149A58AACB38 ERROR 149a5a398030 -- stderr: 'iptables: No chain/target/match by that name.'
 2025-01-09 21:23:55,807 149A58AACB38 ERROR 149a5a398030 -- returned 1
 2025-01-09 21:23:55,808 149A58AACB38 ERROR Failed to execute ban jail 'vaultwarden-auth' action 'iptables-multiport' info 'ActionInfo({'ip': '111.222.333.444', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x149a5ab85800>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x149a5ab85f80>})': Error starting action Jail('vaultwarden-auth')/iptables-multiport: 'Script error'

 

The Problem is, the linuxserver.io docker 1.1.0 container has `iptables v1.8.10 (nf_tables)` and UNRAID 6.12.14 has `iptables v1.8.9 (legacy)`. So the container is using an other iptables modules as UNRAID as the docker host. One can check this by running `iptables --version` and the docker host and in the fail2ban container.

 

The solution is to change the banaction to use iptables-legacy.

 

Example:

[DEFAULT]
banaction = iptables-multiport[iptables=iptables-legacy]

 

Then the iptables rule should be added correctly in iptables on the UNRAID docker host and the blocking should work.

 

root@unraid:~# iptables -L -n
...
Chain DOCKER-USER (1 references)
target     prot opt source               destination         
f2b-vaultwarden-auth  6    --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
RETURN     0    --  0.0.0.0/0            0.0.0.0/0           
...
Chain f2b-vaultwarden-auth (1 references)
target     prot opt source               destination         
REJECT     0    --  111.222.333.444       0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     0    --  0.0.0.0/0            0.0.0.0/0

 

Edited January 9, 20251 yr by pixeldoc81
Missing Quote

this seems more liek a issue with your fail2 ban config..

sounds like you need to setup a jail.

 

https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/

https://www.a2hosting.com/kb/security/hardening-a-server-with-fail2ban/#Configuring-fail2ban

 

fail2ban is not configured for you out of the box...

There is a much simpler solution to use fail2ban with swag without using the iptables of Unraid:

(1) Create an empty "blocklist.conf" file in /nginx/site-confs;

(2) Create an "nginx-blocklist.conf" file in /fail2ban/action.d with the following content:

[Definition]

actionstart =

actionstop =

actioncheck =

actionban = echo "deny <ip>;" >> /config/nginx/site-confs/blocklist.conf && nginx -s reload

actionunban = sed -i '/deny <ip>;/d' /config/nginx/site-confs/blocklist.conf && nginx -s reload

[Init]

(3) Edit your "jail.local" for an application to be monitored, in my example owncloud:

[owncloud]

enabled = true

port = http,https

filter = owncloud

logpath = /fail2ban/owncloud.log

maxretry = 3

findtime = 600

bantime = 10800

action = nginx-blocklist

(4) Create the corresponding filter, in my example "owncloud.local", in /fail2ban/filter.d:

[Definition]

failregex = ^{"reqId":"[^"]*","level":\d+,"time":"[^"]*","remoteAddr":"<HOST>","user":"[^"]*","app":"core","method":"[^"]*","url":"[^"]*","message":"Login failed: [^"]* \(Remote IP: '[^']*'\)"}$

ignoreregex =

datepattern = %%Y-%%m-%%dT%%H:%%M:%%S

That's it. After three failed login attempts, the IP address to be blocked is now added to the "/nginx/site-confs/blocklist.conf" file. Access is blocked.

Tip: Set the following environment variable in docker: "SWAG_AUTORELOAD=true"

Edited August 9, 2025Aug 9 by Novaliz