Whitelist Salesforce IPs on the firewall to securely connect Salesforce with your on-premise systems.

Connecting Salesforce with on‑premise systems is one of the more common integration challenges you’ll face as a Certified Integration Architect Designer. The goal isn’t just to make things work; it’s to make them work securely, reliably, and with a clear audit trail. When you’re weighing how Salesforce should reach your internal services, one approach stands out for many teams: whitelist Salesforce IPs on the firewall. It’s a straightforward, auditable path that fits well with governance and risk management. Let me explain why this matters, what it looks like in practice, and how it stacks up against a few other options you’ll hear about.

A quick orientation: what problem are we solving, really?

Think of Salesforce as a smart, remote client that needs to talk to your on‑prem services—web services, APIs, or a legacy system that still handles important data. The challenge is to allow legitimate Salesforce traffic while keeping bad actors out. You want to answer questions like: Which users or applications should be allowed to access these on‑prem resources? From which locations will those requests originate? How do we prove identity and keep a clear record of access?

In this context, the “IP allowlist” approach is about drawing a precise line in the sand. If a request comes from Salesforce and its named IP range, it gets through. If it doesn’t, it doesn’t. It’s a practical way to connect two trusted fronts—the cloud and the data center—without inviting every source on the internet to knock on the door.

Why whitelisting Salesforce IPs is often the strongest starting point

• Simplicity and clarity: You have a concrete set of IPs to permit. No need to guess who’s calling or what device they’re on. That makes firewall rules easier to write, review, and update.

• Visibility and control: With IP allowlisting, you can log every attempt, track which Salesforce calls succeeded, and quickly spot abnormal patterns. It’s a transparent approach that aligns with security audits and policy reviews.

• Predictable connectivity: Once Salesforce connects from those approved IPs, your on‑prem services can respond with confidence. No need for VPN quirks or network gymnastics during business hours.

• Performance is cleaner: Direct, allowlisted traffic tends to be more efficient than routes that traverse extra chokepoints. That can translate into lower latency for critical calls and smoother data flows.

• Compliance-friendly posture: If your organization has strict controls around data ingress and egress, IP whitelisting maps cleanly to many regulatory requirements. It gives you a defensible position in audits.

What about the other options? A quick, practical read

You’ll hear several alternatives tossed into the mix. Here’s how they stack up in typical enterprise scenarios—and why they aren’t usually the sole or primary solution for Salesforce access.

• Place the systems in a DMZ

In theory, a DMZ can make services more accessible from external networks. In practice, it’s not a silver bullet for Salesforce connectivity. A DMZ can simplify exposure, but it doesn’t guarantee Salesforce traffic is the only traffic you want or need to admit. It also pushes you to manage additional exposure risks on a separate network segment, which adds complexity and potential misconfigurations if not carefully maintained. For many teams, DMZs are an architectural piece that complements, rather than replaces, a controlled allowlist strategy.

• Utilize two‑way (mutual) SSL

Mutual TLS is a strong security practice. It ensures both sides present valid certificates before talking. That’s excellent for identity assurance and channel security. However, by itself, mutual SSL doesn’t solve the practical problem of knowing which Salesforce sources should be allowed to reach your on‑prem services. It also requires robust certificate management, revocation handling, and lifecycle processes. It’s a great layer, but it works best when paired with a defined access boundary—like an IP allowlist or an identity‑based gateway.

• Whitelist the corporate IPs in Salesforce

This one sounds logical at first: tell Salesforce which internal IPs are trusted. But in daily operations, it’s brittle. Internal corporate IPs can be many, dynamic (particularly with remote workers or mobile users), and are not guaranteed to map cleanly to the Salesforce side’s requests. It creates a mismatch of trust realms and can lead to gaps where legitimate Salesforce activities get blocked or where you end up chasing stale entries. It’s a solution that’s hard to scale and hard to maintain across teams and environments.

How to implement the “whitelist Salesforce IPs on the firewall” approach cleanly

If you decide this is the right path for your environment, here’s a practical, no-nonsense checklist you can follow. It’s designed to be stable, auditable, and easy to revisit when things change.

1. Confirm Salesforce IP ranges and update cadence

• Salesforce publishes IP ranges on their Trust site. Keep a standing mechanism to fetch updates and compare them against your firewall rules.

• Plan for changes: Salesforce periodically revises IP blocks. You’ll want to schedule periodic reviews (quarterly is common) and have a process to apply updates during a maintenance window.

2. Define the protected surface

• Identify the on‑prem services Salesforce needs to reach: endpoints, ports, protocols, and data sensitivity levels.

• Use the principle of least privilege: only allow Salesforce IPs to the specific internal endpoints, not to the entire network.

3. Implement precise firewall rules

• Create explicit inbound rules for the Salesforce IP ranges to the required internal services.

• If you must support multiple environments (dev, test, prod), keep separate rule sets to limit blast radius.

• Consider egress controls on Salesforce if your architecture requires the Salesforce side to restrict outbound traffic as well.

4. Add a gateway or reverse proxy if appropriate

• A PCI/HIPAA‑compliant gateway or API gateway can add an extra layer of protection, enforce authentication, and handle rate limiting.

• A gateway can also help consolidate logs and provide a single point for monitoring, which simplifies incident response.

5. Enforce strong authentication and TLS

• Even with IP allowlisting, don’t skip strong authentication and encryption. Use TLS with up‑to‑date certificates and validate the server identity.

• Consider mutual TLS as an additional layer for sensitive data flows where you can sustain the overhead.

6. Monitor, log, and alert

• Enable detailed logs for allowed and blocked attempts. Align alerts with your security ops playbooks.

• Implement anomaly detection: spikes in traffic from Salesforce IP ranges outside of business hours or unusual endpoints should trigger a rapid review.

7. Establish change control and documentation

• Document every rule change, including the rationale, the affected endpoints, and the review date.

• Tie changes to change management processes so auditors can spot the lineage of decisions.

8. Plan for resilience and failover

• Ensure redundancy for the firewalls and the pathways that carry Salesforce traffic.

• Test failover scenarios regularly (including how to handle IP range updates during a failover).

9. Consider complementary patterns

• For higher security, pair the IP allowlist with a gateway that enforces OAuth or API keys for the Salesforce calls.

• If your on‑prem environment is complex, a VPN or private connectivity option (like a dedicated connection) can sit alongside the IP allowlist as a stronger spine for data movement.

A reality check: things that surprise teams

• IP range churn happens. Salesforce does change ranges occasionally, and if you overlook updates, legitimate calls might stop flowing.

• This approach is excellent for defined, predictable calls, but Salesforce integrations can evolve. Be ready to adjust endpoints and authentication methods as the business uses new Salesforce features.

• Don’t treat IP whitelisting as a stand‑alone security measure. It’s part of a layered strategy—combine it with strong authentication, encryption, and ongoing monitoring.

Real‑world metaphors worth keeping in mind

• Think of the firewall as the club’s guest list. Salesforce is on that list, and the internal services are the VIPs. If you know who’s on the list, entry is smoother; if the list is out of date, confusion follows.

• A gateway or API layer is the bouncer that checks credentials before the guest passes through the door. It adds traceability and an extra lock on the door.

Putting it all together: a clear path for integration teams

For teams pursuing the Certified Integration Architect Designer mindset, whitelisting Salesforce IPs on the firewall offers a clear, auditable entrance path for Salesforce to reach on‑premise systems. It provides a straightforward boundary, helps meet governance requirements, and keeps your surface area constrained enough to manage with confidence. It’s not about a single magic trick; it’s about building a robust, layered approach where the firewall rule is the foundation, and every other control adds depth.

If you’re evaluating options in a real project, start with the IP allowlist, then layer in mutual TLS or an API gateway where you can, and reserve DMZ expansion for cases where you truly need broader exposure or legacy‑heavy integrations. And always loop in your security, network, and application teams from day one. A good integration design isn’t a solo performance; it’s a coordinated ensemble that plays well with the rest of the IT orchestra.

Takeaways you can apply now

• Prioritize a precise firewall allowlist for Salesforce IP ranges to enable secure, controlled access to on‑prem services.

• Keep Salesforce IP lists current and automate updates where possible.

• Pair IP allowlisting with strong authentication and encrypted channels to harden the integration.

• Use governance‑driven processes to document changes, monitor activity, and plan for outages or IP updates.

• Avoid relying on a single mechanism. Combine access control with gateways, auditing, and regular reviews to maintain resilience.

If you’re mulling over how to structure a Salesforce‑to‑on‑prem integration, this approach offers a practical balance of security, simplicity, and maintainability. And while the technology stack may vary—different firewall brands, API gateways, or cloud services—the core idea stays steady: invite Salesforce responsibly, and keep the doors clearly labeled, watched, and ready for legitimate business needs.