The Basics of Networking for Salesforce Architects

Part 109: The Basics of Networking for Salesforce Architects

Welcome back to the Salesforce series. We are now deep into The Complete Guide to Salesforce Architecture, and this installment tackles a topic that many Salesforce professionals overlook until it bites them — networking. If you have ever been on an integration call where someone mentions CIDR blocks, firewall rules, or reverse proxies and you quietly hoped the conversation would move on, this post is for you.

Salesforce lives on the internet. Every API callout, every login, every data sync between Salesforce and an on-premise ERP system travels across a network. An architect who does not understand basic networking concepts will struggle to design reliable integrations, troubleshoot connectivity failures, or have a productive conversation with the network security team. Let us fix that.

Why Is Networking Knowledge Important for Salesforce Architects?

You might be thinking — Salesforce is a cloud platform, so why should I care about networking? The answer is that Salesforce rarely exists in isolation. Most enterprise implementations involve integrations with on-premise systems, third-party SaaS applications, and middleware platforms. The moment data needs to travel between Salesforce and something else, you are dealing with networks.

Here are some real situations where networking knowledge is non-negotiable:

IP whitelisting. A customer’s on-premise system only accepts connections from known IP addresses. You need to provide the Salesforce IP ranges. But which ranges? How do you read CIDR notation? What if you are using a proxy?
Firewall rules. An integration to a customer’s SAP system keeps timing out. The network team says the firewall is blocking outbound traffic on port 443 from the Salesforce IP range. You need to explain exactly what needs to be opened and why.
Named Credentials through a proxy. Your organization routes all outbound traffic through a forward proxy for security auditing. You need to configure Named Credentials to work with this setup.
Debugging connectivity failures. A callout from Apex is throwing a CalloutException. Is it a DNS issue? A firewall block? A certificate problem? Understanding the network path helps you isolate the issue.

If you want to be a credible architect in any enterprise Salesforce engagement, you need to speak the language of networking. Let us walk through the fundamentals.

What Is a LAN and a WAN?

A LAN (Local Area Network) is a network that connects devices in a small geographic area — a single office building, a floor, or a home. The computers, printers, and servers on a LAN can communicate with each other directly at high speeds. When you connect your laptop to the office Wi-Fi and access a shared drive, you are using a LAN.

A WAN (Wide Area Network) connects LANs across larger geographic distances. The internet itself is the largest WAN in existence. When your office in New York communicates with your data center in London, that traffic crosses a WAN.

Why does this matter for Salesforce? When an organization has an on-premise system (like an ERP running in a private data center), that system sits on a LAN. Salesforce, on the other hand, lives on the public internet. Any integration between the two must cross the boundary from the private LAN, through the WAN (the internet), and into Salesforce’s cloud infrastructure. That boundary crossing is where firewalls, proxies, and IP whitelisting come into play.

What Is an IP Address?

An IP (Internet Protocol) address is a unique numerical label assigned to every device on a network. It is essentially the mailing address of a computer. When Salesforce makes an outbound callout to your API endpoint, or when a user logs into Salesforce from a browser, IP addresses are what make routing possible.

IPv4

IPv4 addresses look like this: 192.168.1.100. They are four numbers (each 0 to 255) separated by dots, giving us roughly 4.3 billion possible addresses. That sounds like a lot, but with billions of devices connected to the internet, we ran out of IPv4 addresses years ago.

IPv6

IPv6 was created to solve the address exhaustion problem. An IPv6 address looks like this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. It is much longer, providing a practically unlimited address space. Salesforce supports IPv6, and as more networks adopt it, architects should be aware of its existence and format.

Public vs. Private IP Addresses

Private IP addresses are used within a LAN. They are not routable on the public internet. Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Your laptop on the office network likely has a private IP like 10.0.1.45.

Public IP addresses are globally unique and routable on the internet. When your private network communicates with the outside world, a device called a NAT (Network Address Translation) gateway translates the private IP to a public one.

For Salesforce architects: When you whitelist Salesforce IP ranges on a firewall, you are whitelisting public IPs. Salesforce publishes its IP ranges in the official documentation and in the Trust site. These are the public addresses that Salesforce uses for outbound API calls. If you are setting up a callout from Apex to an on-premise system, the customer’s firewall needs to allow inbound connections from these Salesforce IP ranges.

What Is a Subnet?

A subnet (subnetwork) is a logical subdivision of an IP network. Subnetting allows network administrators to break a large network into smaller, more manageable pieces. Each subnet has a defined range of IP addresses.

CIDR Notation

Subnets are expressed using CIDR (Classless Inter-Domain Routing) notation. It looks like this: 13.108.0.0/21. The number after the slash tells you how many bits of the address define the network portion. The remaining bits define the host addresses within that subnet.

/32 — a single IP address
/24 — 256 addresses (e.g., 192.168.1.0 through 192.168.1.255)
/21 — 2,048 addresses
/16 — 65,536 addresses

The smaller the number after the slash, the larger the subnet.

Why It Matters for Salesforce IP Whitelisting

Salesforce publishes its outbound IP ranges in CIDR notation. For example, you might see something like 13.108.0.0/21 listed as a Salesforce IP range for a particular region. When a customer asks you to provide the IPs to whitelist, you hand them these CIDR ranges. If you do not understand CIDR notation, you cannot validate whether the ranges are configured correctly on their firewall. A misconfigured subnet mask could either block legitimate Salesforce traffic or open up too broad a range.

What Is a Firewall?

A firewall is a network security device (or software) that monitors and controls incoming and outgoing network traffic based on predefined rules. Think of it as a bouncer at a door — it decides which traffic is allowed through and which gets turned away.

Firewalls operate on rules that typically specify:

Source IP — where is the traffic coming from?
Destination IP — where is the traffic going?
Port — which service is being accessed? (Port 443 for HTTPS, Port 80 for HTTP, etc.)
Protocol — TCP, UDP, etc.

How It Relates to Salesforce Integrations

Firewalls are the single most common cause of integration connectivity issues in enterprise Salesforce projects. Here are the two main scenarios:

Inbound to on-premise (Salesforce calling out to the customer’s system): Salesforce makes an HTTP callout from Apex or a middleware tool. That request originates from a Salesforce IP address and needs to reach the customer’s server. The customer’s firewall must have a rule allowing inbound traffic from Salesforce’s IP ranges on the appropriate port (usually 443).

Outbound from on-premise (the customer’s system calling the Salesforce API): The customer’s middleware or integration server sends a request to the Salesforce REST or SOAP API. The organization’s firewall must allow outbound traffic to Salesforce’s endpoints. Additionally, if the organization uses Salesforce login IP ranges or connected app IP restrictions, those need to be configured to accept the outbound server’s public IP.

When an integration stops working after months of running fine, the first thing to check is whether someone changed the firewall rules. It happens more often than you would expect.

What Is a DMZ?

A DMZ (Demilitarized Zone) in networking is a subnetwork that sits between an organization’s internal private network and the public internet. It acts as a buffer zone. Servers in the DMZ can be accessed from the internet, but they are isolated from the internal network by a second firewall.

A typical DMZ setup has two firewalls:

Outer firewall — sits between the internet and the DMZ. Allows specific inbound traffic (like HTTPS requests) to reach servers in the DMZ.
Inner firewall — sits between the DMZ and the internal LAN. Only allows traffic from the DMZ to specific internal systems on specific ports.

For Salesforce architects: When an organization exposes an API for Salesforce to call (for example, an integration endpoint that Salesforce hits via an Apex callout), that API server is often placed in the DMZ. This way, Salesforce can reach the endpoint over the internet, but the endpoint itself does not sit directly on the internal network. The DMZ server can then make controlled requests to internal systems behind the inner firewall. This is a common and recommended security pattern for Salesforce-to-on-premise integrations.

What Is a Forward Proxy?

A forward proxy is a server that sits between client devices on a private network and the internet. When a client wants to access an external resource, the request goes to the forward proxy first. The proxy then makes the request on behalf of the client and returns the response.

Forward proxies are used for:

Security and auditing — the organization can log all outbound traffic.
Content filtering — blocking access to certain websites.
IP masking — external services see the proxy’s IP address, not the individual client’s IP.

For Salesforce architects: Some organizations route all outbound API traffic through a forward proxy. If you are using Named Credentials in Salesforce to call an external API, and the customer requires that traffic pass through their proxy, you need to understand how this affects the architecture. Salesforce itself does not natively route callouts through a customer-controlled forward proxy (since Salesforce is in the cloud, not on the customer’s network). However, when the integration pattern involves middleware running on the customer’s network (like MuleSoft on-premise, Dell Boomi Atom, or a custom integration server), that middleware often routes through a forward proxy before reaching external endpoints.

What Is a Reverse Proxy?

A reverse proxy sits in front of one or more backend servers and intercepts requests from external clients. Unlike a forward proxy (which serves the client), a reverse proxy serves the server. External clients connect to the reverse proxy, and the proxy forwards the request to the appropriate backend server.

Reverse proxies are used for:

Load balancing — distributing incoming requests across multiple backend servers.
SSL termination — handling HTTPS encryption/decryption so backend servers do not have to.
Security — hiding the identity and architecture of backend servers from the public internet.
Caching — serving cached responses to reduce load on backend systems.

For Salesforce architects: Reverse proxies are extremely relevant when you expose an API for Salesforce to consume. For example, imagine Salesforce needs to call an on-premise REST API. Instead of exposing the backend server directly, the organization places a reverse proxy (like NGINX, F5, or an API gateway such as Apigee or Kong) in the DMZ. Salesforce’s callout hits the reverse proxy, which then routes the request to the correct backend service. This setup gives the organization control over rate limiting, SSL management, and request routing without exposing internal infrastructure.

Another common pattern is using a reverse proxy to consolidate multiple backend services behind a single endpoint. Salesforce’s Named Credential points to one URL, and the reverse proxy routes to different backends based on the request path. This simplifies the Salesforce configuration significantly.

How All of This Ties Into Salesforce Integration Architecture

Let us bring everything together with a real-world scenario. Imagine you are designing an integration where Salesforce needs to call an on-premise Order Management System (OMS) whenever an Opportunity is closed-won.

Here is what the network path might look like:

Salesforce Apex trigger fires and makes an HTTP callout using a Named Credential.
The request leaves Salesforce’s cloud infrastructure from one of Salesforce’s published public IP addresses.
The request travels across the WAN (the internet) to the customer’s network.
The request hits the customer’s outer firewall, which checks the source IP against the whitelist. Because the customer whitelisted Salesforce’s IP ranges (in CIDR notation), the request is allowed into the DMZ.
In the DMZ, a reverse proxy (or API gateway) receives the request. It terminates SSL, validates the request headers, and forwards the request through the inner firewall to the OMS server on the internal LAN.
The OMS processes the request and sends a response back through the same path.

If any piece of this chain is misconfigured — wrong IP range on the firewall, reverse proxy not forwarding correctly, inner firewall blocking the port — the integration fails. An architect who understands these networking layers can diagnose the problem quickly instead of spending days going back and forth between teams.

Practical Checklist for Salesforce Architects

When designing an integration that crosses network boundaries, confirm the following:

Salesforce IP ranges are whitelisted on any firewalls between Salesforce and the target system. Always reference the latest ranges from Salesforce’s official documentation, as they can change.
Ports are open. HTTPS (443) is the standard, but verify.
DNS resolution works. If Salesforce is calling a hostname, that hostname must be resolvable from the public internet.
Certificates are valid. Salesforce requires that external endpoints use certificates signed by a trusted Certificate Authority. Self-signed certificates will not work out of the box.
Proxy configurations are documented. If middleware routes through a forward proxy, make sure the proxy allows traffic to the target endpoint.
DMZ and reverse proxy rules are in place. If the target system sits behind a reverse proxy, confirm the proxy routes the request correctly to the backend.
Timeouts are accounted for. Salesforce Apex callouts have a maximum timeout of 120 seconds. If the network path includes multiple hops through proxies and firewalls, latency adds up.

Wrapping Up

Networking is not the most glamorous topic in the Salesforce ecosystem, but it is one of the most practical. Every integration failure you will ever troubleshoot has a networking component — a blocked port, a missing IP whitelist entry, a certificate mismatch, or a misconfigured proxy. The concepts we covered here — LANs, WANs, IP addresses, subnets, firewalls, DMZs, forward proxies, and reverse proxies — are the building blocks of every integration architecture diagram you will ever draw.

You do not need to become a network engineer. But you do need to speak the language well enough to collaborate with network and security teams, ask the right questions during integration design reviews, and troubleshoot issues without waiting for someone else to figure it out. That is what separates a Salesforce administrator who can configure integrations from a Salesforce architect who can design them.

In the next installment, we will continue building out the architecture guide with more infrastructure concepts that Salesforce architects encounter in the real world.