Restricting EspoCRM access by IP address

When restricting EspoCRM access by IP address fits your security model

Restricting EspoCRM access by IP address limits which network addresses can reach the login and the application at all, so a user working from outside your approved ranges is refused before a password is even checked. The EspoCRM security documentation lists restricting access by IP address among its recommended controls, alongside password policy, mandatory two-factor authentication and keeping admin accounts out of daily use. In practice, the control suits organizations where staff sit on fixed office ranges or reach the CRM through a VPN with a stable egress address. In those cases, the allowlist removes a large share of credential-stuffing and password-reuse exposure from the public internet at almost no cost to users.

The control is weak on its own in several common situations. Roaming sales staff on home or hotel networks have addresses you cannot predict, so the allowlist either blocks legitimate work or gets widened until it protects little. Shared cloud egress is another trap: many SaaS tools and some VPN providers send traffic from address pools used by thousands of other customers, so a range that looks private may be open to anyone on that provider. Customer portal users usually connect from networks you will never know, which is why portal access normally needs a separate decision rather than the staff allowlist.

Before you rely on this layer, confirm three things with your network team: which egress addresses your VPN and offices really use and whether they are static, whether a reverse proxy or load balancer sits in front of EspoCRM so that the address the application sees is the client's address and not the proxy's, and who approves changes when the allowlist must be updated. Pair the allowlist with strong authentication and treat it as one layer, not the perimeter.

Which IP rule applies to each group of users

The goal for staff is to accept logins only from the networks your company controls, such as the office and the VPN. This is usually the best fit for an IP rule, because the source addresses are known and change rarely. The main risk is locking out people who work from home, travel or use mobile connections that are not routed through the VPN. Many VPN gateways also share one egress address across all remote users, which means a rule that works for one group may be too broad for another.

Egress addresses: Collect the public addresses that office and VPN traffic actually leaves from, not the internal ranges your staff see on their laptops.
Shared NAT: Confirm whether the VPN presents many users behind one address, which affects how tightly the rule can be drawn.
Remote and mobile access: Decide whether staff who cannot use the VPN will be blocked by design or need a documented alternative.
Change control: Set an owner for the allowlist so that office moves, new VPN gateways and ISP changes are recorded.
Failure path: Confirm what staff do when the VPN is down and who can approve a temporary change.

Before enforcing the rule, test a login from each office and VPN path and from a home connection, and confirm the address EspoCRM sees matches the one you expect.

Configuration options and when each one fits

This table compares the decisions a team makes before enabling an IP allowlist for EspoCRM: which addresses to allow, how the client address is read, and how portal users, API users and off-network staff are handled. Read each row against your network layout, then confirm the open points with your EspoCRM administrator and network team before changing production settings.

Decision	When it fits	Trade-off	What to confirm
Office ranges only	Staff always sign in from fixed office sites with known public addresses	Remote and traveling staff are locked out until a fallback exists	Public egress addresses for every office and whether they change
VPN egress only	All staff reach the CRM through a corporate VPN with a stable exit address	A VPN outage blocks all users, and split tunneling can bypass the check	VPN exit addresses, split tunnel policy and who owns VPN changes
Office and VPN combined	Mixed teams work on site and remotely through managed access	Larger list to maintain, and each range widens the reachable surface	Ownership of each range and a review date for the list
Direct connection address	EspoCRM receives client connections without any intermediate proxy	Simplest to reason about, but breaks if a load balancer is added later	Confirm no proxy or CDN sits in front of the instance
Behind a reverse proxy or load balancer	Nginx, Apache, IIS or a cloud load balancer terminates connections before EspoCRM	If the forwarded client address is misread, every user appears to come from the proxy	How the proxy passes client addresses and which parameter EspoCRM reads for them
Separate handling for portal users	External customers sign in through a portal that office ranges do not cover	Portal exceptions widen access for an audience that is not staff	Whether portal logins can be exempted without exempting staff accounts
Separate handling for API users	Integrations call the REST API from fixed servers outside the office	Exempted integrations depend on role permissions and credential hygiene alone	Source addresses of each integration and the API authentication method in use
Fallback for users outside the network	Staff travel or work from home without a VPN	A fallback path such as a second factor or identity provider policy must be built and tested	Which fallback the organization accepts and who approves exceptions

Why REMOTE_ADDR goes wrong behind a reverse proxy

An IP allowlist only works if EspoCRM sees the address of the user, not the address of the proxy in front of it. When EspoCRM runs behind Nginx, Apache, IIS or a load balancer, the connection the application receives usually comes from the proxy. If the allowlist is checked against that address, it either admits everyone (when the proxy sits on an allowed network) or blocks everyone (when it does not). The fix is to pass the client address through a forwarding header, but that header is only as trustworthy as the proxy that sets it.

The trust decision sits with you. Honor forwarded address headers only when they come from a proxy you control, and configure that proxy to overwrite any forwarding headers a client sends, rather than appending to them. If the proxy simply passes through what arrives, an attacker outside your network can send a fake address that matches your allowlist. Limit the trusted proxy list to the specific hosts or networks in front of EspoCRM, and keep that list current when load balancers or ingress controllers change.

The setting to verify is REMOTE_ADDR, the value EspoCRM uses to decide which address a request came from. Confirm in the EspoCRM server configuration documentation exactly how the address is read in your EspoCRM version, which header or server variable it depends on, and which proxy settings your web server must provide. Then test from a client outside the allowed network through the real proxy path, and confirm the logged address is the user's, before you rely on the allowlist for access control.

Setting up the IP allowlist without locking out your own team

This sequence builds the allowlist from a verified list of office and VPN addresses, confirms that EspoCRM reads client addresses correctly behind your proxy, and proves every login type works before production is restricted.

Inventory office and VPN egress addresses
Ask your network team for every public address that office sites, VPN concentrators and remote-access gateways use when traffic leaves your network. Record each address or range, the site or service it belongs to, and who owns the change process for it. Include any cloud NAT gateways that staff or integrations pass through. The step is done when the network team has signed off on the list and named a contact for future changes. Confirm with them whether addresses are static, because dynamic addresses on home or branch connections will need a different plan.
Confirm the client address EspoCRM sees
Sign in from a known office network and from the VPN, then check which address EspoCRM records for the session or login attempt. If you run EspoCRM behind a reverse proxy or load balancer, the application may see the proxy's internal address instead of the client's. Compare what the application logs with the public address from your inventory. The check passes when the recorded address matches the known network for both test logins. If it does not, fix the forwarded-address configuration at the proxy and repeat this test before you go further, because the allowlist depends on it.
Configure the allowlist in staging
On a staging instance that mirrors production's proxy setup, add the verified addresses to the IP allowlist setting in the EspoCRM administration area. Keep the list to the ranges you inventoried and record who approved each entry. Save the change and confirm the setting appears in the saved configuration. Staging should not be a copy of production data for this test, but it should use the same reverse proxy and TLS path. The step is complete when the saved list matches the approved inventory line by line.
Test staff logins from inside and outside
Using accounts with ordinary staff roles, sign in from an allowed office network, from the VPN and from an address outside the list, such as a mobile connection. Record the result of each attempt, including the error shown to the user. Allowed networks should reach the application and the outside attempt should be refused. Ask a few staff members from different teams to repeat the test on their own devices so you catch routing differences that one tester would miss. The check passes when every allowed path works and every outside path is refused.
Test portal, API and administrator logins
Repeat the tests for each access type that your deployment uses. Portal users may reach the application from customer networks, so decide whether they are exempt or handled by a separate portal, and test that decision. API users calling from integration servers need their source addresses on the list or a documented exception. Test an administrator login from the allowed network and from outside it. Confirm the documented behavior for each type in EspoCRM's security and API documentation before relying on it. The step passes when each access type behaves as your written decision says.
Agree an emergency access path
Write down how an administrator gets in if the allowlist blocks everyone, including an out-of-band route such as console access on the host, a documented change to the list made by a named person, and a second administrator who can perform it. Confirm that the route works by performing a dry run in staging. Store the procedure where the on-call team can reach it without EspoCRM access. The step is done when someone who was not involved in the configuration can follow the written procedure and reach the admin screen in staging.
Enforce in production and watch failed attempts
Apply the tested list to production during a planned window with the network and support teams informed. Immediately after the change, sign in from an allowed network to confirm access still works. Then review failed login attempts in the application and proxy logs for the first days of enforcement, looking for legitimate staff, integrations or partners that were refused. Add approved addresses through the same change process as the inventory. The step is complete when the team has reviewed the logs on a set schedule and has no unexplained refusals from known networks.

Security risks that IP restriction does not solve on its own

An IP allowlist narrows where logins can come from, but it does not confirm who is logging in or whether the request really came from that network. The cards below cover the gaps that tend to remain after IP rules are in place, and the controls that close them.

Spoofed client addresses from trusted headers

EspoCRM checks the client address it receives, and behind a reverse proxy that address is often the proxy itself unless forwarding headers are read. If the application trusts a forwarding header such as X-Forwarded-For from any sender, a client outside your network can present an allowed address and pass the check. Confirm that only your proxy is trusted to set that header, and test the allowlist from an address that should be refused.

Shared and changing egress addresses

Office NAT, carrier-grade NAT, cloud egress gateways and home connections can share one public address across many users, or change it without notice. An allowlist entry for a single address may admit people you did not intend, or lock out staff whose provider rotated their address. Ask your network team which addresses are static and dedicated, and document which entries cover shared ranges.

Stolen credentials from an allowed network

An attacker who obtains a valid password through phishing or a breach gains nothing more from an IP rule than a legitimate user does, and may reach the CRM through a compromised laptop, a partner network or a VPN account. The allowlist does not ask who is signing in. Pair it with multi-factor authentication, so the password alone is not enough, and review which accounts can sign in from outside the office at all.

Session length after login

An IP check runs when a session starts, so a session that stays valid for a long time keeps working after a user leaves the office network, changes device or has their access revoked. Review the idle time and lifetime of authentication tokens against how your teams work, and confirm that disabling a user also ends their active sessions.

Refused logins that nobody reviews

A blocked login attempt is only useful if someone sees it. Refused attempts from unexpected addresses can signal a misconfigured VPN, a moved user or an attacker testing the perimeter. Decide where EspoCRM and proxy logs are sent, which refusals raise an alert, and who reviews them, and confirm that the log retention period meets your own policy.

Administrators locked out during changes

Editing the allowlist from a session that is itself being refused, or applying a rule before the office and VPN ranges are verified, can remove access for every administrator at once. Keep a tested recovery path such as a second administrator on an allowed network or direct console access to the server, and make allowlist changes in a planned window with a rollback step written down.

How much effort and cost does an EspoCRM IP restriction take?

How much effort does restricting EspoCRM by IP address take?

The configuration change itself is usually small, but the surrounding work determines the effort. For one office and a single reverse proxy, the setting takes little time to apply. Most of the effort goes into confirming which addresses your users really connect from, checking that EspoCRM sees the correct client address behind your proxy layers, and testing each user type before anyone is locked out. Ask any partner to base its estimate on a written scope that lists your sites, VPN address pools, proxy chain and the user groups that need exceptions. DeployOpen gives quotes from a written scope, so an effort figure should follow that document.

What drives the cost of an IP restriction project?

Cost follows the number of moving parts you must document and test. The main drivers are:

Network inventory: how many offices, data centers, VPN concentrators and cloud egress points need allowlisting, and whether their addresses are stable.
Proxy complexity: how many load balancers, reverse proxies or CDNs sit in front of EspoCRM, and whether each one passes the original client address correctly.
Exceptions: how many portals, API users or integrations must bypass the restriction, and how each is secured in its place.
Testing: how many user types, devices and locations the test plan covers.

One-time work covers design, configuration and testing. Ongoing work covers reviewing exceptions and updating ranges. Ask for these two costs to be quoted separately.

Can an internal administrator restrict EspoCRM by IP address alone?

An experienced administrator can make the change alone if they have access to the server configuration, the reverse proxy and the EspoCRM admin area, and if the network is simple. The risk lies in locking yourself out. A wrong range or a misread proxy header can block every user, including admins. Plan a second administrator, keep a console or direct-access path to the server, and test from a network outside the allowlist before saving changes. Review the EspoCRM security guidance on restricting access by IP address to confirm which settings matter for your version. If any of these conditions is missing, a short scoped engagement may cost less than an outage.

What does the work need from network and security teams?

The network team supplies the authoritative list of office, VPN and egress addresses, including which ranges are static, which are dynamic and who owns each one. The security team approves the exception list, defines which user types may bypass the restriction and sets the monitoring expectations for denied logins. Both teams should review the proxy configuration, because the address EspoCRM sees depends on how traffic reaches it. Agree on a change window, a rollback step and an owner for the allowlist before the work starts. Without these inputs, the project stalls while the team searches for the correct ranges.

How long does validation take after an IP allowlist goes live?

Validation takes as long as your test matrix requires, and that depends on the user groups and locations involved. A useful plan tests an allowed office login, a VPN login, a denied external login, a mobile connection where policy allows it, and each portal and API user type that is meant to be exempt or restricted. Include a check that failed attempts are logged and that administrators can still sign in during a fallback procedure. Ask the partner to show the test cases and results in the written scope. Timing estimates should come from that plan, not from assumptions about the platform.

What happens after go-live when office or VPN ranges change?

Restrictions go stale when offices move, VPN pools are renumbered or a new cloud egress point is added. Users then see blocked logins that look like application faults. Assign an owner for the allowlist, tie changes to network change requests and review the list on a fixed schedule. Each review should confirm that every range is still needed, that exceptions still have a documented reason and that denied-login reports show no legitimate traffic. Recurring support of this kind can be handled in-house or through a retainer, so ask the partner to price it separately from the initial build.

How do portal and API user exceptions change the scope?

Exceptions widen the scope because each one needs its own design and test. Customer portal users may reach EspoCRM from unpredictable networks, so an IP rule may not suit them at all. API users and integrations often run from servers with fixed addresses, which makes them good candidates for allowlisting, but their credentials and permissions need separate review. Each exception should have a named owner, a documented reason and a method for periodic review. Count every exception in the written scope, because each one adds design, configuration and testing work.

Limits to confirm in your environment before you rely on it

An IP allowlist is only as strong as the address it sees. The cards below cover the checks that decide whether the restriction does what you intend, from how EspoCRM reads the client address to how exceptions, sign-in flows and changes behave. Confirm each one against the vendor documentation or in a test environment before you treat the allowlist as a control.

Client address source

Confirm how the EspoCRM version you run determines the client address when requests pass through a reverse proxy, load balancer or CDN. The allowlist compares against the address EspoCRM sees, so if every request appears to come from the proxy, the rule either blocks everyone or allows everyone. Test from a known office address and from an address outside the list, and read the server configuration docs for the forwarded-address setting that applies to your topology.

Separate exemptions for portal users

Confirm whether portal users and API users can be exempted from the IP restriction independently of internal users, and whether an exemption applies to the whole user type or to individual accounts. A portal audience often sits on the public internet, so a single broad exemption can quietly remove the restriction for the group you meant to protect. Write down which user types are covered and test one account of each type from outside the allowed range.

OIDC and LDAP sign-in behavior

Confirm how the allowlist interacts with single sign-on and directory sign-in. An OIDC redirect may originate from the identity provider's address, and the callback may arrive from a different network path than the browser session. Check whether the restriction is evaluated at the login form, at the callback, or on every request, and whether a fallback login method remains reachable. Test each sign-in path separately, including the fallback.

Cloud load balancer and CDN addresses

Confirm what address your cloud load balancer, managed ingress or CDN passes to the application, and whether the original client address is preserved in a header that EspoCRM is configured to trust. Some platforms replace the source address with an internal one, and some allow clients to spoof forwarding headers unless you restrict which proxies are trusted. Ask your hosting team to document the path for each environment, since an update to the edge can change the address without any change to EspoCRM.

Endpoints covered by the rule

Confirm whether the restriction applies to the login page only, to the whole web application, or to the REST API and websocket endpoints as well. A restriction on the login form does not stop someone who already holds a valid session token or API credential from calling the API from an unlisted address. Map each public and authenticated path your deployment exposes, then test the login page, a session token and an API call from outside the allowed range.

Range change testing and records

Confirm how a change to an allowed range is tested, approved and recorded before it reaches production. Office and VPN ranges change when networks are renumbered, providers change, or a VPN pool is extended, and an unnoticed change can lock out staff or leave a gap. Keep the allowlist in version control or a change log, test the new ranges in a non-production instance, and confirm that someone can restore the previous list quickly if a lockout occurs.

How DeployOpen scopes and delivers IP restrictions for EspoCRM

DeployOpen plans, implements and documents IP restrictions for EspoCRM inside your own infrastructure, starting from a written scope that names the networks, proxies and exception paths in use. The work covers the allowlist itself, the proxy and client address handling behind it, and the testing that proves office and VPN users get in while everyone else is stopped.

How we scope

Inventory the office, VPN and remote network ranges that should reach EspoCRM and who owns each one.
Map the reverse proxy or load balancer path so the client address EspoCRM sees is confirmed before any rule is written.
Agree in writing which portal, API user and integration paths are exempt, and which must stay reachable only through another control.

How we build

Configure the IP whitelist and the REMOTE_ADDR handling for your proxy chain, then test from inside and outside the allowed ranges.
Verify that blocked requests fail at the expected layer and that exempt paths still authenticate with their own roles and credentials.
Document each exception with its owner, reason and review date so changes to the allowlist go through a known process.

How we hand over

Deliver a configuration record, a test log and a runbook covering allowlist changes, VPN onboarding and proxy updates.
Walk your administrators through the change procedure and the checks to run after a network or proxy change.
Provide the evidence your security or compliance team needs to show the restriction is in place and was tested.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer for allowlist reviews after network changes.
Confirm with your team which EspoCRM version and proxy product you run, since the setup and the supported options depend on both.