# slack ip restriction

## TL;DR
Slack can restrict workspace access to approved IP ranges, so anyone connecting from outside those ranges is blocked at login even with valid credentials. If legitimate users are locked out, an admin adds the missing egress ranges (office NAT addresses, VPN exit nodes) in the workspace authentication settings. Roll the restriction out gradually and keep a break-glass admin path, or one bad range locks out the whole company.

```text
slack ip restriction
```

## Use this when
- Users report they cannot log in to Slack from the office or VPN
- You are rolling out IP-based access restrictions for compliance
- Remote workers get blocked after a restriction goes live
- You need to document which networks are approved for Slack access

## Not for this skill when
- A Slack app fails with OAuth errors (that is app auth, not network restriction)
- You are setting up SSO or SAML (related but separate)
- Slack API calls hit rate limits

## Steps
1. Confirm the block is the IP restriction. The locked-out user sees a message about not being allowed from their network, and the same account logs in fine from an approved network. Ask the user for their public IP (they can search "what is my ip") and compare it against the approved ranges.
   Expected: the user's IP falls outside every approved range, confirming the cause.

2. As a workspace admin, open the restriction settings. Go to workspace settings, then the authentication section, and find the allowed IP ranges list. Review what is there before changing anything.
   Expected: you can see the current ranges and spot the missing one (often the VPN egress range changed without anyone updating Slack).

3. Add the missing egress ranges in CIDR form. Add office NAT addresses and VPN exit nodes. If your VPN provider publishes its egress ranges, use those rather than guessing. Save and have the blocked user retry.
   Expected: the user logs in normally from the previously blocked network.

4. Roll out in stages if this is a new restriction. Start with a small pilot group, watch the sign-in logs for blocks, then expand. Keep at least one admin able to reach the settings from an approved network at all times.
   Expected: no surprise company-wide lockout, and the logs show only intended blocks.

### Variant: "You are not allowed to access Slack from this network"
The user-facing wording of the block. Same fix: the user's current IP is not in the approved ranges. Check whether they are on VPN, and whether that VPN's exit IP is approved.

### Variant: VPN users blocked after the rollout
VPN egress IPs change more often than office IPs, especially with cloud VPN providers. Subscribe to the provider's published egress list or assign static egress IPs before enforcing the restriction.

### Variant: Enterprise Grid versus Pro differences
IP restrictions are an Enterprise-tier feature with org-wide policies. On lower tiers you will not find the setting at all, which means the block the user sees comes from somewhere else (identity provider, MDM, or network firewall).

### Variant: contractors on home networks
Home IPs change constantly and should not be allowlisted one by one. Route contractors through the company VPN so they present an approved egress IP.

## Why this happens
A stolen session token or password is useless if the attacker cannot connect from an approved network. The IP restriction adds a network-level check on top of credentials: even a fully valid login is refused when it arrives from an unexpected place, which contains credential theft to networks you control.

## Edge cases and pitfalls
- Mobile and carrier IPs rotate constantly. Do not try to allowlist them; require VPN for mobile access instead.
- IPv6 egress ranges are easy to forget. If the office is dual-stack, approve both families or IPv6 users get blocked.
- An admin who enforces the restriction from a network they forgot to approve locks themselves out of the settings page. Keep a break-glass admin on a known-good network.
- IP restriction is not a substitute for SSO and MFA. It narrows where logins can come from, not who can log in.

## Provenance

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