Fail2ban wont start

So as of late yesterday, System Admin ver. was promoted to stable which should resolve the fail2ban starting issue. Upgrading sysadmin can be done in the conventional way using the GUI or you can run:

fwconsole ma upgrade downloadinstall sysadmin --tag

confirm installed version with:

fwconsole ma list | grep sysadmin

confirm fail2ban status with

systemctl status fail2ban

restart fail2ban with

systemctl restart fail2ban
1 Like

I’ve got a fresh install from last night with this same issue.
| sysadmin |
fail2ban-fpbx.noarch 0.8.14-76.sng7 @anaconda/2011

I had to run the following to fix it as others suggested :

No fix yet for me. I’ll trying moving to a new vm I guess.

I wonder what

sudo fail2ban-client restart

would return, apparently the systemd fail2ban.service is disabled in the distro so something is otherwise doing fail2ban-client -x start or systemctl start fail2ban (both of which would fail if it is actually already running) , as to your previous iptables status, then iptables -L -n before and after might be helpful

Where I to suggest a solution . . .

systemctl stop fail2ban.service
systemctl start yourfirewall.service
systemctl start fail2ban.service

of course yourfirewall.service should not be messing with fail2ban in any way (tested working on f2b >= 0.8 with its distributed systemd service installed for “lot’s of years”)

ERROR Unable to contact server. Is it running?

Try Fail2ban-client -x start

or fail2ban-client -x -f restart to clean out the run file and run in the foreground

ERROR Found no accessible config files for ‘filter.d/zulu’ under /etc/fail2ban
ERROR Unable to read the filter
ERROR Errors in jail ‘zulu’. Skipping…

This is why I originally uninstalled Zulu. I just tried reinstalling it and running the command again. Same result.

Usage: /bin/fail2ban-client [OPTIONS]

Fail2Ban v0.8.14 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.

-c configuration directory
-s socket path
-p pidfile path
-d dump configuration. For debugging
-i interactive mode
-v increase verbosity
-q decrease verbosity
-x force execution of the server (remove socket file)
-h, --help display this help message
-V, --version print the version

start starts the server and the jails
reload reloads the configuration
reload reloads the jail

and so on

I guess that version is too old for running in the foreground :wink:

Perhaps you could restart it with -xvvv and either it might on the screen or you could tail the log file :wink:

Edit jail.local and remove the Zulu jail


That seems to have done it on this server. Intrusion detection rules were of course wiped out but syncing it with the trusted networks and registered extensions works now.

Will go check the other servers that were having this issue and report back. Thanks.

In case this fixes anyone else’s issue my sysadmin module was updated via the GUI to the edge track (forgot that was set to edge mode) to version . I commented out the lines about the zuu jail in /etc/fail2ban/jail.local. Then ran fail2ban-client -x start and now it appears to be working. Will see if CPU usage goes up again.

1 Like

It will always be higher if you restart it later in the day as your logs grow, well written logrotate mitigates a little in the early morning by resetting the log files being watched to 0 length , but while fail2ban remains at 0.8 you are hamstrung until Sangoma takes this problem seriously and decouples “intrusion detection” from it’s commercial “firewall” or at least makes them play well together. IMHO F2B >=0.10 would be a good place for them to start :wink: (as far is I can experiment, badly written “jails” are no longer fatal, just ignored)

fwconsole ma downloadinstall sysadmin --tag -f
```did it for me. Stepping back from However same error before in ..71.
I'm not using Zulu.
see CLI, where sysadmin_fail2ban is updated.

No repos specified, using: [standard,extended,commercial] from last GUI settings

Starting module download from ...
 852497/852497 [============================] 100%
Finished downloading
Module successfully downloaded
Updating tables sysadmin_options, sysadmin_update_log, sysadmin_fail2ban...Done
Sangoma PnP Server activated
Generating CSS...Done
Module sysadmin version successfully installed
Updating Hooks...Done
Chowning directories...Done
[[email protected] fail2ban]# systemctl start fail2ban.service
[[email protected] fail2ban]# 

I will not upgrade to ..72 again until green light from Lorne

I’ve got another with a similar problem but this time it’s got a problem with apache-api jail. Is that safe to comment out?

fail2ban-client -x start
ERROR Found no accessible config files for ‘filter.d/apache-api’ under /etc/fail2ban
ERROR Unable to read the filter
ERROR Errors in jail ‘apache-api’. Skipping…

Unfortunately as yet everything posted in this thread (and other similar ones) are closed source as to resolution , so you will have to add your problems behind the dozens of other unresolved dependencies that await attention by Sangoma.

( crocodiles have alarm clocks, a quick ameliorative I can suggest is to stop listening to UDP/5060 before it bites you, and sngrep will show all the exposure you already have, because your firewall is apparently broken and every ‘bot’ and their ‘controller’ knows it)

What port ranges are you using?

Best choice a properly configured and certified TLS on 5061 (easy), next a TCP connection on anything outside 5000-5999 (BTDT, they are not stupid) , lastly and for UDP if you insist , at your chosen random port between 49152 and 65535.

Everyone will tell you that security by obfuscation is dumb, I disagree, add an iptables ‘port scanner’ to DROP such attemp’s and wait for an intrusion . . .

Again TLS is the way to go, your STIR/ SHAKEN headers can’t be fragmented (as ultimately they will over UDP as the concept gets traction) . . .


I updated to sysadmin but /etc/fail2ban/filter.d/apache-api is still not created.

[[email protected] ~]# ls -l /etc/fail2ban/filter.d/asterisk*
-rw-r–r-- 1 root root 3009 Aug 5 2018 /etc/fail2ban/filter.d/asterisk.conf
lrwxrwxrwx. 1 root root 36 Sep 4 2017 /etc/fail2ban/filter.d/asterisk-security.conf -> /etc/fail2ban/filter.d/asterisk.conf
[[email protected] ~]#
[[email protected] ~]#
[[email protected] ~]# fwconsole ma list | grep sysadmin
| sysadmin | | Enabled | Commercial |
[[email protected] ~]#


For what it’s worth I took the apache-api.conf from another server and uploaded it to the one where I had that problem and it seemed to fix the issue. The file is only a couple lines long if you want to try it

API filter access forbiden 403


failregex = ^ -."./admin/api/.*".403.$

ignoreregex =

The comment seems to trigger bold characters in the forums, but that first line is commented out. Also, permissions set to root (group and owner) and octal 0644

1 Like

Thank you. I actually checked another one of my PBXes but it was missing for that also.

I’ll upload and see how I get on, thank you so .ich for that!