We make outbound Apex callouts from a named credential to a vendor API. The vendor has moved that API onto a private cloud network, and our callouts now fail at the network layer before auth is ever evaluated.
The only working solution we've found is for the vendor to allowlist Salesforce's published Hyperforce outbound ranges from https://ip-ranges.salesforce.com/ip-ranges.json (per KB 003876184, which explicitly recommends an IP allowlist for outbound Apex callouts since Salesforce outbound IPs may not resolve under *.salesforce.com).
That works, but it has two drawbacks we'd like to avoid: the ranges are shared across all Salesforce tenants on that infrastructure, so it's a weak control rather than a real identity boundary and Salesforce advises allowlisting the entire file, which is a broad and evolving surface for the vendor's security team to accept.
What I'm hoping someone has solved before--
- Salesforce's stated preferred alternatives are mTLS and domain allowlisting, but both assume the far side is filtering at the application layer. When the block is network-level, a client certificate doesn't get you through the firewall. Has anyone actually used mTLS to solve a reachability problem rather than an auth one, or am I right that it's the wrong tool here?
- Private Connect / Outbound Network Connection appears to be AWS PrivateLink only. Can anyone confirm whether Azure-hosted targets are supported, now or on the roadmap?
- Is there any other mechanism to give an external endpoint a stable or narrower egress identity for Apex callouts?
- For those who've hit this: did you end up putting a relay/gateway in front of the private service and pointing Salesforce at that instead? Would you recommend it?
Any experience appreciated, we have a go-live this week, so we're proceeding with the allowlist for now and looking for something more durable after.
Articles that I have already read -
1. https://help.salesforce.com/s/articleView?id=003876184&type=1
2. https://help.salesforce.com/s/articleView?id=000384438&type=1
#Salesforce Developer #Architects #Solution Architects #TrailblazerCommunity #Security #Integration
Hi Piyush,
1. You're right, mTLS is the wrong tool here. mTLS operates at the application/TLS layer after a TCP connection is already established — it proves identity to something that's already listening and accepting connections. If the vendor's firewall is dropping packets before that handshake even starts, no client cert changes that. mTLS solves "who is this," not "can this even reach me."
2. Private Connect is AWS PrivateLink-based only, so it's natively usable when the target sits in an AWS VPC. Azure targets aren't natively supported — you'd need inter-cloud private peering (AWS↔Azure via ExpressRoute/Direct Connect + a transit arrangement) which Salesforce doesn't self-serve; that requires your account team and is a heavier lift. No public roadmap confirmation of native Azure PrivateLink support as of now.
3. No native mechanism gives an Apex callout a narrower/tenant-specific egress identity beyond the published IP ranges — that's the actual gap you've identified. The published Hyperforce ranges are deliberately shared infrastructure-wide, not per-org, so it's a network-layer allowlist, not an identity boundary. There's no equivalent of "static NAT per org" for outbound Apex callouts today.
4. Yes — a relay/gateway in front of the private service is the standard, recommended pattern here, and I'd recommend it. Put a lightweight reverse proxy (or MuleSoft Anypoint, or even a small managed API gateway) in a publicly reachable spot the vendor controls, with the vendor's actual private-network service sitting behind it. Salesforce calls the gateway over the public internet (allowlist-friendly, small surface), and the gateway — sitting inside the vendor's trusted network — forwards to the private endpoint. This gets you real identity-based control (API key, mTLS, OAuth — now actually meaningful since the gateway is an app-layer listener) instead of a shared-IP-range network allowlist, and it decouples you from Salesforce's outbound range changes entirely, since your callout target becomes a stable endpoint the vendor owns. This is what most orgs land on for exactly this scenario — it's a small piece of infra to own, but it's the durable fix.
Reference:
https://unofficialsf.com/understanding-private-connect/
