Mac sharing shows up over the VPN: stop it or hide it?

Browse lists are built from announcements, and an announcement is not an access grant. Somebody sees your laptop's name in a remote list because a multicast query crossed a boundary that normally stops it at the router. That crossing explains both why the entry appears and why removing the entry is not the same as closing the service. Work out which of the two you actually object to before changing anything.

What the browse entry really is

An mDNS responder on the Mac answers queries for the service types it hosts, and the answer carries a name, a port and a few text records. The client that asked then shows that name in a list. Nothing in the exchange proves that a connection would succeed, and nothing in it grants permission: the list is a claim about a name, not about access. That distinction is what decides whether you should turn something off or stop publishing it.

Different services register separately, so one entry disappearing does not mean every announcement stopped. File sharing registers one type, screen sharing another, and printers, media libraries and developer tools each register their own. Before treating a single switch as the master control, list what is registered and which process owns it:

dns-sd -B _smb._tcp
lsof -nP -iUDP:5353

Multicast stays local unless something bridges it

Multicast DNS sends to a link-local group on UDP 5353, and routers do not forward that group by default. A tunnel that routes unicast traffic therefore leaves discovery behind, which is why a Mac on a routed VPN is usually invisible to the remote site. A bridged tunnel, or a relay configured on purpose, changes that by putting both ends in one broadcast domain. Which design you have is a property of the tunnel, not of the protocol name printed on it.

Inspect the server configuration to see whether it bridges an interface or routes a subnet, because the two behave differently for every broadcast-dependent protocol. If the tunnel is bridged, expect more than one kind of announcement to leak, including things nobody intended to publish. If it is routed, an entry in a remote list probably arrived through a relay or through unicast DNS-based discovery rather than through the multicast group. Those paths have different fixes, and blocking the multicast port closes only one of them.

Stopping the service is the cleanest boundary

If the Mac has no business serving files, turn sharing off through its supported control instead of trying to hide its announcement. A stopped service cannot be connected to, guessed at or reached by an old client that remembered the name. That property makes it the stronger control, and it needs no network cooperation at all.

Apple's file-sharing guide describes the permission model for shared folders, permitted users and guest access, and the sharing pane shows the current state. Review those three when the service is genuinely needed, because a share that must exist is a share that has to be scoped. Guest access deserves its own look, since it can allow a connection with no credentials at all. Then confirm which interfaces the service listens on, because a share offered on every interface is offered on the tunnel too.

When you need the service but not the audience

Sometimes the share is legitimate and the audience is not. Restricting the service to approved sources, with discovery left as a separate and lesser control, is the honest arrangement. Firewall rules, per-user permissions and listening on the right interface all narrow access in ways a hidden announcement cannot.

Suppressing discovery is cosmetic in the strict sense: the service still answers anyone who knows the name. If publication itself is the problem, limit it at the layer that carries it. On a network you administer, that means deciding which service types should cross the boundary and configuring the bridge, relay or filter to match. Copying a bridge-filter command from a forum works only if your server runs that stack and that tunnel mode, and on a network you do not administer the honest answer is that you cannot control what a remote client remembers.

Look at it from the remote side

Test from the remote side rather than from the Mac's own network, and test a fresh browse rather than a cached list. Then attempt a direct connection to the service by name and by address, because the two results answer different questions. A missing entry with a successful connection means you hid a label, while a failed connection means you closed a service. Caches make both tests lie if you skip the refresh, so start the client fresh.

Write down what you changed and which of the three controls it belongs to: service stopped, access restricted, or discovery limited. When somebody reports that the Mac still appears, that record tells you whether the report is stale or whether another service is announcing itself. Most surprises here are a second registration nobody remembered enabling, not a broken control.

Re-check the remaining registrations before concluding the change failed. A short inventory list beats another round of guessing.