
The Technical Challenges of Building Cloudflare Warp - migueldemoura
https://blog.cloudflare.com/warp-technical-challenges/
======
eloff
This looks like an impressive accomplishment, and I'm glad Cloudflare got the
idea before Google did, because the latter are very interested in hoovering up
every shred of data about me to better target their ads. I'll install 1.1.1.1
and give it a try.

However, I had to previously uninstall 1.1.1.1 after I found it draining my
battery. I had a few mysterious instances of my phone dying a day early, and I
couldn't figure it out until I found it warm one day and dug into what was
using the CPU while idle. Turns out it was 1.1.1.1. I uninstalled it and the
problem went away. I very much hope that's been identified and fixed by now (I
use Android on a Pixel One.)

~~~
sofaofthedamned
Google already have an Android VPN [https://www.howtogeek.com/275474/how-to-
use-androids-wi-fi-a...](https://www.howtogeek.com/275474/how-to-use-androids-
wi-fi-assistant-to-keep-your-phone-safe-on-public-networks/)

------
ignoramous
Super interesting [0][1].

Re: NAT and source port changes

I am experimenting building a similar tech but on AWS. To use anycast, I front
my Wireguard servers in multiple regions with GlobalLoadAccelerator and set
ClientAffinty to two-tuple (source-ip, destination-ip) instead of the default
5-tuple (source-ip and port, destination-ip and port, protocol).

Re: Network switch (WiFi to Cellular and Mobile IP)

This one stings. I haven't impl it yet, if ever I get to the scale to warrant
such a design: I was thinking abt sticky routing the traffic using only the
destination port (of the wireguard server). At the time of new connection
establishment (VPN turned on / off), ask the app server for a port to use and
use that. On the server end, have one beefy wireguard server serving a range
of ports per region behind the anycast load balancer, so that the balancer has
no choice but to send the incoming to that single server that is serving
incoming destination port. Use the usual IP route commands to send the traffic
along to approp exit server depending on the actual destination IP (now that
wireguard has decrypted the packet).

Re: Clients:

I'm predominantly focusing on Android, and the I've found things work
differently across OEMs. It is just too much work. I have gone with the
workaround that Blokada so wonderfully uses: employing a watchdog, heartbeat,
keep-alive service, and aggressive wake-ups for some of the common problems
across OEMs.

[0] Google's paper on NetworkLoadBalancer is simply amazing:
[https://ai.google/research/pubs/pub44824/](https://ai.google/research/pubs/pub44824/)

[1] [https://ai.googleblog.com/2015/08/pulling-back-curtain-on-
go...](https://ai.googleblog.com/2015/08/pulling-back-curtain-on-googles-
network.html?m=1)

------
theobeers
I subscribed to WARP+ just to support your work. Keep it up! I see mixed
comments on HN about Cloudflare’s increasingly central role, and I get that,
but my feeling at this point is still positive.

------
tosh
Wireguard + Rust

> After considering and testing several more modern options, we landed on
> WireGuard®. WireGuard is a modern, high performance, and most importantly,
> simple, protocol created by Jason Donenfeld to solve the same problem. Its
> original code-base is less than 1% the size of a popular IPsec
> implementation, making it easy for us to understand and secure. We chose
> Rust as the language most likely to give us the performance and safety we
> needed and implemented WireGuard while optimizing the code heavily to run
> quickly on the platforms we were targeting. Then we open sourced the
> project.

------
fjni
Can someone explain the WARP+ section? First, it says

> [argo continually monitors] thousands of routes over the Internet between
> our data centers. That data builds a database which maps every IP address
> range with the fastest possible route to every destination.

and then they seem to assert that this is impossible with https traffic
because the tcp payload is encrypted. For routing, as I understand it, none of
the payload should have to be inspected... what am I missing?

~~~
Jonnax
The payload is encrypted not the destination IP. Otherwise how would routers
be able to route the packet?

What they're saying is that Warp+ will send the packet across their private
network rather than sending just on the plain internet.

For example:

You're in Italy. You want to send a packet to a server in New York.

On the internet the path is unpredictable. Because there's a lot of hops from
different networks etc.

Cloudfare are saying that your packet will enter their Italy PoP. (they may
have more on the country I don't know)

Then via their separate private network, it will travel to the New York PoP.

Then out to the internet to the destination.

~~~
fjni
We're saying the same thing I think: If the destination IP is not encrypted
(because how would routers be able to route it otherwise) then why would this
only work with http and not https traffic? That was my question.

