SharePoint links break over VPN because of published URLs
A SharePoint page that loads over VPN can still return document links on a name your client cannot resolve. Check DNS, route, TLS, and the published URL.
A SharePoint page opens through the VPN, and the first document link fails with a name that was never in the address bar. That gap is the whole problem: the page came from one URL, and the service formatted the next request from another. The published URL is a server-side decision, so fixing it on the client is the wrong end. Check which name the service returns before touching DNS or routes.
The first page and the next request use different names
A user who reaches the server by address sees a working homepage. The document links in that page are generated from the URL the service believes it is publishing, not from what the browser typed. If those differ, the next click goes to a name the client has never resolved.
Entering the address once does not repair every generated link, and a bookmark to the address hides the problem until a document is opened.
The failure is easy to misread as a VPN problem because it appears only after the tunnel is in use. In practice the tunnel is doing its job: it carries the request to a name that has no working path or no matching certificate. Separate the two questions before changing either. One is where the packet goes, the other is which name the service chose to publish.
Four controls, one name
Every published name has to pass four independent controls. DNS has to resolve it for the actual client, routing and access policy have to permit the path, TLS has to validate for that name, and the service has to be configured to publish it.
A change to one control does not perform the others. Accepting a certificate warning is not a name-resolution repair.
The table below is the checklist order. Stop at the first row that fails, because a later fix cannot compensate for an earlier gap.
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
Read the publishing model before changing it
SharePoint Server deployments differ. Classic web applications can use alternate access mappings, where an internal URL is what the server receives and a public URL is what it uses to format links. Host-named site collections take a different approach and, per Microsoft's guidance, cannot use AAM.
Microsoft's planning guidance also marks AAM features as deprecated and recommends host-named site collections for new planning. That makes the deployment model a question for its owner, not a default you patch.
Establish which model is in use before proposing a mapping change. Adding an AAM entry to a host-named deployment does nothing, and adding one to a classic deployment changes every returned link at once. Both are configuration changes with a blast radius, so stage them and keep a rollback. This is not a recommendation to introduce legacy mappings into a modern environment.
Follow the failed operation, not the homepage
Record the destination the failed request actually used, the client application, the time, and the error. A browser and a desktop application can take different proxy, VPN, or authentication paths to the same document.
The browser may succeed while the Office client fails, and that difference is a clue about which context resolves the name.
If the URL and the network handoff both work and the service still rejects the operation, the remaining problem is application-level. Document permissions and check-out state belong to the service owner, and a VPN route supplies connectivity rather than permission.
Check the handoff end to end
Run the checks in order on the client that fails: resolve the published name, request the page by that name, then request the document URL from the page source. Each step isolates one control.
Three commands cover resolution, TLS, and the document path:
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspxIf resolution fails only through the tunnel, the split-DNS policy is the suspect. If TLS fails, compare the certificate name with the published name rather than clicking through. If both succeed and the document still fails, the error is no longer about the URL.