Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking does not seem to work yet #9

Open
szaimen opened this issue Sep 27, 2023 · 2 comments
Open

Blocking does not seem to work yet #9

szaimen opened this issue Sep 27, 2023 · 2 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@szaimen
Copy link
Owner

szaimen commented Sep 27, 2023

Sometimes stderr: 'iptables: No chain/target/match by that name.' and stderr: 'ip6tables: No chain/target/match by that name.' gets printed in the logs and access is still possible.

Might need to follow https://silvermou.se/how-to-resolve-no-chain-target-match-by-that-name-when-using-iptables-multiport-and-fail2ban/ and/or NginxProxyManager/nginx-proxy-manager#39 (comment) to make it work

Also see https://github.com/linuxserver/fail2ban-confs/

@szaimen szaimen added the bug Something isn't working label Sep 27, 2023
@szaimen szaimen added the help wanted Extra attention is needed label Jan 13, 2024
@Blablach
Copy link

Hi there,

I encountered the same issue you've reported, where the logs showed errors like iptables: No chain/target/match by that name. and ip6tables: No chain/target/match by that name., indicating that Fail2Ban was not functioning as expected.

After some investigation, I found the root cause to be a mismatch between the iptables versions used by my host system and the Fail2Ban Docker container. Specifically, the Docker container uses iptables-nft while my host was using iptables-legacy.

This mismatch led to a scenario where the Fail2Ban container could not find the DOCKER-USER chain, as it only existed under the iptables-legacy system on the host. This chain is crucial for Docker to implement networking rules that isolate containers, and it's also where Fail2Ban needs to insert rules to ban malicious IP addresses.

The solution I found was to align the iptables version used by both the host and the Fail2Ban container. On my host, I switched to iptables-nft to match the container. This can be achieved by using the update-alternatives system, setting iptables-nft as the default. Here's how you can do it:

sudo update-alternatives --set iptables /usr/sbin/iptables-nft
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

After making this change, Fail2Ban started working as expected, with no more errors about missing chains or targets in the logs.

I hope this helps resolve the issue for anyone else experiencing similar problems. It's essential to ensure that both the host and container environments use compatible versions of iptables for Fail2Ban to function correctly in a Dockerized setup.

@szaimen
Copy link
Owner Author

szaimen commented Apr 2, 2024

Thanks for the hint! I added this to the usual docs via nextcloud/all-in-one@9736a77

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants