Network policy

The network policy is a workspace-wide IP allowlist and IP blocklist enforced at every customer-facing surface: sign-in (SSO and password), the dashboard, the public API, SCIM. Coupled with SSO and MFA, it gives you a third dimension of access control — what the credential is, what proves you have it, and where the request is coming from. Most workspaces start in report-only mode for a week, then flip to enforcing once the allowlist is dialed in.

TL;DR — Open Settings → Security → Network policy. Add the corporate VPN / office CIDR ranges to the allowlist, optionally block known-hostile ranges, run a Test IP against your own address, switch to enforcing. Locked-out users see a clear /network-blocked page with the right next step.

Before you start

• You must be a Workspace admin.
• Gather your corporate egress IPs: VPN exit ranges, office static IPs, cloud NAT ranges, anywhere your team's traffic legitimately comes from.
• Have a lockout plan. If you misconfigure and lock yourself out, you'll need to reach your AxisSynapse account team for a one-time bypass. Avoid this — start in report-only mode.
• Decide whether to enforce IPv6. The platform handles both IPv4 and IPv6, plus IPv4-mapped-IPv6 cross-match — but your inventory of corporate ranges has to cover both stacks.

Configure the policy

1. 1

   Open Settings → Security → Network policy

   The page shows the current mode (off / report-only / enforcing), your detected IP, and the rule lists.

2. 2

   Add allowlist rules

   Click Add allowlist rule. Paste a CIDR (e.g. 198.51.100.0/24 or 2001:db8:abcd::/48), label it, save. Repeat for every legitimate egress range.

3. 3

   Optionally add blocklist rules

   The blocklist is evaluated before the allowlist — a hit on blocklist short-circuits to refusal even if the allowlist would have accepted. Use for known-hostile ranges.

4. 4

   Run Test IP

   Type any IP into Test IP. The form shows whether the policy would accept or refuse it and which rule matched.

5. 5

   Switch mode to "Report-only"

   Report-only logs every would-be refusal to the audit log without blocking. Leave it on for a week to discover legitimate ranges you missed.

6. 6

   Review the report-only findings

   Filter Security Console for account.network_policy.blocked — each row carries the source IP, the affected user, and the surface that was reached. Add legitimate ranges to the allowlist; ignore (or blocklist) the rest.

7. 7

   Switch mode to "Enforcing"

   Refusals now block the request. The user sees the /network-blocked page; admins see the same audit lines they saw in report-only mode.

IPv4, IPv6, mapped addresses

AxisSynapse normalizes every inbound address to its canonical form before matching against the rule list. The practical implications:

The blocked-page experience

A blocked user sees /network-blocked — a static page hosted at the workspace origin that:

• Names the blocked IP so the user can paste it to their admin.
• Surfaces the admin contact the workspace configured.
• Does not reveal why the request was blocked (allowlist miss vs blocklist hit) — keeping the surface flat avoids leaking inventory.
• Offers a request-bypass form if the workspace has enabled it. The admin reviews from Settings → Security → Bypass requests.

Admin bypass

An admin can issue a one-time bypass for a user who's legitimately locked out. The bypass is single-use, expires in 30 minutes, and is audited at critical severity.

1. 1

   Open Settings → Security → Network policy → Bypass requests

   Pending requests appear here.

2. 2

   Review the request

   The row shows the user, the source IP, the surface they tried to reach, and the timestamp.

3. 3

   Approve or refuse

   Approve issues a one-time, IP-bound bypass token (step-up protected, see Step-up authentication). Refuse closes the request silently from the requester's side.

Every field, explained

What appears in the audit log

• TENANT_NETWORK_POLICY_UPDATED — mode changes (off / report-only / enforcing).
• TENANT_NETWORK_RULE_ADDED / ..._REMOVED — per-rule lifecycle.
• ACCOUNT_NETWORK_POLICY_BLOCKED — every refusal. In report-only mode these still fire; the affected user is not blocked, only recorded. Aggregate to surface ranges to add.
• ACCOUNT_NETWORK_POLICY_ADMIN_BYPASS — every bypass approval. Always review — bypasses are exceptions, not steady state.

Common gotchas

• "I added our VPN's range but users on the office wifi are blocked." Office wifi has its own egress IP (often a static NAT, sometimes a load-balanced range). Add that range too.
• "My users on home internet keep getting blocked." Personal ISPs use dynamic IPs — you can't allowlist them. Either require VPN, or accept that home connections need a bypass.
• "Bypass tokens are being approved and the user still can't get in." The bypass is bound to the IP that requested it; if the user switched networks between requesting and using it, the token rejects. They re-request from the same network.
• "My IPv6 rule isn't matching." Confirm the inbound request is actually IPv6 — many corporate networks tunnel to IPv4 even when the client has IPv6. Use Test IP to disambiguate.
• "Report-only mode logged thousands of blocks during the weekend." That's normal — every public scan and crawl hits the surface. Focus on rows tied to real user IDs; the rest are noise.

Troubleshooting

| Error code | What it means | Fix | |---|---|---| | NETWORK_POLICY_BLOCKED | The request was refused by the policy. | Add the source range to the allowlist, or use admin bypass. | | NETWORK_RULE_INVALID_CIDR | The CIDR didn't parse. | Use canonical CIDR notation (198.51.100.0/24). | | NETWORK_RULE_RANGE_TOO_BROAD | A CIDR larger than the platform-allowed maximum was submitted. | Break the range into smaller, intentional CIDRs. | | NETWORK_BYPASS_EXPIRED | The bypass token has elapsed. | Re-request a bypass. | | NETWORK_BYPASS_IP_MISMATCH | The bypass token was issued for a different IP than the redeeming one. | Re-request from the current IP. |