Nextcloud VPN-only access: inventory every entrance first

A VPN-only Nextcloud plan fails when it protects the browser and forgets the sync client. The web page, the desktop sync engine, mobile uploads, WebDAV tools and shared-link recipients all need a path to the same service, and each one can expose a different entrance. Inventory them before closing anything. That list is the real perimeter.

Work the checklist in order. The first item defines what private means for this deployment; the later items test whether the deployment actually matches that definition.

Define private before changing the perimeter

Write down the requirement in one sentence: every user must join the VPN before reaching the application, or the application may remain public while its origin stays private. Those are different designs, and a public reverse proxy that forwards into a private tunnel satisfies only the second.

A private backend address does not make the application private. If a public mapping, a second hostname or an IPv6 listener still reaches the same Nextcloud instance, the entrance exists regardless of where the backend sits. Test each name from outside before declaring the service private. A missing DNS record is not the same as a closed port.

Agree on the intended audience as well: employees, a household, a partner organization or a subset of accounts. The answer decides whether a public share link is a feature or a contradiction. Write that audience into the access plan. It is the test for every exception that follows.

Inventory every entrance and every name

List public address mappings, reverse proxies, alternate hostnames, IPv6 listeners and any tunnel or mesh address that reaches the service. Include the names that resolve to those addresses, because a forgotten DNS record is an entrance with a friendly label.

Check the proxy configuration for forwarded headers and alternate server blocks. A proxy added for a different application can expose the same upstream by path or by a leftover virtual host. Read the actual configuration rather than the intended diagram. The two diverge most often after an application is moved.

Then block the entrances you did not choose. A private backend with a public front end is not a VPN-only design, and a firewall rule that only covers IPv4 leaves the IPv6 listener open. Close both families and both names in the same change.

Give every client one service name

Point private DNS at the service, route that name through the VPN, and issue the certificate for it. The name must resolve through the private path and validate without a warning. A client that reaches the IP directly still needs the name to work.

Clients that connect by an unrelated IP address should not have to dismiss certificate errors to make the design work. A stable name also keeps sync clients from creating duplicate server entries when an address changes. That is the difference between a private service and a private IP.

Keep certificate validation enabled. A private network reduces exposure but does not make an unvalidated TLS connection acceptable, and a client trained to ignore warnings will ignore them on other networks too.

Scope network access, not the whole LAN

Permit enrolled users to reach the Nextcloud service and its necessary dependencies, and keep server administration on a separate path. A VPN that admits a client to the entire home or office network gives that client far more than the application requires.

VPN admission does not replace Nextcloud accounts, permissions or additional authentication. The application still decides which user may read which file, and the network layer should not be the only control.

Record the approved source range and the service ports. The target owner needs the observed source, and a NAT or proxy can rewrite it before the request reaches the application.

Review every non-browser workflow

Desktop sync and mobile uploads open their own connections at their own times. They need the approved private path when they connect, and they may behave differently when the VPN is absent: retry, pause or surface an error. Test each one, not just the browser.

WebDAV tools and calendar or contact clients are separate integrations with their own configuration. A client that caches a public URL keeps trying that URL after the perimeter change, and the failure looks like an application problem.

Shared links deserve an explicit decision. A link does not grant its recipient VPN access, so under a genuinely VPN-only design an outside recipient cannot use it even though the link is valid. If outside sharing is required, that is a deliberate exception with its own access path, not an oversight to discover later.

Federation and server-to-server integrations need the same treatment. They are reachability relationships between installations, and a private-only deployment has to say whether they are supported.

Accept both the allowed and the denied case

From an approved client, check the web interface and an ordinary file upload or download. Then check a sync client and one non-browser workflow. Success in the browser alone is not acceptance.

From an unapproved path, confirm that the application is unreachable through every entrance on the inventory. Test the alternate hostname and the IPv6 address, not only the primary URL.

Finally review the application settings that are easy to confuse with network policy. trusted_domains lists names the instance accepts; it is not a client IP allow list. If a reverse proxy supplies address information, trusted_proxies must name the actual proxy, and forwarded headers should be accepted only from it.

Continue the normal hardening work alongside the network change: keep data and backups out of unintended web paths, patch the application, protect administrator access and keep recovery usable. A VPN removes an entrance surface; it does not make an enrolled client trustworthy.