Alternative Endpoint

[DevinWinata]

Update 01/2025:
162.159.193.0/24 gateway seems has stopped working around last December.
You can still try to connect, see if you can still connect from your region.

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.

[peterweissbier]

i am trying to setup a qbittorrent docker container with gluetun using a wgcf configuration file but it doesnt want to read the endpoint unless i set it to an ip, i have tried to use "162.159.193.1" or "162.159.193.1:(port here)" but it wouldnt work

[galpt]

i am trying to setup a qbittorrent docker container with gluetun using a wgcf configuration file but it doesnt want to read the endpoint unless i set it to an ip, i have tried to use "162.159.193.1" or "162.159.193.1:(port here)" but it wouldnt work

When using IP directly, your OS doesn't need to resolve the domain, so technically it should work unless your ISP prevents you from connecting to WARP endpoints.

Resolving a domain to an IP requires a working DNS setup, the first thing you can do is to check your DNS setup and maybe use DoH to prevent DNS hijacking.
If that still doesn't solve the issue, it might be how gluetun works. Let the gluetun devs know about this issue - but only after you've tried checking your DNS and network setup.

Lastly, you can host your own wgcf relay, but it'll require you to get a cheap VPS for that.
#279 (comment)

[peterweissbier]

when i use a protonvpn wireguard conf it works just fine, it is using ip:port as endpoint.

correct me if i am wrong but the gluetun docker container also uses unbound DNS over TLS, so does my system need to resolve it aswell?
i attached the log of the gluetun container, you can see everything is working just fine with the protonvpn wireguard conf

[galpt]

@peterweissbier
Looks fine to me.
Then some things you might need to check are:

1. Try connecting to Warp using 1.1.1.1 & Cloudflare One apps (from Play Store).
2. If you can connect successfully using the official app, try using a freshly generated wgcf config.

The things you want to check here are:

1. It's not your ISP preventing you from connecting to Warp endpoints.
2. It's not Cloudflare preventing you or your country from using unofficial Warp client such as wgcf/gluetun.

Point (2) is currently a known problem for users trying to connect to HKG colo not using the official apps.
So it might (or might not) be the same case for you.

[peterweissbier]

tested 1.1.1.1 warp app and it works fine - i was hoping that it would be able to import the generate config but i guess thats not an option there.
already regenerated the config file a couple times and there is no change
the other config from protonvpn works so neither my ISP nor cloudflare are blocking it in my country (germany)

i just found this qdm12/gluetun#1738 and i made it work, my fault was that i pointed the docker container to the file wg0.conf and it couldnt read the endpoint because it was not an IP, strangely enough i set an environment variable with the ip and the container will accept it just fine

thanks for your help

[ani917]

what to do if all alternative endpoints stop working? (blocked handshake)