## TL;DR

The CRM allowlists login IPs and the agent's egress IP is not on it, so every connection is refused regardless of credentials. Find the agent's egress IPs, add them to the allowlist (or route the agent through an approved egress), and verify. This is network policy, not auth.

## Error

```text
Access error: login from unrecognized IP; the IP allowlist blocked the connection.
```

## Steps

1. Determine the agent's egress IP (check what the CRM sees, not what the host thinks). Expected: the real public egress IP.
2. Add it to the CRM's trusted IP ranges or login IP allowlist. Expected: the policy permits the agent.
3. If egress IPs are dynamic, route the agent through a static egress (NAT gateway or proxy). Expected: a stable IP to allowlist.
4. Verify with a login from the agent. Expected: success.
5. Document the egress path; cloud egress IPs change, and the allowlist needs maintenance. Expected: no surprise re-blocks.

## When to use

- Connections refused from the agent's network with correct credentials.
- An agent works from one network but not another.
- After migrating agent hosting.

## When not to use

- Wrong credentials (fix auth).
- 403s after successful login (permissions).

## Tool compatibility

- Salesforce login IP ranges and trusted IPs; HubSpot IP allowlisting.
- NAT gateways and egress proxies.

## Variant phrasings

### ip allowlist blocked egress

Allowlist the egress IP or fix the route.

### unrecognized ip on login

Same policy block.

## Why it happens

Allowlisting trusts networks, not just credentials. Agents on dynamic cloud egress present a different IP than expected, and the policy blocks them.

## Edge cases

- IPv6 egress needs its own allowlist entries; check both families.
- VPNs change the egress IP; allowlist the VPN egress, not the office.
- Overly broad allowlists defeat the purpose; keep them tight.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WxvNw_f3XONvJqPLMs_e2A