Issue Persistent iptables DROP Rule for Docker Container IP 172.17.0.2

[Phantasia]

Server operating system version

Ubuntu 22.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian v18.0.70_build1800250617.10 os_Ubuntu 22.04

Hello everyone,

I’m running Plesk Obsidian 18.0.70 on Ubuntu 22.04 and have recently started using Docker (e.g. to host Open WebUI).

Since then, I’ve noticed that a DROP rule against 172.17.0.2 (the Docker bridge IP) keeps getting automatically reinserted into the iptables INPUT chain – likely every 60 seconds or so:

DROP all -- 172.17.0.2  0.0.0.0/0

This completely blocks external access to the container, even though it is behind a reverse proxy and should be reachable via HTTPS.

After some investigation, I traced the rule back to this script:

/opt/psa/var/modules/firewall/firewall-active.sh

As a temporary workaround, I’ve created a cronjob that deletes the rule every minute – but the real issue persists in the background.

Important notes:
- I’ve created allow-rules for 172.17.0.2 via the Plesk Firewall GUI several times. They seem to have no effect.
- I’m on Docker 28.2.2, build e6534b4, so I’m well beyond the version where the known issue was supposedly fixed (see: this thread).

So my questions:

• Was the Docker fix in 28.0.1 only temporary or incomplete?
• Or is this an issue with Plesk Firewall rewriting rules incorrectly?
• Is there a proper (update-safe) way to allow internal Docker traffic via 172.17.x.x?

Any help or insight would be greatly appreciated!

 

[scsa20]

This is a docker thing not a Plesk thing. You would want to expose a port that is map to a port in the container itself then create the proxy to said exposed port of the container.

For example, let's say you are running a container which has it's own web server running on port 80. Since port 80 is used by Plesk you would need to expose a different port that is map to port 80. Here's a screen shot of how one of mine is set up as:
In this example I have port 90 exposed to the host that is mapped to port 80 of the container. This will then allows me to create a docker proxy on my domain to proxy it to said container (you could also just add a custom nginix directive to do the proxying as well like I did with another container).

Hope this explains it.

 

[Phantasia]

Hi @scsa20,

thank you for your reply and for sharing the screenshot.

Let me clarify: The port mapping (e.g. 8080:4323) and the Reverse Proxy via domain are both correctly configured — please see the attached screenshots below.




The actual issue is not the port mapping or the proxy setup.
Instead, it's a recurring DROP rule in iptables that is automatically set against the Docker container's internal IP (e.g. 172.17.0.2).

---

What we've observed:

- A DROP rule is re-added frequently (possibly every few seconds) without manual intervention.
- This happens even after we delete the rule manually.
- We do not believe Docker would drop its own container IPs — that would make little sense.
- The rule is found in the firewall-active.sh script, which is automatically generated by Plesk.

Here’s the critical line:

apply_rule /usr/sbin/iptables -A INPUT -j DROP

And there is no ACCEPT rule for the Docker subnet (e.g. 172.17.0.0/16) before this.

We also tried adding such an ACCEPT rule manually using iptables — but it gets removed automatically, even though the Plesk GUI doesn’t allow setting such a rule directly.

---

Our conclusion:

Based on the script content and all test results, it's very likely that the Plesk Firewall module is applying this DROP rule — possibly triggered by a system process, not manually.
We do not have evidence that Docker itself is doing this.

---

What we’re hoping for:

• Is this behavior known or intended?
• Is there a supported way to allow Docker internal subnets like 172.17.0.0/16 permanently?
• Can we configure the Firewall in a way that won't override such rules on its own?

Thanks again — happy to share more data if needed.

 

[Phantasia]

Addition:
The problem is not just that a DROP rule exists — that's understandable.
The real issue is that any manually added ACCEPT rule (e.g. for 172.17.0.0/16)
is automatically removed again, and the Plesk GUI offers no way to make such an exception persistent.
This makes it impossible to whitelist Docker traffic reliably.