Restricting Salesforce Org Access by IP

Restrict DevHub and production org access to your sfp server's egress IP using Salesforce profile login IP ranges.

Because an sfp server instance is single-tenant, all of its Salesforce traffic — DevHub calls, production deployments, sandbox operations — originates from a fixed set of egress IP addresses. The org-side integration user can therefore be restricted to those addresses using Salesforce profile login IP ranges. If the integration user's credentials or refresh token leak, they cannot be used from any other address.

Prerequisites

• A dedicated integration user in each org you register with sfp server (DevHub, production). Do not register orgs under a human's user account — IP restrictions are applied per profile, and you want a profile that only the integration user holds.
• Your server's egress IP address(es). For self-hosted deployments this is the public IP your Docker host (or its NAT gateway) presents outbound; verify it from the machine running the workers:

curl -s https://ifconfig.me

If your workers run behind a NAT gateway or egress proxy, use that address. For cloud-hosted instances, reach out to flxbl support to get the egress IP address of your instance.

This control only works if the egress IP is stable. If your server egresses through a dynamic residential or office IP, put it behind a NAT gateway or VPN with a fixed address first.

Salesforce-side configuration

1. Restrict the integration user's profile to the server IP

In each org (Setup → Profiles → the integration user's profile → Login IP Ranges), add the server's egress address — for a single IP, use it as both start and end:

Start IP: 203.0.113.10
End IP:   203.0.113.10

Do not stop at the server IP alone if this org feeds sandbox pools. Profiles are copied into sandboxes on create/refresh, and pooled review environments are refreshed frequently — often daily. A profile that allows only the server IP will, in every copied sandbox, block the frontdoor sessions testers and developers use to open review environments. Add your corporate VPN or developer egress ranges alongside the server IP before saving:

Start IP: 203.0.113.10    End IP: 203.0.113.10     (sfp server)
Start IP: 198.51.100.0    End IP: 198.51.100.255   (corporate VPN egress)

See Impact on frontdoor access and review environments for the full mechanics.

Profile login IP ranges are enforced for API logins as well as interactive logins. A login attempt with valid credentials from any other address is rejected outright — there is no verification-code fallback.

2. Enforce the ranges on every request, not just login

By default, Salesforce checks profile IP ranges only at login; an established session can then be used from other addresses. To close that gap, enable:

Setup → Session Settings → "Enforce login IP ranges on every request"

This makes Salesforce validate the originating IP on each API call for users whose profiles define login IP ranges.

Read Impact on frontdoor access and review environments below before enabling per-request enforcement. It changes the behavior of browser sessions minted through sfp server's environment access feature, and the setting is copied into sandboxes on refresh.

3. Do not rely on Network Access trusted ranges

Setup → Network Access trusted IP ranges look similar but do something different: they only skip the identity-verification challenge for logins from listed addresses. They do not block logins from other addresses. Use profile login IP ranges for restriction; treat Network Access as unrelated to this control.

4. Harden the integration user itself

IP restriction combines with standard integration-user hardening:

• Assign the API Only User permission so the integration user cannot log in through the UI (note: this also disables frontdoor sessions for that user — see below).
• Scope the profile and permission sets to the operations sfp performs.

A note on connected apps

sfp server authenticates to the org with the refresh token captured when the org was registered (the SFDX auth URL). These tokens are issued through the Salesforce CLI's connected app, and that is deliberate: tokens from this app work across the sandboxes and scratch orgs created from the hub, which environment pooling depends on.

A custom app is not a substitute. Salesforce no longer allows creating new connected apps — new apps are External Client Apps, and ECAs do not propagate to scratch orgs, which also rules out a JWT bearer flow for pooled environments. There is therefore no app whose policies you manage in this setup; apply the controls at the integration user's profile, as described above.

Impact on frontdoor access and review environments

sfp server's environment access feature mints frontdoor URLs: the server logs in as the stored org user (from the server's IP) and hands the resulting session to a developer or tester, who opens it in their own browser — from their IP.

Profiles — including login IP ranges — and session settings are copied into sandboxes when they are created or refreshed. Locking the integration user's profile in production therefore propagates into every sandbox built from that org.

With sandbox pools, this is not a one-time event: pooled review environments are refreshed frequently — often daily — so the production lockdown is re-stamped into them on every cycle. Frontdoor access for testers and developers breaks on each refresh, in a different org than the one you configured, with nothing more visible than a failed environment open. The only org-side signal is Restricted IP entries in the sandbox's Login History.

The server itself keeps working throughout (its IP is allowed), so deployments and pool operations succeed while testers are locked out — which makes the cause hard to spot.

How the controls interact with frontdoor sessions:

Configuration	Effect on frontdoor sessions
Profile IP ranges only (login-time check)	Frontdoor continues to work. The login happened from the server IP; the browser session is not re-checked per request.
Plus "Enforce login IP ranges on every request"	Frontdoor sessions fail for users outside the allowed ranges — each browser request is checked against the profile's ranges.
Plus "API Only User" permission	Frontdoor fails entirely for that user, regardless of IP.

Pick the posture per org:

• Production or DevHub that feeds sandbox pools (most production orgs): always include your corporate VPN or developer egress ranges in the profile alongside the server IP — the profile will be copied into every pooled sandbox at the next refresh. Prefer login-time-only restriction (skip per-request enforcement); it already blocks the use of leaked credentials and refresh tokens from outside the ranges, without breaking frontdoor sessions in the copies.
• Production or DevHub that does not source pooled sandboxes, and that nobody opens through sfp's environment access: the full set — profile IP ranges, per-request enforcement, API-only user — is viable.
• After any sandbox refresh, verify the copied profile's ranges before testers need the environment.

Verifying the lockdown

After configuring, verify both directions:

1. From the server: trigger any operation that touches the org — a validation, a deployment, or environment access from the web UI — and confirm it succeeds.
2. From outside: attempt to log in as the integration user from a machine outside the allowed ranges and confirm the login is rejected.
3. In the org: Setup → Login History for the integration user should show successful logins only from the server egress IP; attempts from other addresses appear with a Restricted IP status.