6 ms·

Can the service be used with another Wireguard client (hopefully bundled into Linux distros in the future) without installing Cloudflare’s client software?

jgrahamc 8y ago
We do not currently plan to allow third-party WireGuard clients to connect to the service.
- sascha_sl 8y ago
  It it just me or does it sound wrong to call wireguard, the kernel module, third party software in this context? That's literally the reference implementation.
  - arghwhat 8y ago
    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.
    - jgrahamc 8y ago
      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...)
      - nickysielicki 8y ago
        Not supporting a configuration is much different than actively prohibiting it. It's okay to just say, "Hey, we are running a free VPN. We're making some privacy guarantees and are trying to log as little as possible. That exposes us to being abused, which means that we have to put some limits in-place on the client." There's nothing unreasonable about that at all.
      - steve19 8y ago
        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.
        jgrahamc 8y ago
        I'll tell the team. Thanks for the suggestion.
- newscracker 8y ago
  Could you elaborate why? Is it because you may not be able to field support requests and complaints from users who may have clients with issues or may have misconfigured it? Or are there other reasons too? Would you ever make the code of the 1.1.1.1 app with Warp open source?
  - jgrahamc 8y ago
    Exactly that: there would be a large support cost to making it work and so we'd need to think carefully about it. It's not a technical issue at all. On the open source thing: maybe? It's hard to say. In general, we like to open source libraries and stand alone applications. And we think pretty carefully about the cost of supporting an open source community as well. Which is, I think, a thing people overlook.
  - jrockway 8y ago
    > Could you elaborate why? Embrace, extend, extinguish!
- arghwhat 8y ago
  Asked differently, do you plan on explicitly disallowing/banning it if people unofficially ran the reference implementation against Warp? It would be nice to know the policy there. For those of us that do know what a VPN is, and are okay not having access to support, getting things to work without a desktop app would be nice.
  - jgrahamc 8y ago
    I think my answer was pretty clear. We do not currently plan to allow stock WireGuard clients to use Warp. I say, currently, because things can always change. It's important to appreciate that we have literally millions of users for the 1.1.1.1 App and we are rolling out a free VPN for them. That is a huge support and network burden that we have to deal with to make that experience work well. Yes, we use WireGuard under the hood (and have open sourced our Rust code), but the additional cost of supporting people connecting from their WireGuard clients means that we don't want to support that _today_. Please bear with us while we get through a massive roll out.
    - newaccoutnas 8y ago
      What's the reasoning behind this[1]? It strikes of ulterior motives and turns me off, as a potential user. Any official response from Cloudflare? [1]https://lists.zx2c4.com/pipermail/wireguard/2019-March/004048.html https://lists.zx2c4.com/pipermail/wireguard/2019-March/00404...
      - jgrahamc 8y ago
        We're really happy to work with the WireGuard. We communicated with Jason throughout the process and have a ton of respect for him and the entire WireGuard community. In the short term, we need the flexibility to quickly update our code base to support the project we built it for. That's harder when you need to coordinate with people outside Cloudflare and when we need to move as fast as we plan to. However, we really believe in open source and want the WireGuard community to thrive. We licensed the code very openly (3-clause BSD) and WireGuard may choose to fork it. If they do, we'll support it and plan to contribute any improvements in our own fork back. Over the long term, we're very open to merging this back into the upstream project.
- foobarbazetc 8y ago
  So you’ve taken WireGuard and commercialized it into your own incompatible implementation or?

jgrahamc 8y ago

We do not currently plan to allow third-party WireGuard clients to connect to the service.

sascha_sl 8y ago
It it just me or does it sound wrong to call wireguard, the kernel module, third party software in this context? That's literally the reference implementation.
- arghwhat 8y ago
  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.
  - jgrahamc 8y ago
    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...)
    - nickysielicki 8y ago
      Not supporting a configuration is much different than actively prohibiting it. It's okay to just say, "Hey, we are running a free VPN. We're making some privacy guarantees and are trying to log as little as possible. That exposes us to being abused, which means that we have to put some limits in-place on the client." There's nothing unreasonable about that at all.
    - steve19 8y ago
      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.
      - jgrahamc 8y ago
        I'll tell the team. Thanks for the suggestion.
newscracker 8y ago
Could you elaborate why? Is it because you may not be able to field support requests and complaints from users who may have clients with issues or may have misconfigured it? Or are there other reasons too? Would you ever make the code of the 1.1.1.1 app with Warp open source?
- jgrahamc 8y ago
  Exactly that: there would be a large support cost to making it work and so we'd need to think carefully about it. It's not a technical issue at all. On the open source thing: maybe? It's hard to say. In general, we like to open source libraries and stand alone applications. And we think pretty carefully about the cost of supporting an open source community as well. Which is, I think, a thing people overlook.
- jrockway 8y ago
  > Could you elaborate why? Embrace, extend, extinguish!
arghwhat 8y ago
Asked differently, do you plan on explicitly disallowing/banning it if people unofficially ran the reference implementation against Warp? It would be nice to know the policy there. For those of us that do know what a VPN is, and are okay not having access to support, getting things to work without a desktop app would be nice.
- jgrahamc 8y ago
  I think my answer was pretty clear. We do not currently plan to allow stock WireGuard clients to use Warp. I say, currently, because things can always change. It's important to appreciate that we have literally millions of users for the 1.1.1.1 App and we are rolling out a free VPN for them. That is a huge support and network burden that we have to deal with to make that experience work well. Yes, we use WireGuard under the hood (and have open sourced our Rust code), but the additional cost of supporting people connecting from their WireGuard clients means that we don't want to support that _today_. Please bear with us while we get through a massive roll out.
  - newaccoutnas 8y ago
    What's the reasoning behind this[1]? It strikes of ulterior motives and turns me off, as a potential user. Any official response from Cloudflare? [1]https://lists.zx2c4.com/pipermail/wireguard/2019-March/004048.html https://lists.zx2c4.com/pipermail/wireguard/2019-March/00404...
    - jgrahamc 8y ago
      We're really happy to work with the WireGuard. We communicated with Jason throughout the process and have a ton of respect for him and the entire WireGuard community. In the short term, we need the flexibility to quickly update our code base to support the project we built it for. That's harder when you need to coordinate with people outside Cloudflare and when we need to move as fast as we plan to. However, we really believe in open source and want the WireGuard community to thrive. We licensed the code very openly (3-clause BSD) and WireGuard may choose to fork it. If they do, we'll support it and plan to contribute any improvements in our own fork back. Over the long term, we're very open to merging this back into the upstream project.
foobarbazetc 8y ago
So you’ve taken WireGuard and commercialized it into your own incompatible implementation or?