Connect two devices privately with Cloudflare Mesh

Connect two laptops, phones, or desktops by enrolling both devices in Cloudflare Mesh. Each device receives a private Mesh IP and can reach the other device without a Mesh node.

Use two devices supported by the Cloudflare One Client. One device must run a service that the other device can test, such as SSH or HTTP.

Before you enroll the devices, configure the required account settings. You do not need to create a Mesh node for device-to-device connectivity.

Use the Mesh dashboard to find the installer and organization name:

The workflow provides installation information. It does not enroll the device automatically. For manual enrollment instructions, refer to Enroll a device.

Do not use interactive CLI enrollment on a device without a browser. Instead, create a Service Auth enrollment policy. Configure the organization, auth_client_id, and auth_client_secret managed deployment parameters.

For platform-specific installation methods and configuration file locations, refer to Managed deployment. For a complete Linux example, refer to Deploy the Cloudflare One Client on headless Linux machines.

This method works on supported Windows, macOS, and Linux systems. Service-token devices use the shared identity non_identity@<team-name>.cloudflareaccess.com. Policies based on identity provider users or groups do not apply to these devices. To assign device profiles, use the expression identity.service_token_uuid == "<SERVICE_TOKEN_ID>", where <SERVICE_TOKEN_ID> is the service token resource UUID (id), not its auth_client_id. Place this Service Token selector before broader OS or email profiles. Use the shared non-identity email only when all Service Auth devices should match the profile.

After enrollment, the device receives a Mesh IP. The device appears in the participant table under Networking > Mesh.

Repeat the enrollment procedure on the second device. Use the same Cloudflare account and Zero Trust organization.

Confirm that both devices appear as Online under Networking > Mesh. Record the Mesh IP of the device that runs the service.

Check the device profile applied to each device. The profile must use Traffic and DNS mode and route your Mesh IP range through Cloudflare.

• In Split Tunnels Include mode, include 100.96.0.0/12.
• In Split Tunnels Exclude mode, make sure neither 100.96.0.0/12 nor a parent range such as 100.64.0.0/10 is excluded.

Use your custom device IP range instead of 100.96.0.0/12 if you changed the default. For configuration instructions, refer to Split Tunnels.

Configure the destination device firewall to accept the service traffic. Windows Firewall blocks inbound traffic from 100.96.0.0/12 by default. Add a rule that allows the required protocols and ports from the Mesh IP range.

On macOS and Linux, verify that custom firewall rules permit the same traffic. You do not need to open the service to the public Internet.

Test the application protocol that you intend to use. For example, test a service that listens on TCP port 22:

nc -vz <DESTINATION-IP> 22

Test-NetConnection <DESTINATION-IP> -Port 22

Replace <DESTINATION-IP> with the destination Mesh IP or private IP. Replace port 22 or <PORT> with the port used by your service.

If you turned on the ICMP Gateway proxy, you can also run ping <DESTINATION-IP> as a diagnostic check. A connected participant status does not confirm that the application protocol can reach the destination.

Use the destination device Mesh IP for <DESTINATION-IP>.

Use Gateway network policies to control which sources can reach each destination IP and port. You can combine network policies with device posture checks for enrolled client devices.

Review allowed and blocked connections in Gateway network logs. Client device traffic includes the enrolled user identity. Mesh node traffic uses the identity warp_connector@<your-team-name>.cloudflareaccess.com.

If a participant is online but the service is unreachable, refer to Troubleshoot Cloudflare Mesh connectivity.

• Connect two servers by their Mesh IPs.
• Connect two private networks through routed subnets.
• Configure routes for devices that cannot run the client.