Skip to content
Cloudflare Docs

Secure a private IP or hostname

You can configure a self-hosted Access application to manage access to specific IPs or hostnames on your private network.

Prerequisites

Add your application to Access

  1. In Cloudflare One ↗, go to Access controls > Applications.

  2. Select Add an application.

  3. Select Self-hosted.

  4. Enter any name for the application.

  5. In Session Duration, choose how often the user's application token should expire.

    Cloudflare checks every HTTP request to your application for a valid application token. If the user's application token (and global token) has expired, they will be prompted to reauthenticate with the IdP. For more information, refer to Session management.

    If the application is non-HTTPS or you do not have TLS decryption turned on, the session is tracked by the WARP client per application.

  1. To add an application using its private IP:

    1. Select Add private IP.

    2. In IP address, enter the private IP or CIDR range that represents the application (for example, 10.0.0.1 or 172.16.0.0/12).

    3. In Port, enter a single port or a port range used by your application (for example, 22 or 8000-8099).

      Comma-separated lists of ports (such as 80, 443) are not supported. To add multiple ports for a specific IP, you can select Add private IP and repeat the IP address with the other port. Alternatively, create a new Access application for the other port.

  2. To add an application using its private hostname:

    1. Select Add private hostname.
    2. In Hostname, enter the private hostname of the application (for example, wiki.internal.local). You can use wildcards with private hostnames to protect multiple parts of an application that share a root path.
    3. In Port, enter a single port or a port range used by your application (for example, 22 or 8000-8099).

  3. Add Access policies to control who can connect to your application. All Access applications are deny by default -- a user must match an Allow policy before they are granted access.

  4. Configure how users will authenticate:

    1. Select the Identity providers you want to enable for your application.
    2. (Recommended) If you plan to only allow access via a single IdP, turn on Instant Auth. End users will not be shown the Cloudflare Access login page. Instead, Cloudflare will redirect users directly to your SSO login event.
    3. (Recommended) Turn on WARP authentication identity to allow users to authenticate to the application using their WARP session identity. We recommend turning this on if your application is not in the browser and cannot handle a 302 redirect.

  5. Select Next.

  6. (Optional) Configure App Launcher settings for the application.

  7. (Optional) Turn on Allow clientless access to allow users to access this private hostname or IP without the WARP client. Users who pass your Access policies will see a tile in their App Launcher which points to a prefixed URL such as https://<your-teamname>.cloudflareaccess.com/browser/https://wiki.internal.local/. The link will route traffic to the application through Clientless Web Isolation. This setting is useful for users on unmanaged devices or contractors who cannot install a device client.

  8. Under Block page, choose what end users will see when they are denied access to the application:

    • Cloudflare default: Reload the login page and display a block message below the Cloudflare Access logo. The default message is That account does not have access, or you can enter a custom message.
    • Redirect URL: Redirect to the specified website.
    • Custom page template: Display a custom block page hosted in Cloudflare One.

  9. Select Next.

  10. (Optional) Configure advanced settings:

    These settings only apply to private hostnames and require Gateway TLS decryption.

  11. Select Save.

Users can now connect to your private application after authenticating with Cloudflare Access.

Authentication flow

HTTPS applications

If Gateway TLS decryption is turned on and a user is accessing an HTTPS application on port 443, Cloudflare Access will present a login page in the browser and issue an application token to your origin. This is the same cookie-based authentication flow used by self-hosted public apps.

If Gateway TLS decryption is turned off, session management is handled in the WARP client instead of in the browser.

Non-HTTPS applications

The WARP client manages sessions for all non-HTTPS applications. Users will receive an Authentication required pop-up notification from the WARP client. When the user selects the notification, WARP will open a browser window with your Access login page.

Ensure that your operating system allows notifications for WARP. Your device may not display notifications if focus, do not disturb, or screen sharing settings are turned on. To turn on client notifications on macOS devices running DisplayLink software, you may have to allow system notifications when mirroring your display. For more information, refer to the macOS documentation ↗.

Order of precedence

Access vs Gateway policies

By default, Cloudflare will evaluate Access application policies after evaluating all Gateway network policies. To evaluate Access applications before or after specific Gateway policies:

  1. In Cloudflare One ↗, go to Traffic policies > Firewall policies. In Network, create a Network policy with the following configuration:

    SelectorOperatorValueAction
    Access Private AppisPresentAllow

  2. Update the policy's order of precedence using the dashboard or API.

Private hostname vs private IP

An Access application defined by a private hostname takes precedence over an Access application defined by a private IP. For example, assume App-1 points to wiki.internal.local and App-2 points to 10.0.0.1, but wiki.internal.local resolves to 10.0.0.1. Users who go to wiki.internal.local will never match App-2; they will be allowed or blocked strictly based on App-1 Access policies (and Gateway policies).

Limitations

Browser Isolation is not compatible with apps on non-443 ports

Browser Isolation is not compatible with self-hosted private applications that use private IPs or hostnames on ports other than 443. Trying to access self-hosted applications on non-443 ports will result in a Gateway block page.

To use Browser Isolation for an application on a private IP address with a non-443 port, configure a private network application instead.

Google Chrome restricts access to private hostnames

Starting with Chrome 142 ↗, the browser restricts requests from websites to local IP addresses, including the Gateway initial resolved IP CGNAT range (100.80.0.0/16). Because this range falls within 100.64.0.0/10, Chrome categorizes these addresses as belonging to a local network. When a website loaded from a public IP makes subrequests to a domain resolved through an initial resolved IP, Chrome treats this as a public-to-local network request and displays a prompt asking the user to allow access to devices on the local network. Chrome will block requests to these domains until the user accepts this prompt.

This commonly occurs when an Egress policy matches broadly used domains (such as cloudfront.net or github.com), causing subrequests from public pages to resolve to the 100.80.0.0/16 range.

Iframes

If the affected request originates from within an iframe (for example, an application embedded in a third-party portal), the iframe must declare the local-network-access permission for the browser prompt to appear in the parent frame:

  • Chrome 142-144: Use the allow="local-network-access" attribute on the iframe element.
  • Chrome 145+: The permission was split into allow="local-network" and allow="loopback-network".

If iframes are nested, every iframe in the chain must include the appropriate attribute. Since third-party applications control their own iframe attributes, this may not be configurable by the end user.

Workarounds

To avoid this issue, choose one of the following options:

  • Override IP address space classification (Chrome 146+): Use the LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome Enterprise policy to reclassify the 100.80.0.0/16 range as public. This is the most targeted fix because it only changes the classification for the initial resolved IP range rather than disabling security checks entirely.
  • Allow specific URLs (Chrome 140+): Use the LocalNetworkAccessAllowedForUrls ↗ Chrome Enterprise policy to exempt specific websites from Local Network Access checks. Note that https://* is a valid entry to disable checks for all URLs.
  • Allow specific URLs (Chrome 146+): Use the LocalNetworkAllowedForUrls ↗ Chrome Enterprise policy, which replaces LocalNetworkAccessAllowedForUrls starting in Chrome 146.
  • Opt out of Local Network Access restrictions (Chrome 142-152): Use the LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome Enterprise policy to completely opt out of Local Network Access restrictions. This is a temporary policy and will be removed after Chrome 152.
  • Disable the Chrome feature flag: Go to chrome://flags and set the Local Network Access Checks flag to Disabled. This approach is suitable for individual users but not for enterprise-wide deployment.