I want to use zero trust instead of VPN to access these servers. Currently out VPN IP is allowlisted for SSH in azure. How to replace this with Zero Trust? I have created zero trust team, and users. I’ve installed and able to connect warp. Is there any IP range to allowlist in azure?
You actually don’t need WARP on the server. Instead, you’ll need two things:
- install a Cloudflare Tunnel (not WARP) on the Azure VM.
- install Cloudflare WARP on your local client
There’s a good setup guide here, which should be applicable for your use-case.
2 Likes
I didn’t install warp on VM. The SS shows my own pc. I have 30 VMs do I need to install tunnel for each one? The setup guide has unclear spots for me. What about firewall rules? Do I need to open 22 port to world?
As long as they are on the same subnet you should be able to install Tunnel on one and SSH to them all. No ports need to be opened on the Azure Firewall but SSH should be running on them all and accessible from the “jump host”.
You should be able to follow the “Connect a Network” guide linked in the link I sent above 
I’m trying to do this exact same thing, but am getting really stuck. I’ve got:
- An Azure VM in a subnet (10.0.0.0/8)
- Cloudflare Tunnel running on that VM, successfully showing a connection on the dashboard
- A Private Network configured on that Tunnel for 10.0.0.0/8 (I want to hit everything on that subnet)
- The Cloudflare WARP desktop application, signed into Zero Trust
- The WARP client profile set to Include Split Tunnels, to include 10.0.0.0/8
But it’s not working: I cannot connect to the VM (10.0.0.4) from my local machine, even though WARP is running.
I’m familiar with VPNs and split tunnels, and am currently using Tailscale (which auto-creates routes for each IP on the network to ensure traffic routes through its wireguard connection), but I see no such thing happening for WARP.
All attempts to tracert 10.0.0.4 break out to my ISP, when (in my lizard brain) they should be routing to whatever tunnel WARP is creating on my machine, so it can transit out that way.
Am I doing something wrong here?
Have you checked that the particular VM in that subnet allows talking to the rest of the IP addresses within the subnet? For E.g. check the Azure Network Security Group?
Yes, and they do. But even if they didn’t, I should be able to reach the VM that the agent is running on - and I can’t.
