Meshnet, Docker, and the Permission in Between

Two URLs can look identical from a peer's browser and mean very different things to the firewall. One points at a service listening on the host itself. The other points at a host address whose port is published into a container network, where a translation step hands the connection to a different IP. On a peer-to-peer mesh that gates local-network access with a per-peer permission, that difference is the whole review.

The permission is about the host endpoint, the translation is about Docker, and the login is about the application. Three decisions, three places to look.

Follow the destination after publication

Take a Linux Docker host publishing a container's port 80 on host port 8080. A peer connects to the host's mesh address on 8080, the host accepts the connection, and a destination translation rewrites it toward the container's bridge address, typically something like 172.17.0.2 on port 80.

By the time a rule inspects that flow, the interesting destination is the container, not the host. A policy that reasons only about "a service on this machine" is reasoning about the wrong object. The request landed on the host, but it is being delivered somewhere else.

That is why the mesh documentation lists Docker containers among the resources that local-network permission governs on Linux. The permission is not a synonym for an ordinary VPN allowlist entry, and the two controls do not substitute for each other. One decides whether a peer may reach local resources at all; the other decides which destinations a tunneled route carries.

Decide how much local access a permission grants

Granting local-network access to a peer is not a single-container decision. It can expose other published services on the same host, and it may reach further depending on how the host forwards. Review the effective scope before clicking the switch for one dashboard.

Then look at where Docker publishes the port. A publication on 0.0.0.0 creates a listener on every host address, which can add an ordinary LAN entry alongside the mesh one. If the requirement is mesh-only, bind the publication to the specific address or interface you intend, and treat the wider binding as a separate finding rather than a convenience.

Keep the host forwarding policy and the application's own authentication narrow enough for the service. A private-looking URL is not an access control, and a container that trusts every source on its bridge network is not protected by the fact that the mesh peer was approved. The application's authentication is the third decision, and it is the only one that knows who the user is. A host-level permission cannot supply that knowledge.

Test the permission, not just the URL

From the approved peer, open the exact service and confirm it works. Then try a destination that should remain denied and confirm it does not. Testing only the happy path tells you the permission was granted; it does not tell you the boundary is where you think it is.

Compare a host-native service separately. If a database listens on the host and a dashboard runs in a container, they follow different paths through the same permission and may not be governed identically by the host's forwarding policy. Record which is which before writing the review note.

Do not flush Docker's tables or the mesh client's rules to "reset" access. Both products install their own policy integration, and clearing it produces a host that appears to work while bypassing the controls you were asked to evaluate. If a rule looks wrong, read it and change that one rule. If you cannot explain what a rule does, that is the finding, not a reason to delete it.

Write the finding in the system's own terms

What matters is the distinction the product actually enforces, not the one in the review template: permission to reach a host endpoint, permission to reach routed private resources, and permission to use the application. Publishing a port leaves those three decisions exactly where they were, and a reviewer who treats them as one will approve the wrong scope.

State the host address, the published port, the container destination, and the peer permission in the same sentence. That sentence is testable by someone else, which is what makes it a finding rather than an opinion.