Warp 2023.7.7.0 on Windows doesn't detect managed network

I’m currently testing Zero Trust in combination with the WARP client as a VPN replacment for a small business. It’s working great for the most part.

However, I’ve recently upgraded the WARP client to 2023.7.7.0 on Windows 11, and it isn’t now detecting when I’m in the office where there is a ‘beacon’ configured to signify this is a managed network. As a result the correct WARP settings profile isn’t being applied (along with some specific split tunnel exclusions).

My colleague who is testing with me is on the previous client version and is detecting the managed network correctly and therefore loading the correct split tunnel prefixes.

Could this be a case of a bug in the new client? Or is there something else I can check?

2 Likes

To answer my own question, the release notes for this version of the WARP client state the following under ‘Known Issues’:

Blockquote Managed network detection on certain Windows machines doesn’t consistently apply the expected profile upon network changes. We will address this issue in a future release.

I shall roll back to the previous version until the future release becomes available.

1 Like

Recent versions 2023.7.* don’t seem to work with macOS either with managed network configs.
In previous versions. the daemon.log would contain:

2023-07-31T22:58:27.280Z  INFO main_loop: warp::warp_service: Detected alternate network name=Some("TestNetwork")

and download the correct split tunnel config with include mode, while the new versions seems to lose connectivity (not pingable) to the IP with the managed network fingerprint server after WARP is connected. Shortly after the WARP connection, the detection failed with

2023-07-31T23:02:14.776Z  INFO main_loop: warp::warp_service: Detected alternate network name=None

And proceed to download the default config in exclude mode. The local IP with the fingerprint server is not accessible until WARP is disconnected.

Stuck with 2023.3.460.0 for now.

1 Like

Hi @net1,

have you also already tested with the beta (2023.7.243.1)? In the beta it is not explicitly listed as fixed, but it is also no longer listed as a known issue.

The latest beta doesn’t work either. With 2023.7.243.1, the local IP with the fingerprint server is still not reachable when WARP is connected. It’s will detect the network correctly again when WARP is disconnected. It has more debug logging though:

❯ grep 'Detected alt' *.log
daemon.log:2023-08-01T18:25:45.860Z DEBUG warp::warp_service::alternate_networks: Detected alternate network name=TestNetwork
daemon.log:2023-08-01T18:25:45.860Z  INFO main_loop: warp::warp_service: Detected alternate network, fetching new config name=Some("TestNetwork")
daemon.log:2023-08-01T18:25:46.386Z DEBUG warp::warp_service::alternate_networks: Detected alternate network name=TestNetwork
daemon.log:2023-08-01T18:26:36.216Z  INFO main_loop: warp::warp_service: Detected alternate network, fetching new config name=None
daemon.log:2023-08-01T18:26:47.076Z DEBUG warp::warp_service::alternate_networks: Detected alternate network name=TestNetwork
daemon.log:2023-08-01T18:26:47.076Z  INFO main_loop: warp::warp_service: Detected alternate network, fetching new config name=Some("TestNetwork")
daemon.log:2023-08-01T18:26:47.090Z DEBUG warp::warp_service::alternate_networks: Detected alternate network name=TestNetwork
1 Like

Thank you for the information and testing.

It would be really good to get a statement from a Cloudflare official when this feature will work properly again.

I mean one possibility is to stay on the old version, but that doesn’t evoke a very good feeling.

Cloudflare should be aware that this feature is indispensable in the enterprise environment.

Right. The funny thing is that you can NOT report bugs (the web UI of reporting problems directs to this community) if you’re on a free plan. Considering many are evaluating these features before deciding to upgrade to a paid plan, Cloudflare should reduce the friction of direct bug reporting and give people visibility of the status of such bugs.

2 Likes

I have done intensive testing (multiple endpoints, multiple users, multiple networks).

For me, it looks like this:

2023.3.450.0 > works

2023.7.160.0 (Stable) > does not work

2023.7.344.1 (Beta) > works

2 Likes

Still only 2023.3.450.0 works good with managed networks. I had issues described here

and I stumbled upon this this post and solved the problem. Issues were with Windows and Linux clients. On Android worked like a charm.
But still, after 6 months later CF developers can’t manage to make Managed networks to work as they should.

1 Like