I have two hosts connected to cf tunnel using cloudflared. I need to be able to connect to one from the other. They are in the same local subnet in azure and can ping each other.
I’m a bit unclear on the IP assignment aspect of this. In the warp to warp documentation it mkes reference to IPs in the CGNAT range:
Once enrolled, your users and services will be able to connect to the virtual IPs configured for TCP, UDP, or ICMP-based traffic. You can optionally create Gateway network policies to define the users and devices that can access the 100.96.0.0/12 IP space.
But when I look at a connected windows client and run ipconfig I see nothing of the sort:
If you’re trying to route through cloudflare then you need to specifically enable “Allow WARP to WARP connection” in your dashboard. That is step #3 in the guide linked above and at least with my setup caused the clients to allocate IPs in the CGNAT space.
If you don’t want to route through cloudflare then you could look at the split tunnel exclude setup and exclude the server IPs from WARP.
I ran into a couple issues and UI experiences that I’ll note here for anyone else finding the thread.
The copy/paste install commands for WARP in the tunnel config do not put the Cloudflare CA in place. You have to do this manually or not very much will work over the WARP tunnel. These lines should just be in the copy and paste block.
The WARP tunnel inherits the cloud-side configuration for the other clients (which is reasonable) but in my case since we are migrating to WARP from Tailscale to get MASQUE/FIPS support, my default is DOH only during initial roll out of the client, so I had to use warp-cli mode warp+doh to actually bring up the WARP tunnel. Until I did this, the tunnel appeared disconnected in the dashboard but warp-cli status would show connected, which was confusing.
The mandatory tunnel route field in the CF zero trust dashboard has no impact whatosever on what IP is assigned to the tunnel, nor to whether the IP that does get assigned is routable via CF WARP. It also does not do proper checks for overlaps. If you have one set for a /16 and try to create another with the same /16 it complains but if you change it to a /32 within that /16 it just sails through the checks. My second WARP tunnel was assigned an IP outside of its /32 and WARP clients can route to it just fine.
The IP that is actually assigned in the CGNAT block is not visibly exposed in the tunnels interface and instead you have to go to devices and look there. This seems like a real omission. If I am exposing services via tunnels I want to know the assigned IPs for those endpoints at a glance.
IMHO the way that ACLs, routes, endpoints, and exposing ports is managed is really not up to snuff. This probably works in a programmatic devops web application environment, and almost certainly has a much deeper feature set than other solutions, but as a replacement for a VPN it just does not feel finished. It took far longer to implement basic functionality for this that I now need to harden than to implement a fully locked down ephemeral authentication setup for containers in Tailscale.
When I compared it to the UI for ZeroTier it seems like it fails to present information in a concise single view that promotes comprehension - and ZeroTier’s UI pales in comparison to Tailscale. Tailscale has a single pane view that makes it easy to get the details on every authenticated node, and a single pane view of the JSON file that defines ACLs, routes, etc that can be modified programatically and has syntax checking when you submit changes manually. The UI would be a dealbreaker if I did not need FIPS.
The way that seats are purchased for CF Zero Trust is poorly thought out. I do not want to have to keep drilling into the UI to buy more seats instead of licenses just automatically being purchased and assigned. I dislike that the minimum time you can set for expiration for idle device/seat usage is so long because we have a lot of interns who are here for shorter than that setting.