• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx

  • We are developing a new feature in Plesk that will help you promote your websites or business on social media. We want to conduct a one-hour online UX test to present the prototype and collect feedback. If you are interested in the feature, please book a meeting via this link.
    Thank you in advance!
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue plesk firewall 2.1.5-412 still has problems

PeterKi

Regular Pleskian
Server operating system version
Ubuntu 22.04.3 on strato vServer
Plesk version and microupdate number
Plesk Obsidian Web Admin Edition Version 18.0.54 Update #4
I still have problems with the new plesk firewall.
After I set the timeouts in panel.ini to 120s I was able to activate the firewall and iptables -L did show all the rules.
Then I tried to block two IP ranges by adding a block-all rule to deny all incoming ports for 218.92.0.0/24 and 61.177.172.0/24.
With the old firewall, it was very easy to do this.
When I tried to activate my new rule, the firewall came back with the following error:

Failed to apply the firewall configuration.
  • I did not receive connectivity confirmation after applying new firewall configuration, then same happened after I reverted to previous configuration. This means that both new and previous configurations were bad. Emergency rollback to configuration without rules was performed. Firewall is now disabled. Fix your rules and try again.
After I had removed the block-all rule, I was able to activate the firewall again.
The new firewall is much worse than the old one.
It is slower, the rule management is worse, and it does not work as properly as before.
 
If the rule was faulty, then the rule applet is faulty.
I entered the rule as shown on the attached screenshot, and I do not see anything wrong with it as it follows the given examples.
Also, the original error message said, that it could not revert to the previous configuration, claiming it was bad too.
This obviously was a false message, because the previous configuration did work.
I tried to enter the blocking rule a second time, but this time the "applying firewall configuration" did not come back even after 10 minuters and I was totally locked out of my server.
The only solution was to revert to a server backup to get it accessible again.
 

Attachments

  • 2023-10-09 10_06_03-Firewall - Plesk Obsidian 18.0.54 — Mozilla Firefox.jpg
    2023-10-09 10_06_03-Firewall - Plesk Obsidian 18.0.54 — Mozilla Firefox.jpg
    65.6 KB · Views: 20
Please address this to the support team by a ticket. They will be able to help you solve it directly on your server.
 
Still something funky going on with the firewall extension.

We use ansible to deploy Plesk servers and the firewall application fails on some installs. The same ansible playbook applied in each case, and whilst on most servers it installs everything fine, on some it times out with
Failed to apply the firewall configuration.
  • I did not receive connectivity confirmation after applying new firewall configuration, then same happened after I reverted to previous configuration. This means that both new and previous configurations were bad. Emergency rollback to configuration without rules was performed. Firewall is now disabled. Fix your rules and try again
The same playbook and OS in all cases is the same image of AlmaLinux8.
This extension needs to be investigated further as it is not stable.

Dave_W
 
Please address this to the support team by a ticket. They will be able to help you solve it directly on your server.
I am on a reseller license from Strato and there is no support from Plesk for this.
Is there a way, how I can still address a ticket to the support team?

The previous plesk firewall extension had worked flawlessly for me for many years, but the new extension is a major fail.
 
@PeterKi before applying the new Firewall rule changes Plesk shows a dialog which allows you to preview the script which gets used to apply all firewall changed. Could you post the script here for a quick analyses?

Schermafbeelding 2023-10-10 om 11.19.16.png
 
Still something funky going on with the firewall extension.

We use ansible to deploy Plesk servers and the firewall application fails on some installs. The same ansible playbook applied in each case, and whilst on most servers it installs everything fine, on some it times out with
Failed to apply the firewall configuration.
  • I did not receive connectivity confirmation after applying new firewall configuration, then same happened after I reverted to previous configuration. This means that both new and previous configurations were bad. Emergency rollback to configuration without rules was performed. Firewall is now disabled. Fix your rules and try again
The same playbook and OS in all cases is the same image of AlmaLinux8.
This extension needs to be investigated further as it is not stable.

Dave_W
Out of curiosity, does the error persist when tried again on the same server? Or is it a one time error?
 
I currently have an open support call with Plesk support.
So far they have confirmed that for some reason it appears that adding any rule clears the firewall chains, and the server becomes unreachable.
It happened to them too, when I gave access to my server and I had to restore it again to yesterday's backup, which for me is the fastest way to
They are still investigating the issue.
 
Out of curiosity, does the error persist when tried again on the same server? Or is it a one time error?
Hey Kasper,

Ive stopped paying attention to it to be honest because Ive had numerous tickets open on it, and once support see that they can apply rules they call it resolved and with the increase in Plesk pricing I don't see why we should beta test for them.

From memory its intermittent, on a run of say 5 new containers running the same ansible playbook, 1 might fail. Then in a run of changing the firewall a different one in five would fail.

This is with the timeouts changed in panel.ini before changes to the firewall are made which if these are a requirement for the firewall to work then should be the default timeouts set by Plesk but I dont think its a timeout issue.

I just manually fix and move on, Ive pretty much given up on opening tickets on the issue.

Dave_W
 
I have the exact same issue as @PeterKi mentions and I'm also on a Strato server (yet!).
I set both timeouts already to 240 because running the firewall-new.sh script manually already took 2:40. Nevertheless firewall i disabled, can't be enabled, breaks with the "emergency.sh timeout after 5s" and knocks me out of my server, so only a reboot works.

Anyone having a working and persistent firewall solution running that works with fail2ban and docker, but without this extension?

BTW: I noticed in the changelog for 2.1.3:
Added support for using the --apply and --enable commands without the --confirm command in automated deployment scenarios. (EXTPLESK-4831)

How does that work? There's no further information in this. I also provision with ansible (except the firewall because it isn't working).
 
When you configure the Plesk firewall on the Linux console, please make sure that you use a different SSH session for confirming the new configuration than for appyling it.
 
The "emergency.sh" keyword caught my attention. I think it is a known issue PPS-14933, but not an issue with Plesk actually. Your hosting provider should resolve the iptables timing issue in order for iptables-related scripts to work properly.

As a workaround, please increase the timeout settings in panel.ini drastically, e.g.

[ext-firewall]
confirmTimeout = 660
confirmTimeoutCli = 660
 
The support did analyze my server and found that a timeout of 150 solves the problem.
They stated that the strato vServer seems to be the problem as it reacts very slow on the iptables scripts.
During the investigation Pleask supporters also locked out themselves several times.

Nevertheless, I think, that it must never happen that a firewall update leaves a server in an inaccessible state.
If there is a timeout, it must under all circumstance keep the server accessible and as a last resort flush the firewall rules and disable the firewall.
The too short default timeout is definitively a problem with the new firewall extension.

It is very common to have a blacklist for certain IP ranges and the Plesk firewall should have a special case for that.
Especially with the wars in Ukraine and Gaza I see frequent hacking attempts from Iranian, Russian and Chinese servers.
I have found ipsets (https://ipset.netfilter.org/install.html) which may be a solution as it allows changing a set without clearing and reloading all iptables rules.
Thus, the lock out problem may be avoided.
I encourage Plesk to look into this and possibly add ipsets to a reworked firewall extension.
 
As far as I know, the geo-blocking feature of the new Firewall extension does exactly that.
 
geo-blocking? Where is it?
I do not see this anywhere and a Plesk search for it does not reveal anything.
 
Oh, I see.
But blocking a whole country isn't very helpful.
There are cloud hosters located in UK or NL which host servers from all over the world.
I use the dialog shown in your link to block specific IPs or IP ranges like e.g. 46.148.40.0/24 which currently does a lot of login scanning.
For that I have added a rule to the firewall which I call myBlacklist to which I add the IPs which I want to block.
With any changes to the firewall rules, the current firewall extension clears all rules at first though and then it adds them again one by one.
This is what can take so much time.
In contrast to that, fail2ban for example only manipulates single rules and thus doesn't show the timeout problem.
From my understanding, the ipset tool also only changes a set of rules and doesn't flush all the other rules which are not affected.
Thus, I encourage Plesk developers to look into ipset, so that subset of iptables rules e.g. for blacklisting or whitelisting can be maintained separately from other rules.
 

Attachments

  • 2023-11-03 10_22_01-Firewall - Plesk Obsidian 18.0.56 — Mozilla Firefox.png
    2023-11-03 10_22_01-Firewall - Plesk Obsidian 18.0.56 — Mozilla Firefox.png
    14.2 KB · Views: 4
Back
Top