Access Policies

Access policies define project-wide runtime requirements for rstream tunnels. They are configured from the project settings page and enforced by the engine when tunnels are created and when published traffic reaches the edge.

Project settings are bounds. If a tunnel request also specifies trusted IPs, GeoIP restrictions, authentication settings, or a TLS minimum version, the engine keeps the intersection with the project policy and rejects incompatible tunnel requests. When a setting can safely fill a missing tunnel property, the engine applies it.

The same project-level cryptographic settings also constrain project-scoped edge entrypoints that terminate TLS, such as the engine API and control channel surfaces bound to the project endpoint.

Public access policy

The public access policy controls how a project handles public tunnels.

allowed permits public tunnels with or without authentication. auth-required permits public tunnels only when authentication is enabled. If a tunnel request does not specify an auth mode, Basic projects default to token auth, while Pro and Enterprise projects default to both token auth and rstream Auth. forbidden rejects public tunnels and only allows private tunnels.

allowed and auth-required are available on Basic, Pro, and Enterprise projects. forbidden is available on Pro and Enterprise projects.

Trusted IPs

Trusted IPs restrict published traffic to specific client IP addresses or CIDR ranges. Entries accept IPv4, IPv6, and CIDR values. The engine normalizes entries, removes duplicates, and evaluates the policy before traffic reaches the upstream service.

When both the project and a tunnel define trusted IPs, both policies must match. The tunnel cannot broaden the project policy. Trusted IPs are available on Pro and Enterprise projects.

GeoIP restrictions

GeoIP restrictions limit published traffic by country code derived from the client IP address. Entries use ISO 3166-1 alpha-2 country codes and are normalized to uppercase.

GeoIP restrictions are evaluated together with trusted IPs when both are configured. A request must satisfy every applicable project and tunnel policy. GeoIP restrictions are available on Pro and Enterprise projects.

Minimum TLS version

The minimum TLS version controls the published tunnel endpoint, whatever the tunnel protocol. Managed projects default to allowing TLS 1.2 and TLS 1.3 for published traffic. Setting the project minimum to TLS 1.3 requires every published tunnel in the project to satisfy that minimum version.

This setting is available on Basic, Pro, and Enterprise projects.

Post-quantum key exchange

Post-quantum key exchange controls the TLS group policy for terminated TLS handshakes in the project.

preferred prioritizes hybrid post-quantum groups while keeping classical groups available as fallback. required accepts only hybrid groups and enforces TLS 1.3 at runtime. The optional NIST and FIPS toggle restricts hybrid and fallback selection to the P-256 and P-384 families.

The stored tunnel setting is left unchanged. When required is enabled, the engine computes an effective runtime minimum of TLS 1.3 even if the tunnel or project minimum TLS version remains set to TLS 1.2.

This policy applies only when the edge terminates TLS. It therefore affects terminated HTTPS, TLS, and QUIC surfaces for the project, but not TLS passthrough tunnels. Published DTLS tunnels cannot satisfy the required mode because the current DTLS surface remains DTLS 1.2.

Encrypted Client Hello

Encrypted Client Hello controls whether terminated TLS surfaces in the project prefer or require ECH.

preferred enables ECH when the client supports it and DNS provides a usable ECH configuration, while keeping the standard TLS fallback path available. required rejects TLS handshakes that do not negotiate ECH and therefore accepts only TLS 1.3 traffic on the affected terminated surfaces.

ECH is runtime-only and does not rewrite the stored minimum TLS version. As with post-quantum required, the engine computes an effective minimum of TLS 1.3 when ECH is required.

This policy applies only when the edge terminates TLS. It affects terminated HTTPS, TLS, and QUIC surfaces for the project, but not TLS passthrough tunnels. Published DTLS tunnels cannot satisfy the required mode. ECH also depends on valid DNS HTTPS or SVCB publication for the project hostname and on engine-side ECH configuration for the cluster.

Relationship with tokens

Access policies apply at the project level. Tunnel grants apply at the credential or token level. The engine applies both.

For example, a project can require authenticated public access, while a token can be limited to creating HTTP tunnels for that project. The token cannot bypass the project policy, and the project policy does not grant any token permission by itself.