3 ms·

I know Wireguard is better but how do I get my work to use it instead of openvpn?

battery_cowboy 7y ago
Provide them a plan to transition to it that's bullet proof and wait until the current crisis is over (no one smart is making changes to their VPN right now while it's being overtaxed). You'll need the code to run it, the plan for authentication and authorization, documentation, testing, maintenance plans, training, rollout plans, fallback plans, etc.
tjalfi 7y ago
If it’s a large company, wait 5 to 10 years for the IETF to mangle the design and Cisco to add support for the botched protocol.
kylek 7y ago
I think one of the points the author is getting at is that there is a lack of (enterprise-level?) tooling around wireguard at the moment. Something that supports 2fa to connect would be nice, etc.
- vxNsr 7y ago
  Yeah, the setup really needs to find a way to not require manually adding the actual private keys to each side to set it up.
  - jedberg 7y ago
    But that is precisely what makes it so easy and yet remain secure. When I add a new client, it takes just a minute to generate the keys and send over the QR code to the person via an already secure side channel, if we aren't already meeting face to face.
  - eadmund 7y ago
    You don't add the private keys to both sides: you add each node's private key and the other node's public key on each side.
- 0xCMP 7y ago
  Tailscale seems to be trying to provide exactly this: https://tailscale.com/ https://tailscale.com/
- rauhl 7y ago
  I wonder what two-factor would even look like for WireGuard. It’s a stateless protocol, so how often would you need to enter a second factor? How would you be prompted? Maybe that is working at the wrong level? Maybe it’s possible to build that feature atop WireGuard, without failing open (potentially catastrophic if you are using it as a VPN).
  - nightfly 7y ago
    We're considering that at my work for internal use. The easiest solution we can think of would be using something like an HTTPS API to 2FA to a server, ship a private key and other connection info out to the client, and require the client to check in regularly to keep their generated key enabled. So yeah, something to build on top of Wireguard.
    - tialaramex 7y ago
      When you start shipping private keys alarm bells ought to go off in your head. "The whole point of this cryptosystem I'm using is that these keys never go anywhere, but somehow I've persuaded myself that I need to move them over the network so I screwed up badly somewhere". This is the same in TLS setups (including OpenVPN) and in S/MIME (where it's a reminder that S/MIME probably is only delivering theatre and not any real security to your users).
      - afiori 7y ago
        That could be changed by generating the key in the authenticated client.
loeg 7y ago
Depending on firewall egress policy, reverse tunnel home.

Provide them a plan to transition to it that's bullet proof and wait until the current crisis is over (no one smart is making changes to their VPN right now while it's being overtaxed). You'll need the code to run it, the plan for authentication and authorization, documentation, testing, maintenance plans, training, rollout plans, fallback plans, etc.

tjalfi 7y ago

If it’s a large company, wait 5 to 10 years for the IETF to mangle the design and Cisco to add support for the botched protocol.

kylek 7y ago

I think one of the points the author is getting at is that there is a lack of (enterprise-level?) tooling around wireguard at the moment. Something that supports 2fa to connect would be nice, etc.

vxNsr 7y ago
Yeah, the setup really needs to find a way to not require manually adding the actual private keys to each side to set it up.
- jedberg 7y ago
  But that is precisely what makes it so easy and yet remain secure. When I add a new client, it takes just a minute to generate the keys and send over the QR code to the person via an already secure side channel, if we aren't already meeting face to face.
- eadmund 7y ago
  You don't add the private keys to both sides: you add each node's private key and the other node's public key on each side.
0xCMP 7y ago
Tailscale seems to be trying to provide exactly this: https://tailscale.com/ https://tailscale.com/
rauhl 7y ago
I wonder what two-factor would even look like for WireGuard. It’s a stateless protocol, so how often would you need to enter a second factor? How would you be prompted? Maybe that is working at the wrong level? Maybe it’s possible to build that feature atop WireGuard, without failing open (potentially catastrophic if you are using it as a VPN).
- nightfly 7y ago
  We're considering that at my work for internal use. The easiest solution we can think of would be using something like an HTTPS API to 2FA to a server, ship a private key and other connection info out to the client, and require the client to check in regularly to keep their generated key enabled. So yeah, something to build on top of Wireguard.
  - tialaramex 7y ago
    When you start shipping private keys alarm bells ought to go off in your head. "The whole point of this cryptosystem I'm using is that these keys never go anywhere, but somehow I've persuaded myself that I need to move them over the network so I screwed up badly somewhere". This is the same in TLS setups (including OpenVPN) and in S/MIME (where it's a reminder that S/MIME probably is only delivering theatre and not any real security to your users).
    - afiori 7y ago
      That could be changed by generating the key in the authenticated client.

loeg 7y ago

Depending on firewall egress policy, reverse tunnel home.