search

ViRb3 / wgcf

🚤 Cross-platform, unofficial CLI for Cloudflare Warp
MIT License
6.09k stars 682 forks source link

Server Re-routing #236

Closed nwpr closed 1 year ago

nwpr commented 1 year ago

As mentioned in #178 the official client does support server re-routing if Cloudflare does some maintenance or thinks that another server is better at the moment.

Has anyone looked into how this feature works? Depending on Cloudflare's protocol, we could implement a service that dynamically updates the Wireguard config and maybe also automatically manages the registration based on a given license key. This could make wgcf more reliable.

I haven't yet looked into the details of this feature on Cloudflare's implementation, but is the official client also always using the same static "engage.cloudflareclient.com" endpoint like we are?

ViRb3 commented 1 year ago

I have no idea, but unless a different endpoint is used, it is most likely a customization in their WireGuard protocol, which we cannot support with wgcf.

nwpr commented 1 year ago

I've found the answer now. Basically there's nothing we have to do, this feature is already working. The server re-routing itself happens automatically on Cloudflare's end using their Unimog edge load balancer - regardless of the client.

There's only one caveat. Cloudflare's BoringTun uses an unused Wireguard header field for routing the packets to the right server internally on its edge. The endpoint IPs itself are anycast, and every server in their datacenter runs the same software, so using a specific endpoint IP isn't relevant anymore. (I'd btw suggest everyone preferring IPv4 for the tunnel itself because it allows using a bigger MTU size.) But their tunnel implementation is backwards compatible to the standard Wireguard protocol. Basically the modification is only really needed if your switch to another network and want to hold the connection without renegotiation for example. That's something we can't achieve with the stock Wireguard protocol. But for us there's one important implication: if you're behind a source NAT, the NATed source port shouldn't change to keep the connection up permanently - because this additional header information is missing. So be advised to use an adequate keepalive to keep the NAT mapping open.

If the address/port on your side should change, the tunnel will experience a few lost packets before renegotiating the connection.

This issue can be closed.

ViRb3 commented 1 year ago

Great find! Do you think the lack of keepalive in the generated wg profile could be why some people (behind CGNAT?) can't connect to WARP at all? I will consider adding keepalive by default in the next update.

nwpr commented 1 year ago

Great find! Do you think the lack of keepalive in the generated wg profile could be why some people (behind CGNAT?) can't connect to WARP at all? I will consider adding keepalive by default in the next update.

I'll answer this in #50 so others can find this information too.