Apex callouts leave from Salesforce, not from your VPN
A laptop VPN gives your browser a path, not Apex or Marketing Cloud. Match the real caller to a public gateway or a qualified private connection.
The private API answers in your browser the moment the laptop joins the VPN, so the integration "should work". It does not, because the code that makes the callout runs somewhere else entirely. Apex executes on Salesforce's application servers, and a Marketing Cloud server-side activity executes in that product's runtime. Neither of them inherits your laptop's tunnel. Run this as a short procedure: identify the caller, choose an entrance that caller can reach, wire the path end to end, then verify from the runtime itself.
Write the caller card before any network change
Fill in five fields and refuse to guess any of them. The execution product and context decide everything downstream, so start there rather than with the server's firewall.
| Field | What it must answer |
|---|---|
| Runtime | Which product and execution context issues the request? |
| Endpoint | Which hostname must that runtime resolve, and to what? |
| Path | Which supported public entry or private connection carries it? |
| Identity | Which credential and which operation is the API asked to authorize? |
| Failure | How do responses return, and what happens when the path is down? |
A browser tab and an Apex callout are two different clients, and a working browser proves only that a path exists from your desk. If the runtime field says Apex, the relevant question is which addresses Salesforce egresses from, not which addresses your laptop holds. That is why a tunnel that makes the API load in a browser can leave the integration failing with the same timeout it had before. The caller card exists to stop that mistake before anybody edits a firewall.
Pick the entrance the caller can actually use
Two designs are legitimate, and they solve different problems. The first is a deliberate public entry: an HTTPS API gateway or integration service that authenticates the caller, applies narrow permissions, and holds a protected connection to the private backend. That is not the same as exposing every backend service or forwarding a management port to the internet.
The second is a qualified private connection. Salesforce's Private Connect outbound documentation describes routing supported callouts through an Outbound Network Connection bound to a named credential, over its defined AWS PrivateLink arrangement. The feature has edition, licence and product constraints, so confirm the org qualifies before designing around it.
Neither design is an OpenVPN client installed inside Salesforce, and the older claim that every integration must reach a public backend is too broad wherever a supported private connection fits. Pick the one the runtime supports, then finish the path to the real API: an AWS endpoint does not know your on-premises resource and does not inherit your laptop's route. DNS, backend routing, access policy and reply traffic all have to follow the architecture you chose. A half-built private path fails in a way that looks exactly like an authentication problem.
Wire the private path end to end
Work outward from the API and stop at the first gap. Confirm the backend answers locally, then confirm the private endpoint reaches it, then confirm the named credential and its outbound connection target that endpoint.
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integrationThe first command proves the backend is healthy from inside the private network, the second shows what the name resolves to, and the third executes a callout from the actual Salesforce runtime. A 200 from the first and a failure from the third isolates the gap to the path or the credential rather than the service.
Keep the identity scope precise while wiring. A named credential does not repair an unreachable endpoint on its own, because the credential and the private connection are related settings with separate jobs. An IP allowlist narrows network admission and is not an API credential, so retain normal TLS validation and the service's own authentication and rotation process. If a test succeeds only after you disable certificate checking, you have found a hostname problem rather than a path problem, and the certificate still needs to match.
Verify from the runtime, then record the rollback
Accept a harmless permitted request from the integration runtime, not from your machine. Record the receiving service's observed source, the authenticated principal, the result, and one deliberately denied request that must fail.
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/pingRun the same two probes from the backend's own network so the observed source can be compared with what the runtime produced. A 200 followed by a 401 or 403 is the shape you want; two 200s mean the denial path is not actually enforced.
Write the rollback before you need it: which allowlist entry, named credential or outbound connection you changed, who owns it, and how to restore the previous value. Then close the loop by naming the cloud caller and the complete service path in the ticket, so nobody reopens the same issue as a VPN problem.