You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
Sometimes
stderr: 'iptables: No chain/target/match by that name.'
andstderr: '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/
The text was updated successfully, but these errors were encountered: