Issue Docker containers unable to resolve DNS or access external network on Plesk Obsidian 18.0.76 Update #4 (Collabora / Nextcloud issue)

[first4it]

Server operating system version

AlmaLinux 9.7 (Moss Jungle Cat)

Plesk version and microupdate number

18.0.76 Update #4

I am raising this as a potential infrastructure-level issue affecting Docker networking on Plesk, rather than an application-specific problem.

Environment:

• Plesk Obsidian 18.0.76 Update #4
• Docker Engine 29.3.1
• AlmaLinux (Plesk managed server)
• Dedicated server (not shared hosting)
• Nextcloud installed via Plesk
• Collabora Online (collabora/code) deployed via Docker
• Separate subdomains:
  • Nextcloud: files.example.com
  • Collabora: collabora.example.com

Issue:

Nextcloud Office integration fails when opening .doc / .docx files.

The error shown in Nextcloud:

“Failed to establish socket connection or socket connection closed unexpectedly”

Collabora logs show:

• Failed to lookup host
• Temporary failure in name resolution
• Failed to connect to Nextcloud host on port 443

Observed behaviour:

• Collabora /hosting/discovery endpoint works correctly
• WebSocket connection (/cool/.../ws) upgrades successfully (101)
• Reverse proxy configuration is correct
• SSL termination via Plesk works correctly

However:

• DNS resolution inside Docker containers fails
• External HTTP requests from containers fail
• Containers cannot reach public internet resources

Diagnostics performed:

From inside the Collabora container:

• getent hosts <nextcloud-domain> hangs
• DNS resolution fails
• WOPI calls fail due to hostname lookup

From test containers:

• docker run alpine ping 8.8.8.8 → fails
• docker run alpine wget Example Domain → hangs
• Alpine package install fails due to unreachable repositories

From host:

• DNS resolution works correctly
• HTTPS access to Nextcloud works
• Docker NAT and forwarding appear correctly configured
• ip_forward = 1
• MASQUERADE rule present for 172.17.0.0/16

Firewall checks:

• Plesk Firewall forwarding policy tested (Allow) → no change
• DOCKER-USER ACCEPT rule tested → no change

Conclusion from testing:

Docker bridge networking on this host cannot reliably:

• resolve DNS
• reach external HTTP services

This causes Collabora to fail WOPI communication with Nextcloud.

This is not a misconfiguration of:

• Nextcloud
• Collabora
• Reverse proxy
• SSL

Workaround:

Running Collabora in host network mode resolves the issue completely:

docker run --network host ...

Result:

• DNS works
• WOPI works
• Documents open correctly

Concern:

This should not be required.

Docker containers should be able to:

• resolve external DNS
• access outbound HTTP/HTTPS

without requiring host networking.

Using host mode:

• bypasses Docker networking entirely
• is not ideal for isolation or portability
• is not manageable via the Plesk Docker UI

Questions:

1. Is this a known issue with Docker networking on recent Plesk versions?
2. Is there a known interaction between Plesk firewall / nftables / Docker bridge networking that could cause this?
3. Are additional routing or firewall adjustments required on Plesk-managed servers for Docker containers to access external DNS?
4. Is this related to provider network topology (e.g. routed gateways like 10.x.x.x) and how Docker NAT behaves in that scenario?

Expectation:

A standard Plesk + Docker setup should allow containers to:

• resolve DNS
• access external services

without requiring host network mode.

Summary:

• Issue affects Docker networking layer
• Breaks Collabora / Nextcloud Office
• Reproducible with simple test containers
• Workaround exists but is not ideal

If anyone has experienced similar behaviour or has a recommended fix that restores normal Docker bridge networking, I would appreciate their input.

 

[scsa20]

So what you didn't provide is how you have the containers set up. Are you deploying them through a stack or each container set up on their own? You using the NextCloud AIO? If each container was set up separately, are they all part of the default docker network or did you made a dedicated docker network for those 2 containers?

Technically speaking the Plesk Firewall should respect entries entered in by Docker but it can still be iffy, especially if you there's another firewall that's changing the IPTables.

With that said, if you are using the default docker network, make a dedicated docker network and put the 2 containers on that network, that should help a bit. Disable the firewall and test as well as a way to do another test.

Also, if you have any external networks using the same subnet that is being used by the docker network (through NAT) then you'll have issues.

Also, I randomly decided to throw your whole message into grok and it has some suggestions for you as well: Plesk Firewall Breaks Docker Outbound Connectivity | Shared Grok Conversation

 

[first4it]

So what you didn't provide is how you have the containers set up. Are you deploying them through a stack or each container set up on their own? You using the NextCloud AIO? If each container was set up separately, are they all part of the default docker network or did you made a dedicated docker network for those 2 containers?

Technically speaking the Plesk Firewall should respect entries entered in by Docker but it can still be iffy, especially if you there's another firewall that's changing the IPTables.

With that said, if you are using the default docker network, make a dedicated docker network and put the 2 containers on that network, that should help a bit. Disable the firewall and test as well as a way to do another test.

Also, if you have any external networks using the same subnet that is being used by the docker network (through NAT) then you'll have issues.

Also, I randomly decided to throw your whole message into grok and it has some suggestions for you as well: Plesk Firewall Breaks Docker Outbound Connectivity | Shared Grok Conversation

To answer the specific points you have raised.

The installation is very simple. NextCloud was installed manually on a domain within Plesk, not using the NextCloud extension. The docker extension was installed and this was used to create a single Collabora container - there is no network. I have progressed your Grok conversation but it has resulted in recommendations for some radical changes including flushing iptables and nftables and setting up a separate docker network to avoid the default docker bridge. This should not be necessary for a simple setup as this via Plesk.

It would appear the problem is clearly the FORWARD chain configuration caused by the Plesk + Docker interaction on this configuration. I will post the output of the Grok response here:

Root Cause

This is a recurring rule-order conflict between the Plesk Firewall extension and Docker's iptables management on AlmaLinux with Plesk Obsidian 18.0.76 Update #4 + Docker Engine 29.3.1.

Specifically:

• Docker sets the FORWARD chain policy to DROP (as clearly visible in your iptables -L FORWARD output: "Chain FORWARD (policy DROP)").
• Docker adds its own chains/rules (DOCKER-USER → DOCKER-FORWARD → DOCKER, plus the MASQUERADE in nat table for 172.17.0.0/16).
• The Plesk Firewall extension also manages the FORWARD chain and places restrictive rules (REJECT for new TCP without SYN, DROP for INVALID, and the overall policy DROP) in a way that Docker's outbound ACCEPT rules for containers (from docker0 bridge) end up after the blocking rules.
• Even when you set "System policy for traffic forwarding = Allow" in Plesk, or added -I DOCKER-USER -j ACCEPT, or disabled firewalld, the rules are re-applied or ordered such that outbound packets from containers (ping to 8.8.8.8, TCP to files.example.com:443 for WOPI, DNS queries, etc.) hit DROP/REJECT before they can be accepted.

This is the same underlying issue as the well-documented EXTPLESK-8001 bug that appeared after Plesk 18.0.67 (where Docker started appending its ACCEPT rules after Plesk's DROP). It was supposed to be fixed in later patches and Docker 28.0.1+, but it has resurfaced (or persists in a slightly different form) with Docker 29.x on AlmaLinux in this specific Plesk micro-update.

Your diagnostics perfectly match:

• Host networking works (bypasses the entire Docker bridge + FORWARD chain).
• MASQUERADE and ip_forward=1 are present and correct.
• DNS resolution + external HTTP from containers fail (classic symptom of FORWARD blocking).
• firewalld disabled didn't fully resolve it (because Plesk Firewall + Docker's nftables/iptables compatibility layer still conflicts).
• The broad DOCKER-USER ACCEPT didn't stick reliably due to rule re-application order.

This is not a misconfiguration in Nextcloud, Collabora, your reverse proxy, SSL, or provider routing. It is a low-level Docker networking + Plesk Firewall interaction on this exact version combination.