Community Solution

Why ZimaOS Opens Router Ports: Audit UPnP and Docker

A ZimaOS user found unexpected router port mappings and later traced the behavior to UPnP being enabled on the home router.

Bottom Line: First Distinguish a Local Listening Port From a Router WAN Port Mapping

The 2025 case was resolved by disabling UPnP on the router. That tells us the suspicious entries were automatic NAT mappings at the router, not simply “random ports listening inside ZimaOS.” Those are different security surfaces. A NAS can legitimately listen on many LAN ports without any of them being exposed to the public internet.

Check What ZimaOS Is Actually Listening On

ss -lntup
docker ps --format 'table {.Names}	{.Ports}'

The first command shows host listeners. The Docker output shows which container ports are published onto the host. If a port exists here but not in the router's WAN/UPnP table, it is not automatically a public internet exposure.

The ZimaOS app ports helps explain why each installed service adds its own listeners.

Then Check the Router's UPnP Port-Mapping Table

UPnP IGD lets a device or application on the LAN request a NAT mapping automatically. If the router allows it, a service can create an external port without a manual port-forward rule. The 2025 user disabled router UPnP and the automatic openings stopped.

The IETF's UPnP port mappings discusses UPnP IGD port mappings and their security considerations.

Current Built-In ZimaOS Remote Access Does Not Need Manual Port Forwarding

Current ZimaOS remote access creates an encrypted peer-to-peer/relay path and explicitly says router port forwarding is not required. That means you should not enable UPnP merely because you want the normal ZimaClient remote-access experience.

The ZimaOS remote access defines the current built-in path.

Some Self-Hosted Apps Still Need Explicit Internet Exposure

WireGuard servers, game servers and other inbound services can require a reachable UDP/TCP port. In those cases, a deliberate manual forward is easier to audit than allowing every LAN application to request arbitrary UPnP mappings. Document the service, internal host, internal port, external port and whether authentication/TLS protects it.

The Tailscale remote access offers an alternative for many administrative use cases.

Disable UPnP if You Want Every Public Mapping to Be Explicit

Turning off UPnP at the router is a reasonable security policy when you are comfortable creating the few port forwards you actually need. After disabling it, reboot or clear stale mappings, then scan your public IP from outside the LAN to verify the result. Do not test public exposure from inside only, because NAT loopback behavior can mislead you.

Use an External Scan to Verify WAN Exposure

From a device outside your home network, test the specific public ports you believe are open. Nmap's Nmap port states explains why a router UI entry and a reachable internet service are not always the same thing.

Do Not Close Ports Blindly on the ZimaOS Host

Blocking an unfamiliar port without identifying its process can break Files, SMB, app web interfaces, discovery or remote access. Map the port to a process/container first, decide whether the service is needed, then stop/unpublish that service if appropriate.

The ZimaOS HTTPS proxying is useful when several web applications need a single auditable ingress layer.

A Simple Port-Audit Workflow

  1. Export or screenshot the router's manual and UPnP mappings.
  2. Run ss -lntup on ZimaOS.
  3. Run docker ps and map listeners to apps.
  4. Disable UPnP if automatic WAN mappings are not desired.
  5. Retest from outside the LAN.
  6. Keep only documented exposure that has a clear owner and purpose.

FAQ

Why does my router show ZimaOS opening ports?

If the entries are in the UPnP table, an application or service may be requesting automatic NAT mappings. Identify the process before assuming all ZimaOS listeners are public.

Does disabling UPnP break ZimaClient remote access?

Current ZimaOS documentation says built-in remote access does not require manual port forwarding, so normal ZimaClient remote access should not depend on UPnP for that purpose.

Are Docker published ports exposed to the internet?

They are exposed on host interfaces according to Docker binding, but WAN reachability still depends on routing, firewall and NAT configuration.

Should I close every unknown port?

No. First identify the owning process or container. Closing infrastructure ports blindly can break legitimate NAS functions.

Is manual port forwarding safer than UPnP?

It is easier to audit because each mapping is intentional and documented. Security still depends on the exposed service, authentication, patching and firewall rules.