Users cannot access internal network using WARP client

I’ve setup a Linux VM with a tunnel that includes a /24 internal network range. I’ve ran tests on the tunnel to ensure it can connect to certain IP’s in this range which works fine. The tunnel is up (cloudflared running as a service) and there are no errors with that. The config file has warp-routing enabled. I don’t have any ingress rules in the config file.

In the teams web UI I have setup a policy to allow traffic to this /24 network. HTTP filtering is enabled, and I’ve removed the /24 from the split tunnels list.

I have a WARP client running on a dedicated laptop with ‘Gateway with WARP’ ticked. I’m logged in with my user and it is connected without any errors. My device is also visible/connected as seen in the teams web UI.

I would expect this laptop to be able to ping/connect to various IP’s in the /24 but for some reason it cannot. I’ve been through the docs a number of times and cannot see what I might be missing. Other settings in the Teams UI work such as an HTTP block policy.

Any help greatly appreciated.

Hello. I am having the exact same issue (the CIDR block for my private network is Everything looks like it should be working, but it doesn’t. I tried pinging as well as spinning up a dummy HTTP server; it answers when accessed through its public IP, but not through its private IP.

I dug in the WARP logs and found this line:

[2021-08-04T06:21:39Z DEBUG warp::warp_service::ipc_handlers] Ipc response: 9; Settings: Always On: true; Mode: Warp; Gateway Unique Id: 3f0213a061b6cda10da34e0913892080; Cloudflare for Families: Off; Disabled for WiFi: false; Disabled for Ethernet: false; Enable DNS logging: false; Excluded routes:; (Local network); (Local network); (Local network); (Local network); (Local network); (Local network); (Local network); (Local network); (Local network);   fe80::/10 (Local network);   fd00::/8 (Local network);   ff01::/16 (Local network);   ff02::/16 (Local network);   ff03::/16 (Local network);   ff04::/16 (Local network);   ff05::/16 (Local network); Fallback domains:;   intranet ();   internal ();   private ();   localdomain ();   domain ();   lan ();   home ();   host ();   corp ();   local ();   localhost (); ();   invalid ();   test (); Teams Registration by Daemon: false

Relevant part is Excluded routes:; (Local network); (Local network); . Note that the first block contains my private network.
This is odd, because I removed both of these blocks from the split tunnels before that, and even restarted the WARP client since. Also, the UI does not show these routes as excluded; see screenshot.

I’m at loss. I expect this to be a bug from WARP, where IPs that should be ignored are ignored anyway.

Here’s a few things I’ve learned along the way:

  1. The tunnels currently only support TCP traffic. This means DNS and ICMP won’t work. The knock on effect of this is that you cannot a) ping and b) send queries to your internal DNS server. The workaround for this (so I’m told) is to head to Policies > DNS and create an ‘Override’ rule. That sounds straightforward enough although I’ve not been able to get this to work at all.

  2. I’ve also noticed the WARP logs are not consistent with whats in the split tunnels configuration. I can see ranges in my WARP logs which I have specifically removed from the split tunnels config in the Teams UI. However, if I check the ‘Excluded IPs’ list in WARP they are not displayed. Given that it works I am inclined to trust this and not what is displayed in the logs.

  3. IP’s on their own work/DNS does not. I can RDP/SSH and browse using IP addresses and this all works fine. It’s this DNS Override thing I am struggling with.

Here’s an interesting quote from a CF Sales guy I’ve been chatting to:

“As the WARP to cloudflared tunnel currently doesn’t support proxying UDP traffic (just TCP), resolving internal DNS doesn’t work (we plan to support UDP traffic in Q4). The way around this is to recreate your internal DNS records as “DNS override” policies in the Gateway section of the product. You’ll be able to say for “app.local, override to” as an example.”

1 Like

@swilliams already lined up an excellent answer while I was writing. You can use netcat against a TCP port on a private origin to test it out.

I want to add a few extra details:

  • Please check and it should say “gateway=on” for everything to work. Gateway Filtering must be enabled: → Settings → Network → Proxy (enabled)
  • Make sure your origin tunnel is running and that it belongs to the same account as the WARP Team you are accessing from. The tunnel logs should say “Warp-routing is enabled”.
  • Check that you have an IP route pointing to your tunnel via cloudflared tunnel route ip show.
  • If it still fails, check your tunnel logs when you access it, is there anything there?
1 Like

Thank you very much @swilliams and @nuno.diegues for your help.

I had done everything you both mentioned, and it was not working.
At your suggestion @nuno.diegues I checked and it was showing “gateway=off”, even though WARP with Cloudflare for Teams was enabled (see screenshot) and my device was showing up in the settings :slightly_frowning_face:

Then I disconnected from my WiFi, reconnected, logged off from WARP, logged in again, and it now works! This is doubly surprising because I did that before, and even restarted my computer twice.

Anyway, I am glad this was sorted out. Thanks again for the help; if it ever shows up the same weird behaviour I’ll report it here.

@yacine glad that it works for your internal IP addresses. I’d be really curious to know if you ever get DNS working (not sure if that’s a requirement of yours - I’m just curious). For me, we are trying to replace our VPN using this CF service because it seems great and having DNS working is a dealbreaker. We can’t have people browsing or RDP’ing etc to IP’s because DNS does not work. Most of our staff will only know the hostnames and not the IP’s. And the DNS Override policy that is suggested as the solution to this just doesn’t seem to work.

I have an open ticket with CF about the DNS Override policy which has been going on for weeks. I hope they can resolve it.


We do not have private DNS as a requirement. Instead, we have a zone dedicated to internal tools (, and set everything up there.
There is nothing that prevents us from setting an A record that points to a private IP address. Sure, the record is going to be public, but without WARP set up, it is meaningless.
I imagine that on your end, it is about the resolution with a DNS server in the private network. That I can’t help you with.