IP Allowlist

Keelson can restrict access to an app by the source IP address of each request.

With an IP allowlist, only requests from approved addresses or networks can proceed to the app. This is useful for internal apps that should be reachable only from an office, a corporate VPN, or another controlled network.

When to use an IP allowlist

Allow access only through your office network or VPN.
Add a network boundary in addition to user authentication.
Prevent access from arbitrary networks even when someone knows the app URL.

An IP allowlist works best when your users connect through stable public egress addresses. If a network’s public address changes frequently, users may be blocked until the allowlist is updated.

How the restriction works

When an IP restriction is active, Keelson compares the request’s source address with the effective allowlist. A request is accepted only when the address belongs to at least one allowed IP address or CIDR range.

Requests from outside every allowed range are denied before they reach the application. A valid Keelson account does not bypass the network restriction.

The IP allowlist therefore supplements authentication; it does not replace authentication or app permissions.

IP restrictions do not apply to static sites, SPAs, and the static files of hybrid apps.

Configure an allowlist

Keelson stores allowed addresses in named access sources (shown as Sources in the console) at workspace scope. Each access source can contain one or more IP addresses or CIDR ranges. An app can either inherit the workspace’s default access sources or select its own set of access sources.

Use the Keelson console to configure the policy:

Open Workspace Settings, then open the security settings.
Under Allowed Sources, create an access source for an office, VPN, or other trusted network and add its IP addresses or CIDR ranges.
Add the access source to the workspace default if apps should inherit it.
To use a different policy for one app, open that app’s settings and select the access sources for its app-specific IP restriction.
Save the configuration.
Test from both an allowed network and a network that is not allowed.

Changes take effect without a redeploy. They normally take effect within two minutes. Changes made during an incident take effect after recovery.

An app-specific policy selects from access sources already registered in the workspace. Create or edit the address ranges in the workspace security settings first.

Before saving a restrictive policy, confirm that you have the correct public egress address for your office or VPN. The private address shown on a laptop, such as 192.168.x.x, is usually not the address Keelson sees.

Accepted address formats

An allowlist entry can represent one address or a CIDR network range.

A single IPv4 address, such as 203.0.113.10
An IPv4 CIDR range, such as 203.0.113.0/24
A single IPv6 address or an IPv6 CIDR range when your network uses IPv6

Examples

203.0.113.10 allows one public IPv4 address.

203.0.113.0/24 allows addresses in the corresponding 256-address IPv4 block. Use the narrowest range that covers the intended network.

If you are unsure which range represents your organization, ask the person who manages the office network or VPN. Do not broaden a CIDR range merely to make a failed test pass.

Test the policy safely

Test the allowlist after every change:

Open the app from an allowed office or VPN connection.
Confirm that an authorized user can sign in and reach the app.
Switch to a connection outside the allowed range, such as a separate mobile connection.
Confirm that Keelson denies the request before the app loads.

Keep an administrative console session available while testing so that you can correct an accidental lockout. Remember that a VPN may change the source address observed by Keelson.

Relationship to authentication

IP restriction and user authentication are separate checks. Keelson evaluates the IP restriction after sign-in and app permission, immediately before the request reaches the application.

For stronger protection of an internal app:

Keep authentication enabled.
Grant app permissions only to the members who need them.
Enable an IP allowlist when access should also be limited by network location.

Passing the IP check does not grant a user access. The user must still satisfy the app’s authentication and permission requirements.

Operational considerations

Prefer fixed public egress addresses for offices and VPNs.
Review entries when a network provider or VPN configuration changes.
Remove obsolete ranges instead of leaving temporary broad access in place.
Test both IPv4 and IPv6 paths if clients can use either protocol.
Record who owns each allowed range so it can be reviewed later.