Live data from Hacker News

Warp – Mobile VPN

blog.cloudflare.com

401–410 of 500 posts

Re: Warp – Mobile VPN

#401

Earlier quoted context omitted.

My interpretation of “not designed for mobile” is mobile devices, not mobile network. In particular, TCP is not designed for a scenario where the device keeps leaving old networks and joining new ones, or where a device routinely has 2 network interfaces where one has better performance than the other but which one is better changes frequently.

Multipath-TCP is designed for precisely that.

I may be wrong but isn't Multipath TCP pretty darn new and rarely used? At least on iOS you have to explicitly opt into it, either using the new Network framework for raw networking or a special configuration for URLSession, and also requires an entitlement to even do (no idea why). AFAIK the only Multipath TCP that my iPhone regularly actually uses is Siri.

Which is to say, it still feels largely experimental.

Re: Warp – Mobile VPN

#404
post #377

Earlier quoted context omitted.

Ships, as mobile devices, frequently entered and left packet radio range with each other, or might have multiple other ships in range and have to select which ship to send their packets to.

That would be equivalent to the server going offline and back online, as opposed to the route constantly changing.

We're talking about a packet-switched network. The other ships aren't your destination - some server on land is your destination.

Re: Warp – Mobile VPN

#405
Given the size of the queue to join (request via their 1.1.1.1 app), I'd say get it, got a slot and by the time that comes up any issues or concerns would of been well debated.

But looking good so far.

Re: Warp – Mobile VPN

#406

Earlier quoted context omitted.

Hmm, I didn't consider that angle. Maybe I'm just a cynic, a byproduct of the 90s Microsoft monopoly and Linux backlash.

Nothing wrong with some cynicism. And I totally understand the concern, but one thing people always miss with Cloudflare is... follow the money. We get paid by people with web servers and API servers. We have to do things that keep them happy.

> one thing people always miss with Cloudflare is... follow the money

I think that applies almost anywhere. One could say "don't trust Google or Facebook with personal data" merely based on the fact that almost all of their money comes from advertising.

And thanks for the interesting exchange!

Re: Warp – Mobile VPN

#407
post #55

There's a lot of dissing of competition (they drain your battery, "all suck", slow down your internet) without a single datapoint. Personally I find the performance of PIA fine. I just ran a test through fast.com and got 42 mbps on 4g through PIA mobile VPN in NYC. (Weirdly, when I turn off the VPN and test I'm only getting around 2 Mbps.) Latency is a bit higher than direct, but not enough for me to agree with their…

CPU on your phone is probably gonna be the main reason VPN is slower than not using one. But this only sends DNS over the VPN so it won’t use much power at all. 99% of your traffic does not route via the VPN with this app.

Where do you get the idea this is DNS over VPN only?

> Any unencrypted connections are encrypted automatically and by default.

> Unfortunately, a lot of the Internet is still unencrypted. For that, Warp automatically adds encryption from your device to the edge of Cloudflare’s network

It reads to me like all your traffic goes through your service, not just DNS.

Re: Warp – Mobile VPN

#408
post #363

How is Cloudflare handling IP allocation here? I might be mis-understanding how WireGuard works, but it doesn't look like there is an official method for IP dynamic assignment.

I would like to know the answer to this too :)

Maybe they are using one tunnel interface per single customer then always assign the same address to everybody and use policy routing to handle this (EDIT: just realized there might not be using the network stack at all for this and do something alike in their userspace implementation). This would not solve key exchange though. But maybe it is possible to accept any key (if the public key is transmitted this should be easy). Otherwise connecting probably requires requesting an IP address for your key prior to connecting via WireGuard to allow the endpoint to setup required configuration.

This is really something WireGuard did not quite expect to be needed apparently. It is also hard to do dynamic routing with WireGuard which could also possibly allow fully meshed networks directly on top of WireGuard but i have not tried really hard yet. It would also be very useful to me to be able to have a CA so i do not have to update configuration everywhere. Last but not least its not possible to bridge the WireGuard interface at all. I have an experimental setup where i would like to use WireGuard as a sole network interface for a virtual machine, somewhat like advertised for containers where it works beautifully. However, its not possible because its not an Ethernet interface in Linux. Instead i have setup a VLAN on my switch and route traffic through WireGuard using my gateway. I would like to terminate the tunnels at the hypervisor a lot more, but don't want to route traffic there.

I think all of this boils down to the usage of their cryptographic routing and trickery around it to make it work as intended. I would probably abandon WireGuard if a fork would allow my use cases as i am otherwise a really happy user.

Re: Warp – Mobile VPN

#409
post #363

How is Cloudflare handling IP allocation here? I might be mis-understanding how WireGuard works, but it doesn't look like there is an official method for IP dynamic assignment.

From what I reckon this (and almost any other VPN, or even Tor) will give you the outside appearance of the IP of the exit node. Think like NAT.

He is most likely talking about the IP address inside the tunnel which in case of WireGuard is intervened with the exchange of cryptographic keys. You can not use a DHCP server as only unicast traffic is possible.

Re: Warp – Mobile VPN

#410

Earlier quoted context omitted.

It is wrong. Warp is the third-party implementation. It would be amazing if it could be made to work from standard wireguard, but I suppose there's a chance that if desktop versions arrive, you'll be able to extract the keys. The only thing stopping that would be if Cloudflare broke the protocol.

We can argue about the terminology but from the perspective of the company other WireGuard clients (including the official ones) are 'third-party' in the sense that we don't control them. That makes supporting users of those clients more expensive for us (e.g. we currently have a mobile app for Warp, someone calls our support asking for help with a Linux client...)

I know this is the last thing you are worried about right now, but could you at some point look into tasker integration. Its really easy to provide a tasker interface. I would love to be able to control when 1.1.1.1 connected.
Post reply on HN