Warp Client Split-Tunneling Exclusions Woes - Local and Remote Access

(First time poster)

We’re new to Cloudflare and are trying to replace our traditional VPN client with Warp client using the Warp client in ZeroTrust access mode.

We were able to successfully setup remote access from a laptop to connect back to our corp. office server on our internal/private network via Warp client / cloudflared on the server (Access :arrow_right: Applications:arrow_right: Private Network). Great - however, we noticed that when a Warp client returns to the office and connects to the local/internal network, it does not recognize the new context of being in the same network as the server and continues to access to the server via the Cloudflared tunnel, instead of just directly accessing the server on the subnet they share.

In Cloudflare Zero Trust management panel, we then configured the internal private within Settings :arrow_right: Networks :arrow_right: Split Tunnels :arrow_right: Exclude IPs and domains which makes it then behave correctly when inside the private network, but breaks the remote access to the server.

If we delete the Split Tunnel network exclusion, remote access works again, but local Warp clients flow through Cloudflare to access local server.

So - the big question: Is there a way for Warp clients to automatically/transparently bypass Cloudflare to access internal network resources when connected on the LAN, while continue to be able to access internal networks / servers remotely via Cloudflare from public internet?

The Warp client is working great for DNS/HTTP filtering policies, device posture, and this remote access / split-tunneling issue is really the last hurdle to overcome for us to fully adopt it.

2 Likes

Hello @AlexDG ,

Your post is clear and, to the best of my knowledge, there’s no current workaround. Right now the way to have it working is to always go through the Cloudflare network (hence Zero Trust WARP Client and Cloudflare Tunnel) regardless of the physical network you are in.

I’ve shared this internally, where I believe they are already aware of this, so maybe there’ll be some update here on addressing this in the future to make it better!

Thank you for the prompt reply.

This really seems like an essential feature, though - as Windows domain-joined computers should be able to fully communicate with their on-premise AD Domain Controllers on TCP, UDP, and ICMP which is not possible while connected with the Warp client.

Please add to feature request list!

Speaking of… is there a specific place where it is best to make feature requests for Cloudflare products?

Yes, thank you for the clear and descriptive feature request. You can check out this post for a bit more detail on how we’re thinking about this problem.

As for feature requests, you can always post them in community which we monitor, but for requests specific to Cloudflare Tunnel you can share them on Github as well.

1 Like

Hi,

Has there been any update on the new ‘Beacon’ that was proposed. The idea being that this beacon would be installed on the local LAN so that when a user’s Warp client was local it would detect the beacon and stop routing local traffic via Cloudflare.

We have some clients with a large user base that work either in the office or from home, but there is only ever a small percentage working from home at any one time. Their applications are mostly on the internal network, so routing local traffic through Cloudflare would put a strain on the WAN bandwidth to the extent that I’m not confident recommending this to larger clients.

Without some ability to intelligently route local traffic we would need to recommend Cloudflare only to clients that have a remote majority.

Thanks,

Mark

Eagerly waiting for this → “In the office” exclusion