Synology DSM Firewall Bug Blocks Docker Containers – How to Fix It

Synology NAS systems are fantastic for running Docker containers, but sometimes bugs and hidden limitations make things frustrating. Recently, a user struggled for days to get Documenso (self-hosted document signing) running on their Synology NAS. Containers installed fine, but they refused to talk to each other.

Along the way, the same user also hit issues with email security (lack of 2FA) and ISP restrictions with CGNAT. This case study walks through the problems and the fixes, which may save you hours of troubleshooting.

Problem 1: Docker Containers Couldn’t Communicate

Symptoms:

• Installed multiple Docker containers (e.g., Documenso and its database).

• Containers launched successfully, but the app couldn’t see the database.

• A test stack using Alpine images (service-a pinging service-b) resulted in 100% packet loss.

Diagnosis:

• When the DSM firewall was disabled, everything worked.

• When the DSM firewall was enabled, even with allow rules, traffic failed.

• This confirmed a DSM firewall bug blocking Docker bridge traffic.

Fix: Allow Docker Bridge Subnet

Find the subnet used by Docker:

In DSM Firewall rules:

• Source: 172.17.0.0/16 (or whatever your bridge subnet is)

• Destination: All

• Ports: All

• Action: Allow

• Move this rule above any deny rules.

Alternative Fixes

1. Custom Bridge Network
   Define your own subnet in docker-compose.yml:

   networks:
my_custom_net:
driver: bridge
ipam:
config:
- subnet: 172.30.0.0/16


   Then whitelist 172.30.0.0/16 in the firewall.

2. Host Mode
   Run containers with:

   network_mode: host


   This bypasses the firewall bug, but reduces isolation.

3. Disable DSM Firewall
   Last resort. If disabled, use:

   • Router firewall rules

   • Reverse proxy with SSL (DSM Application Portal)

   • VPN (Tailscale, ZeroTier, WireGuard)

Problem 2: ISP Blocks Port Forwarding (CGNAT)

Another roadblock: The ISP was using CGNAT and only enabled port forwarding if you upgraded to a premium 2.5Gbps package.

Fix: A Cloudflare Tunnel was used instead. This gave secure remote access without opening router ports. It works even if you don’t fully understand the networking details — set it up, and it just works.

Problem 3: Email Provider Without 2FA

The user’s email provider didn’t offer 2FA for SMTP logins. This was a big security concern since Documenso relies on email delivery.

Fix: Support suggested editing one line in the app’s environment config:

This enabled secure SMTP communication and fixed the issue.

Lesson: If your provider doesn’t support modern email security, either adjust the config where possible or move to a provider like Gmail, Outlook, or Proton that offers proper 2FA.

Lessons Learned

1. DSM Firewall has a bug that blocks Docker bridge networking. Fix it by whitelisting the subnet or using custom networks.

2. CGNAT breaks port forwarding. If your ISP uses it, consider Cloudflare Tunnels, Tailscale, or a VPN.

3. SMTP security matters. If your provider doesn’t support 2FA, use secure connection flags (NEXT_PRIVATE_SMTP_SECURE=true) or migrate to a better provider.

4. Different tests give different results. Tools like Blackmagic Disk Speed Test, AJA System Test, or even manual copies all show different performance values. Always test with realistic workloads.

Conclusion

This case is a reminder that running self-hosted apps on Synology NAS isn’t always plug-and-play. But with patience and a few workarounds, you can overcome DSM firewall bugs, ISP limitations, and provider gaps.

If you run into Docker networking failures, don’t waste days debugging your stack — check the DSM firewall first.

Where to Buy a Product
			VISIT RETAILER ➤
			VISIT RETAILER ➤
			VISIT RETAILER ➤
			VISIT RETAILER ➤

☕ WE LOVE COFFEE ☕

Or support us by using our affiliate links on Amazon UK and Amazon US