We have had this issue and at present the only solution we found was to change our work subnets to use uncommon ranges such as 192.168.100.0/24 to reduce the likelihood of a collision. Not ideal if this is something you can’t control.
We are hoping split tunnel will allow us to map virtual networks to a different IP space at some point in the future. The feature seems well intentioned but sometimes it is hard to get it to work in practice.
We also had the issue that if a client is running the Cloudflare Tunnel then this doesn’t play nicely with the accessing other tunnels through the WARP client. This prevents us from using WARP internally without adding extra hosts to do the tunneling. In an ideal world we want a few hosts to do the tunneling to allow for failsafes.
We are also waiting for HTTP/3 support to go live, unless this has already. We believe this was causing issues with device posture as warp=on and gateway=on parameters were not always showing correctly. We also had issues with device posture policies detecting gateway=on on mobile and antivirus on Windows. In both cases it would appear to be working but when accessing the app a HTTP 403 forbidden response was given.
Hopefully someone at Cloudflare is working on and is aware of these issues as we see the WARP client gets a lot of updates and bug fixes.