NAS admin over a VPN: keep the name, drop the public port
Reach the admin page through the tunnel, not a new public port. Resolve the real name, match the certificate to it, and allow one service from one source.
The NAS administration page works at home and stops working the moment the administrator travels, so somebody opens a port and the problem disappears along with the privacy. There is a better shape for this. Keep the page where it is, let the tunnel supply reachability, and make what you document a complete URL with a named permission path rather than a device address that happens to answer. Every decision below, from the name to the certificate to the single allowed port, follows from writing it that way.
The unit of design is a URL, not an address
Write the entry as a full URL with its port and scheme, then attach the conditions: who may use it, from which network, and through which path. An illustration might be https://nas.corp.example:8443 published only to approved private clients, with the name and port standing in for whatever the device actually listens on.
That framing forces the decisions early. A URL implies a name, a name implies a certificate, and a certificate implies a trust arrangement. An address implies none of those, which is exactly why the address-only version survives until the first browser warning and then turns into a habit of clicking through it.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Keep the name the certificate was issued for
The client needs a permitted route to the NAS private address, and a private DNS arrangement can resolve the intended hostname to that address while preserving the name the HTTPS service expects. Both halves matter: the route gets packets there, the name tells the client which identity to verify.
Typing the numeric address instead changes the identity requirement. RFC 9525 separates the name a client intends to contact from the identity a service presents, so a certificate issued for nas.corp.example can legitimately fail when the browser was pointed at 10.20.0.15. The warning is correct, and the fix is the name, not an exception.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleRun both before blaming the tunnel. The first shows whether the private name resolves where you think, and the second shows which certificate and subject alternative names the service actually presents. A private CA can be a perfectly managed choice; what should not become routine is teaching people to dismiss identity warnings.
Bound the management path
Allow exactly the management service from the intended source, at both the gateway and the NAS. That sentence hides a detail that bites: a routed client pool and a source-translated gateway arrive at the NAS with different source addresses, so an allow rule written for one silently fails for the other.
The NAS also needs a return path, and the browser has to use the configured port and scheme rather than the vendor default from a forum post. Reaching the device is not permission to reach every port on it. The gap between a device that answers ping and an admin page that loads is the gap between two separate rules. Write them as two rules with two comments, so the next person can see why both exist.
Separate VPN admission from NAS privilege
Being allowed through the tunnel is not the same as being allowed to administer the device. A user who legitimately needs file storage should not inherit device administration because both live behind one gateway, and the NAS account model is where that separation has to be enforced.
A shared or translated exit address cannot identify an individual administrator either. If the audit trail needs to name a person, the identity has to come from an authenticated account rather than from the source address of a tunnel that many people use.
What not to publish by accident
A public reverse proxy and a vendor relay are both real architectures, and each carries its own trust and exposure decisions. Neither becomes necessary because an administrator is away from home, and neither should appear as a side effect of exposing a media server or a file share.
Document four things and stop: the private name, the listener it maps to, the group permitted to use it, and the recovery path if the tunnel is unavailable. Those four also answer the questions an incident review will ask, which is not true of a screenshot of a port-forwarding page. What you end up with is one stable administrative entry point rather than a device whose every feature faces the internet.