Warp – Mobile VPN • Hacker News Board

Re: Warp – Mobile VPN

#391

Post by stevenjohns » Mon, Apr 01, 2019, 10:29 PM UTC

jgrahamc wrote: post #169

dexterdog wrote: post #113

Earlier quoted context omitted.

Those "cloudflare loading" screens that come up when visiting some low-traffic sites. It's probably more common for people using privacy blockers and browser containers to block tracking. I see it at least a few times per day and I get captchas on almost any site that uses them (regardless of being behind cloudflare).

That's "I'm Under Attack Mode" which is used by sites (mostly smaller ones) to protect against small DDoS attacks or scrapers.

I'd just like to mention that this service saved me once. I have a small low-end box and one of the sites I hosted (that belonged to a YouTube personality) was DDOS'ed for a while, it kept taking the server down. A combination of crafty server configuration and enabling the "Under Attack" mode helped me deal with it.

Re: Warp – Mobile VPN

#392

Post by X-Istence » Mon, Apr 01, 2019, 10:39 PM UTC

topranks wrote: post #390

dsl wrote: post #253

Earlier quoted context omitted.

Is this in X-Forwarded-For?

How can they do this? Are Cloudflare going to be able to decrypt the TLS sessions running over their VPN between me and end-sites, so they can insert this additional HTTP header? Doesn’t sound feasible.

When most of those sites are hosted by Cloudflare, they already decrypt the TLS session at their load balancers before forwarding the request to the remote endpoint.

Re: Warp – Mobile VPN

#393

Post by dsl » Mon, Apr 01, 2019, 10:47 PM UTC

zackbloom wrote: post #341

devicenull wrote: post #321

Earlier quoted context omitted.

Which presumably only works if your site is using Cloudflare? Since you wouldn't be MITMing SSL in order to inject this header?

This is correct. It's significantly harder to inject the origin IP into a TCP stream. We have ways [1] of doing it, but it requires some coordination on both sides. 1- https://blog.cloudflare.com/mmproxy-creative-way-of-preservi...

Have you considered enabling this out of band? For example as a network administrator I could verify a CIDR block and receive a real time stream of 5-tuples (err, 7-tuples with the proxy?) destined to my network.

Re: Warp – Mobile VPN

#394

Post by topranks » Mon, Apr 01, 2019, 10:47 PM UTC

aroch wrote: post #19

ChrisSD wrote: post #12

Last time I used 1.1.1.1 DNS I sometimes had problems when visiting bbc.co.uk. It seemed to be trying to look up the domain on cloudflare's service for some reason. Was I the only one to have this problem? Would it be fixed now?

1.1.1.1 doesn't use eDNS and likely never will: https://developers.cloudflare.com/1.1.1.1/nitty-gritty-detai... So geo-specific things will break... BBC.com should load though since its for out-of-UK people

This is factually inaccurate.

Cloudflare do not use the EDNS Client Subnet extension:

https://tools.ietf.org/html/rfc7871

You are right to say that can potentially affect geo-located services. But that is not to say that 1.1.1.1 doesn’t support EDNS:

https://tools.ietf.org/html/rfc6891

Re: Warp – Mobile VPN

#395

Post by dsl » Mon, Apr 01, 2019, 10:50 PM UTC

jgrahamc wrote: post #259

dsl wrote: post #251

Earlier quoted context omitted.

That is why Cloudflare wants you to use their VPN rather than an anonymized one. If they can track you, they can have more data about whether to block you.

Nope. We want you to use our VPN because we think it'll make your mobile Internet experience better (faster and more secure). That turns into an upsell opportunity to us and makes our core service (which people pay us for) more valuable.

So if I end up at a Cloudflare customer over a Cloudflare VPN you will never tie the two records together? That is actually encouraging if you'd publicly commit to that.

Re: Warp – Mobile VPN

#396

Post by oedmarap » Mon, Apr 01, 2019, 10:56 PM UTC

This is a wonderful announcement. I'm a bit torn since on the one hand I love Cloudflare and use them extensively for my domains/servers/websites but for personal secure browsing I've been using Mullvad + WireGuard Android (with 1.1.1.1 in the config file) for a long time and it's worked flawlessly.

I like both companies so maybe I'll just keep supporting Mullvad and recommend 1.1.1.1 to friends and family once Warp is in general availability (those "people who don't know what a VPN is").

Warp+ looks to be a solid business use case which I think fits well with Argo and their other offerings. Either way, it's good to have another proper VPN option outside of (self)hosted WireGuard.

Many thanks for democratizing this service, as is always the case with Cloudflare.

Re: Warp – Mobile VPN

#397

Post by Operyl » Mon, Apr 01, 2019, 10:59 PM UTC

maltalex wrote: post #128

newaccoutnas wrote: post #107

Earlier quoted context omitted.

Could also be packet-shaping/QoS on the ISP side

Sure. Especially in countries that don't have network neutrality...

I wonder what first world country would do that!

Re: Warp – Mobile VPN

#398

Post by Operyl » Mon, Apr 01, 2019, 11:01 PM UTC

maltalex wrote: post #124

arendtio wrote: post #110

Earlier quoted context omitted.

Possible but I am not exactly sure what caused the difference. I used fast.com for testing and when I increased the number of parallel connections the performance degradation was lower when using Wireguard. I assumed that it is related to congestion control as Wireguard uses UDP AFAIK and otherwise I would use TCP on the bottleneck part of the connection.

Wireguard might be using UDP, but you're still tunneling TCP on top of it. So the congestion control is still there and kicking.

The congestion control is less likely on the server side, whereas congestion control on an ISPs network is much more so.

Re: Warp – Mobile VPN

#399

Post by moneywoes » Mon, Apr 01, 2019, 11:06 PM UTC

Would this work in China?

Re: Warp – Mobile VPN

#400

Post by eridius » Mon, Apr 01, 2019, 11:13 PM UTC

catern wrote: post #377

eridius wrote: post #370

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.

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.