Alternative Endpoint

[DevinWinata]

Hello,
I just so happened to found this Cloudflare Zero Trust Docs (I haven't try dive deep into Zero Trust Docs) while googling about Cloudflare WARP Endpoints and IPs.
And I noticed on section WARP ingress IP, the IP is different from engage.cloudflareclient.com (162.159.192.1) and it's IP range.
IPv4 Range: 162.159.193.0/24
IPv6 Range: 2606:4700:100::/48
And I tried with IP 162.159.193.1 and it worked.

For me, the benefit of using IP 162.159.193.1 is it routed to my nearest Cloudflare PoP rather than neighbouring country.


Maybe you already routed to your nearest Cloudflare PoP using IP 162.159.192.1, then this is why I called it an Alternative Endpoint.

Further "investigation" and maybe unrelated to the main point:
Reverse IP lookup (and IP lookup) reveals that maybe some person/organization have the same endpoint with multiple IPs and different subnet (probably Zero Trust customer or manually assign the IPs to a domain/subdomain).
Sorry if it's revealing private domains/subdomains.

This is just a "report" based on my own experience (and curiosity). If there's any duplicate/similar issue (or this is something that doesn't amuse you), my apology. Sorry for long post and thanks for reading.

[shaikhnedab]

Hello There,

Thanks for your this amazing find. I was having issue where Warp connected me to wrong data center. after change endpoint to above IP, it fixed the issue.
Thanks again.

[mangotango69202]

Thanks! this allowed me to reduce my total latency by 400ms before it was 450 ish now its 50!

[galpt]

Be careful as this is not the endpoint CF wants us consumers to connect to.
It might give us the idea of "It works better than the default." temporarily, but might introduce other problems later.

According to their docs, this IP range is used for the Zero Trust client.
Refer to WARP ingress IP for the details.

Until now, WGCF only supports the consumer version of WARP and not the Zero Trust/Teams version.
Refer to #56 for the details.

The Zero Trust WARP is more complex than that as it's integrated with authentications, session management, and more features used by companies to manage their employees. Thus, might introduce unknown errors at some point if we're using the Zero Trust endpoints.
Not stopping there, this thread seems to justify that the Zero Trust WARP is different from the consumer version, so it's better to stick with engage.cloudflareclient.com.

As for why it's not routing to the nearest PoP to you, CF already explained that it might be caused by many random factors such as:

• Your ISP don't have the best peering with CF.
• It could be that the nearest PoP to you is currently very busy/congested at the moment you're trying to use WARP, so they automatically re-route you to other PoP that's not congested.
• It could be that the nearest PoP to you is currently having other technical problems.

Refer to FAQ for the details.

Also, WARP+ is using Smart Routing, so it might re-route you to servers slightly further from you but have the best conditions compared to servers nearest to your country but they might be super busy at the time you're trying to connect.

[galpt]

We did further research related to this issue and got some promising results.
Refer to this guide for the details.

Underneath, it's using the 162.159.192.1 endpoint — which is supposed to be used for consumer version of WARP according to this thread. So there shouldn't be any issues using it with WGCF, since we're basically using the consumer version.

It's also explained very well in the guide about the security & privacy considerations, to not cause a confusion.

Technically speaking, if people want custom endpoints, they should make their own by hosting it in servers nearest to them.
Using 162.159.193.0/24 is kind of redundant since you are still connecting to Cloudflare directly.
The logic would look like this:

You <--> Your ISP (probably bad peering to cf) <--> WARP datacenter

The point of using a custom endpoint is to avoid bad peering quality between your ISP and Cloudflare.
So that should look like this:

You <--> Your ISP <--> Your server/cloud (good peering to WARP and your ISP) <--> WARP datacenter

The one written by @DevinWinata is good enough, but defeats the purpose of using a custom endpoint if people's ISPs have bad peering with Cloudflare, so everyone is welcomed to test the theory in the guide.