Question Plesk firewall and preventing clashes with firewalld

[iainh]

Server operating system version

AlmaLinux 9.8 (Olive Jaguar)

Plesk version and microupdate number

Plesk Obsidian 18.0.79

I have my Plesk firewall set to only permit privileged service access only from my own IP (using the "Allow from selected sources, deny from others" rule option and listing my IP). This applies to the rules for "Plesk administrative interface" (and HTTP/3 equivalent) which I take to mean port 8443, SSH, FTP etc., however, I'm seeing failed login attempts as root against 'panel' which should be there give the above rules.

A deal of digging has found that the Plesk firewall UI is simply controlling nftables (previously iptables) which I was aware of, but that firewalld is also running (confirmed via systemctl status firewalld), and that the two compete and conflict in making (nftables) updates, and that firewalld will win rendering the Plesk rules irrelevant. Suddenly what I am seeing is explained, if not making sense (why is firewalld left running when the Plesk firewall is enabled?).

There's an article on this at Plesk for Linux and firewalld Compatibility which warns: "Both firewalld and the Plesk Firewall extension are tools for managing the iptables firewall. Using both tools simultaneously can result in conflicts and in ports required for Plesk to operate being closed. We recommend only using one tool at a time."
Google further advises: "If firewalld (on RHEL/AlmaLinux/Rocky) or ufw (on Ubuntu/Debian) is active, it will override or bypass the script Plesk uses (psa-firewall) to push rules into iptables. Plesk requires these native OS services to be completely disabled so it can manage iptables natively."

Okay, so there's my answer, I need to disable firewalld, so why don't you get on with it and why am I posting here? Becasue, Google references a Plesk Talk article Firewall suddenly took Plesk down overnight which cautions: "Some providers install correctly plesk with almalinux and firewalld is disabled while all needed ports are already at iptables via plesk firewall, at others firewalld is enabled with open only ssh dhcp and cokpit and need to open manually the others.
At these configurations if you disabled firewalld you will be locked out from ssh as iptable entries will be erased."

Right, so the solution is NOT to plough in with:

sudo systemctl stop firewalld
sudo systemctl disable firewalld

unless I want to lock myself out of my VPS. I guess I can ensure my virtual console is working okay and with that working, then go about disabling firewalld, but it would seem this needs a little thought and consideration if I'm not to give myself a world of pain.

So why post this here?

1. Becasue the discovery that simply enabling the Plesk firewall and setting access may not be providing the protection you are expecting may be of use to others, and
2. Maybe some wiser soul than me has been here, done all this, and has some advice on the correct steps to take to disable firewalld and get the Plesk firewall working as expected without too much pain on the way

Here's hoping for some great advice from those that know much more than me

 

[Kaspar]

I don't see how removing firewalld while using DHCP could lock you out of your server. Maybe @manos could elaborate on that a bit more. What I suspect is meant here is that some providers configure a base rule in iptables/nftables to block all traffic and use firewalld to open specific ports, such as port 22 for SSH. When stopping firewalld, all associated rules are purged/flushed, but the base rule remains in place, blocking all traffic. (But I don't see how this relates to DHCP.) It's an unlikely scenario to me, as this is how firewalld (and the Plesk firewall, for that matter) operates in the first place. By default, almost all firewalls use a base rule to block all traffic and then use additional rules to open specific ports (or allow specific traffic).

If you want to circumvent this scenario, you could simply flush nftables directly after stopping firewalld, like so:

sudo systemctl stop firewalld && sudo nft flush ruleset
sudo systemctl disable firewalld

In my experience, however, as someone who mainly uses RHEL derivatives (such as AlmaLinux), stopping and removing firewalld has never caused any issues. If you're still concerned about getting locked out, you might want to check whether your provider offers some sort of (virtual) console to access your server in case you can no longer connect via SSH. That way, you'll always have a way to access your server and restore or change the firewall configuration.

 

[iainh]

1. Yes, I'm using AlmaLinux 9.8 (Olive Jaguar) (mentioned in post header)
2. Yes, I should have (would retest) VNS console access should things go south before I go changing too many things
3. I presume the reference to "ssh dhcp and cokpit" by @manos is a block of all access other than (presumably) 'any' on 22, UDP 67 & 68, and 9090

Certainly the server is static IP and my client is static IP, so as you say, DHCP is otherwise irrelevant other than UDP 67/68 being left open.

You are saying a firewalld stop, ruleset flush, firewalld disable never caused you any issues? You didn't lose Plesk panel access? You didn't lose SSH access? You just disabled and then reapplied the Plesk firewall rules and all worked swimmingly? Or did you do some specific sequence to disable firewalld, then enable the Plesk panel UI, and then applied Plesk rules ... or some other sequence? What precisely have you done that never caused any issues?

Interested in your experience given "stopping and removing firewalld has never caused any issues." That's encouraging. Would just like to ensure I have the same experience

 

[Kaspar]

Usually one of the first thing I do when setting up a new RHEL based server is uninstalling firewalld, before installing Plesk. But even in cases where Plesk has already installed it has never caused me any issues to simply stop and uninstall firewalld. I don't have a specific sequence, as it's a pretty straight forward operation. It never caused me any issue (which doesn't mean that no issues can arise of course). But if I have to make a list of actions, this would probably be it:
1) Disable or uninstall the Plesk firewall,
2) Disable fail2ban
3) Stop firewalld && flush nftable
4) Uninstall firewalld
5) Install and enable Plesk firewall
6) Re-eanble fail2ban

 

[iainh]

I don't see how removing firewalld ... could lock you out of your server. Maybe @manos could elaborate on that a bit more.

I think the issue @manos is referring to is that someone's access to the server may be dependent on firewalld configured rules. As disabling firewalld also results in the removal of rules it has added, disabling could result in someone removing rules on which their own access relies.

I have seen something suggesting you should ensure the Plesk firewall is installed and configured with access for yourself as sysadm, and only after doing that should firewalld be disabled. I'm presuming this is to ensure that Plesk will have suitably configured nftable itself ensuring all the right ports are open, including permitting you sysadm access to your own machine, and so disabling firewalld and the removal of rules added by it won't bring you to a grinding halt.

The other point @manos made was that some hosting providers use firewalld to initially configure the base image and leave it active. This is precisely the issue I have uncovered. Looking through the (extensive) config, I can also see the reason for some of the 'inconsistent results' I am seeing regarding access:

1. Deny/block rules I have added via Plesk to block endless IMAP and POP3 login attempts are in the config and working. The reason is because they provide an explicit IP match with a deny and so things work as expected, however...
2. More concerning is restricted access to 22 and 8443. While I have defined 'Allow from selected sources, deny from others' access via Plesk, what I see in the running config includes ip saddr 1.2.3.4 tcp dport 8443 counter packets 124 bytes 6448 accept (access for me) but no tcp dport 8443 drop to block everyone else. Instead I see under table inet firewalld / filter_IN_plesk_allow, tcp dport 8443 accept ... a global open to all to come have a try. In fact, these sections open a whole list of ports to all. It's a horror story IMHO, made worse by it not being obvious. You configure your firewall via Plesk and expect that to be the running config, but instead behind the scenes and unknown, you have these firewalld added sections leaving the server wide open

The Plesk article Plesk for Linux and firewalld Compatibility is slightly confusing as it says "Using both tools (firewalld and the Plesk Firewall extension) simultaneously can result in conflicts and in ports required for Plesk to operate being closed. We recommend only using one tool at a time." Fine ... hence we get to disabling firewalld, however, the article also says "Plesk can only configure firewalld version 0.4 or later ... and ... Plesk can only configure firewalld during Plesk installation. When you upgrade Plesk, the firewalld configuration does not change.", i.e. Plesk is actually making use of firewalld and configuring access via it ... it's an agent of Plesk, not an antagonist, so should it be disabled?

You kindly mention "In my experience, however, as someone who mainly uses RHEL derivatives (such as AlmaLinux), stopping and removing firewalld has never caused any issues." Does this experience come from first configuring the Plesk firewall and only then disabling firewalld? I'm keen to get a safe means to get rid of these dreadful 'open to all' blocks in the nftable config and that probably means disabling firewalld, but I don't just want to jump in and disable firewalld only to have some horrendous unintended impact. I probably won't, but I'd like to be a little more sure before pushing the big red button on firewalld

 

[iainh]

Okay, so for anyone else wandering into this post with the same issue of firewallld and Plesk firewalls running together, these are the precise steps I took to safely disable firewallld and (so far ) not lock myself out of my server. The steps are detailed as a pet hate is people that say:"Oh, you just need to do 'this'", when, if I knew how to do whatever they refer to, it's unlikely I'd be reading the post in the first place.

So, this post is designed for any other poor soul who would like to extracate themselves from the problem I found myself with, namely that the hosting provider had configured access via firewallld and left this running. I then came along, enabled and configured the Plesk firewall and believed I had everything nicely locked down, only to find all manner of unwanted probes of management services going on due to conflicts with what firewallld was doing.

As an example, I had restricted SSH and panel access and can see the following in the table ip filter { chain INPUT } ... an early chain to be evaluated:

ip saddr 1.2.3.4 tcp dport 22 counter packets 4 bytes 208 accept
tcp dport 22 counter packets 2244 bytes 132968 drop

... yet I discovered all manner of Chinese and other IPs having a go at both 22 and 8443. firewallld did have some 'wonderful' (not!) 'open to anyone' rules, although these were in a later evaluated chain and so I'd not have expected these to be meaningful, however, somewhere along the lines, these IPs were escaping the global drop and probing away unwanted.

Working through quite how these IPs escaped the drop would have been a long job, but the key takeaway is if your also have firewallld or equivalent working away unknown to you in the background, what you get from your firewall may well not be what you think. This was my lesson: access was not as per the Plesk config due to this 'interference' from firewallld.

The solution was to rid myself of this unknown, unwanted firewallld config, leaving me with a clean Plesk (and fail2ban) config with no conflicts. My steps to achieve this were:

1. Configure and activate the Plesk firewall with appropriate access rules. I found myself in this 'dual running' state by accident, but by configuring the Plesk firewall, even though you have competing management tasks, Plesk should have inserted your access and so you reduce the chance of locking yourself out of the box when you disable firewallld
   
   
2. Sort console access to the server. My hosting provider provides VNC console access, so I made sure I had that configured, working and I had a logged in open and working before starting any changes
   
   
3. Test the at function which will be used to setup a fail-safe rollback. at allows a task to run at a time or after a set interval and so can auto-execute a change un-do if you were to lose access
   1. echo "echo 'The at daemon is working' >> /tmp/at_test.txt" | at now + 1 minutes
   2. After 1 minute: cat /tmp/at_test.txt
   3. Hopefully see: "The at daemon is working"
   4. If you lack at, you'll need to install it to set this roll-back safety net
      
      
4. Setup the automated change roll-back (adjust the delay as you wish, but leave yourself enough time to make and verify the changes before the roll-back auto-runs!):
   echo 'systemctl start firewalld && systemctl restart plesk-firewall' | at now + 10 minutes
   You will want to note the job number at gives back. It will be something like:
   job 5 at Wed Jul 1 15:24:00 2026
   You can all find this using the atq command. You'll want to to cancel (remove) the roll-back presuming everything goes as planned
   
   
5. Stop firewalld and restart the Plesk firewall to rewrite rules (do not disable firewallld yet else the rollback will fail):
   systemctl stop firewalld && systemctl restart plesk-firewall
   The Plesk firewall restart is to get it to take control of the firewall/nftables config
   
   
6. Check firewalld runtime status:
   systemctl status firewalld
   You want to see it is stopped
   
   
7. Check active firewall tables to ensure firewalld rules have gone:
   nft list tables
   You should see a clean set of tables rather than the contorted mess I saw with firewallld inserted tables:
   

   # nft list tables
   table ip filter
   table ip mangle
   table ip nat
   table ip6 filter
   table ip6 mangle
   table ip6 nat

   
   
8. Go into the Plesk UI and reapply the rules to sync the clean environment (Tools & Settings > Firewall). Make some change and apply the change to force a refresh by Plesk
   
   
9. Restart fail2ban:
   systemctl restart fail2ban
   
   
10. Check fail2ban internal status:
    fail2ban-client status
    
    
11. Check if fail2ban rules are visible in legacy iptables:
    iptables -L -n -v | grep -E "Chain f2b|Chain fail2ban"
    
    
12. Now, I had some issues with the restart of fail2ban and so I went into the Plesk UI where they all showed as 'Active'. But looking in Settings (Tools & Settings > IP Address Banning (Fail2Ban) > Settings) I had to recheck 'Enable intrusion detection' which was off. But doing this and re-enabling the various jails had fail2ban back in action
    
    
13. Check port 22 and 8443 access via a new sessions and ensure you're happy all is working (and do not close your VNC session yet)
    
    
14. If happy all is working, cancel the roll-back:
    atrm [task_number-from-step-4]
    
    
15. Disable firewalld permanently so it does not start on reboot:
    systemctl disable firewalld
    
    
16. Eyeball the final active ruleset to confirm a clean environment:
    nft list ruleset
    Look at your new clean ruleset which should look a whole lot more likely you'd expect from the Plesk setup you believed was working
    
    
17. Close your VNC session, sigh a huge sigh of relief, and retired to a beer!

And you should be done.