When connecting using ZeroTrust WARP on my Android, I can access devices on the defined private network. However, on my mac when doing the same thing, the same IP’s time out and show nothing.
Could you please visit https://cloudflare.com/cdn-cgi/trace while connected to WARP on your Mac and share the output?
Sure!
This is the output of that when my Mac is connected via WARP.
fl=138f27
h=cloudflare.com
ip=2a09:bac5:6239:569::8a:1b
ts=1684606364.267
visit_scheme=https
uag=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36 Edg/112.0.1722.48
colo=SMF
sliver=none
http=http/3
loc=US
tls=TLSv1.3
sni=plaintext
warp=plus
gateway=off
rbi=off
kex=X25519
and this is the same site on my Android phone via WARP
fl=4f626
h=cloudflare.com
ip=2a09:bac1:76c0:28::4:272
ts=1684606436.553
visit_scheme=https
uag=Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Mobile Safari/537.36
colo=SJC
sliver=010-tier1
http=http/2
loc=US
tls=TLSv1.3
sni=plaintext
warp=plus
gateway=off
rbi=off
kex=X25519
I see that your Mac is connecting over HTTP/3, which uses UDP instead of TCP. Do you have UDP proxying enabled in your network settings?
I don’t have any proxy enabled in network settings.
On another note when my router uses the same local IP range as is configured in zero trust (10.0.0.0/24) mac does not connect to the private devices (android doesn’t seem to mind this). However, when the router’s local IP range is different (192.168.1.0/24) than the zero trust range (10.0.0.0/24) macos allows me to connect. Could this be contributing to or caused by the HTTP/3 issue? Maybe there is some mac setting that routes subnet routes internally rather than allowing cloudflare to handle them or something? idk.
Oh I never enabled the firewall in zero trust.
If the proxy is not enabled in Zero Trust network settings, then connections will not be routed through the tunnel to your private network. I believe TCP proxy is enabled by default, but you have to manually enable UDP.
I enabled UDP under the proxy settings and it did not make any difference. I still believe it’s because of the local subnet tbh, because when I change my router settings to use a completely different ip address space than zero trust, it works. Even on my mac with HTTP/3.
For now, I simply moved the IP ranges for zero trust up by 65,536
So 10.0.0.0/24 is now 10.1.0.0/24, this should prevent any IP overlap with the local routing tables when connecting (even though the local routing tables are not needed by me).
Thank you for the help Albert!
Hi @nasrj3
I have the same issue, can you please explain what you did to solve it?
Thanks.
Hey woodyard!
basically in the macbooks network routing table, the routers subnet takes priority over cloudflares subnet.
If my private network that proxies through cloudflare uses the IP of say 10.0.0.1/16, then cloudflare will add a routing table entry into my macbook’s network config.
However, if you connect to wifi and the wifi router also happens to use the 10.0.0.1/16 subnet, then the macbook will have conflicting routing table entries and will prefer the wifi routers entries.
One solution is to simply change the private ip cloudflare proxies. you can make it 192.168, or 10.0.0.1 or whatever you want.
the second solution (this is on the one i currently use) is to manually modify the macbooks network routing table to delete the wifi routers entries for 10.0.0.1/16 and replace it with a more strict subnet. say 10.0.0.1/24. What this means is that now the wifi router will handle all requests from IP address 10.0.0.1 → 10.0.0.255 and it will leave IP’s 10.0.1.0 → 10.0.255.255 for cloudflare to handle.
If you want cloudflare to cover the entire IP range for 10.0.0.* you can just delete the wifi routers entry and replace it with 10.0.0.1/32, which basically only routes the ip “10.0.0.1” through the wifi router, the other 10.0.0.* ip’s will then be handled by cloudflare.
You also could of course write a script that does this automatically (as did we) but I cannot share that for privacy reasons. (google is your friend).
If you need more of an in depth explanation or even an ELI5, let me know, i’m happy to help :).
1 Like
Thank you for your explanation!
My setup is at home so a pretty simple setup with 10.10.1.0/24 as the subnet and a docker instance running a tunnel that makes the subnet available to my devices even if I am not at home.
So I am not sure if I understand the first solution you mention, where I could just change the private ip Cloudflare proxies.
I just want the WARP client to handle “all” trafic so it is routed through CF and then back through the tunnel, even if I am at home. It works like a charm on Windows.
I guess I have to look at fiddling with the routing table on the mac, I am just not so confident in doing so, so if you happend to have some sort of anonymized version of your script, I would be happy to get some inspiration from it.
Thanks again for taking your time!
EDIT:
If I run ‘sudo route delete -net 10.10.1.0/24’ in a terminal window, it acts like I want it to. But after a restart, the route is back which breaks it again. So question is if it is possible to run this command automatically when the WARP client connects? Is that what you do?
EDIT 2:
I added 10.10.1.1/32 to the exclude list under Settings->Warp Client->(profile)->Split tunnels and that also seemed to do the trick.
So now I have this routing table (like default) and it works and routes all trafic through CF when WARP client is connected:
Check the network interface through which the Cloudflare warp client is connected or tunnelled. In my case, when I run the command ifconfig, I get the below network interface.
My tunneling virtual network in this case is utun4.
bash $ ifconfig
...
...
utun4: flags=1234<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet X.X.X.X --> Y.Y.Y.Y netmask 0xffffffff
inet6 AAAA::BBBB:CCCC:DDDD:EEEE%utun4 prefixlen 64 scopeid 0x19
inet6 AAAA:BBBB:CCC:DDDD:EEEE:FFFF:GGGG:HHHH prefixlen 128
nd6 options=123<PERFORMNUD,DAD>
Now, add the private network interface that you added in the private network tunnel address to use the cloudflare gateway interface.
sudo route add 10.0.0.1 -interface utun4
This should tunnel your private network cloudflare tunnel to use the route through the cloudflare gateway.