4 ms·

I agree. I've been using Wireguard for about 6 months now. The quick start is great for getting a quick overview but it doesn't really document properly how a c

I agree. I've been using Wireguard for about 6 months now. The quick start is great for getting a quick overview but it doesn't really document properly how a configuration file should be made. There is no real detail about how a wg-quick config differs from a wg one, and they're not compatible; it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg. I also saw nothing anywhere about how if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config as the 'down' will write back the current state of the interface. It's not a big deal, but it messes with the usual workflow of editing the config file of a service (you don't want to down it while updating your config, which could take time). otherwise, wg has been great, it is generally quite reliable on Android but I'd like to see an easier way of doing the exclusions, inverse CIDRs are not my forte.

StavrosK 8y ago
> it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg. Really? I didn't even know that, thanks. > if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config Ouch. Yeah, these things definitely need to be documented, I had no idea about this either. I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc.
- alias_neo 8y ago
  > I would also like to see an easier way to configure authentications Agreed. I like the way home assistant does it with a secrets.yml and you refer to your secrets by !secret <name of secret>
- Hello71 8y ago
  > I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc. The config file is designed to be very straightforward and contain only the bare minimum required configuration stanzas. If you want to separate the keys, or use a higher level key negotiation protocol (e.g. TLS), you can write your own script that calls the lower level "wg" command instead of "wg-quick". Alternatively, you can write a script that generates a wg-quick configuration file.
  - zx2c4 8y ago
    Exactly this. WireGuard and wg(8) are meant as building blocks. For example, the wg-quick(8) tool is a simple bash script I built out of wg(8) and ip(8) that mostly works for my use cases and those of some other folks. But if you want something more complicated, then it's supposed to be easy to build that out of the building blocks presented.
  - chasil 8y ago
    What I am wondering is why they chose 25519. It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Round-1-Submissions https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...
    - tialaramex 8y ago
      Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm. NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".
      - chasil 8y ago
        The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update." ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable. On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems. Android, however, cannot do that. p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway. "In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."
Hello71 8y ago
> I also saw nothing anywhere about how if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config as the 'down' will write back the current state of the interface. It's not a big deal, but it messes with the usual workflow of editing the config file of a service (you don't want to down it while updating your config, which could take time). `down` only writes the state of the interface if you put SaveConfig = true in your configuration file. If so... you asked for it. > I'd like to see an easier way of doing the exclusions, inverse CIDRs are not my forte WireGuard uses the standard Linux routing infrastructure. wg-quick uses the powerful Linux policy routing functions along with the suppress_prefixlength policy routing rule in order to use your main routing table for exclusions. Therefore, the command to exclude an IP is simply "ip route add 10.0.1.0/24 via 10.0.0.1 dev eth0". Obviously you should replace the example subnets and interface, and this is not permanent. The beauty of wg-quick is that you don't need to add this rule every time you bring up your VPN, but can instead add it as a temporarily redundant static route.
- alias_neo 8y ago
  > `down` only writes the state of the interface if you put SaveConfig = true in your configuration file. If so... you asked for it. Nope, it's not in my config file. I didn't even know the option existed until you mentioned it, again, nothing on the Quick Start about it. > WireGuard uses the standard Linux routing infrastructure... I meant more in terms of the Android app, not really a WG issue, but it has a check box to add exclusions to the allowed ip list, by basically adding ranges inverse to what you'd input if you were saying "exclude these". What's the inverse of 192.168.0.0/16? I have no idea without looking it up.
  - zx2c4 8y ago
    > I meant more in terms of the Android app, not really a WG issue, but it has a check box to add exclusions to the allowed ip list, by basically adding ranges inverse to what you'd input if you were saying "exclude these". The Android app now has a little checkbox to toggle a common set complement operation ("Exclude private IPs"). If you want to do something wild and include or exclude very particular ranges, then you can compute that yourself and put it in there, since ostensibly you have a very particular networking idea in mind.
zx2c4 8y ago
> I also saw nothing anywhere about how if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config as the 'down' will write back the current state of the interface. No. Only if you've explicitly chosen to add "SaveConfig = true" to the config file, which by default is not there.

StavrosK 8y ago

> it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg. Really? I didn't even know that, thanks. > if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config Ouch. Yeah, these things definitely need to be documented, I had no idea about this either. I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc.

alias_neo 8y ago
> I would also like to see an easier way to configure authentications Agreed. I like the way home assistant does it with a secrets.yml and you refer to your secrets by !secret <name of secret>
Hello71 8y ago
> I would also like to see an easier way to configure authentications, having them in the same file as the config means I can't version control it, share it easily, etc. The config file is designed to be very straightforward and contain only the bare minimum required configuration stanzas. If you want to separate the keys, or use a higher level key negotiation protocol (e.g. TLS), you can write your own script that calls the lower level "wg" command instead of "wg-quick". Alternatively, you can write a script that generates a wg-quick configuration file.
- zx2c4 8y ago
  Exactly this. WireGuard and wg(8) are meant as building blocks. For example, the wg-quick(8) tool is a simple bash script I built out of wg(8) and ip(8) that mostly works for my use cases and those of some other folks. But if you want something more complicated, then it's supposed to be easy to build that out of the building blocks presented.
- chasil 8y ago
  What I am wondering is why they chose 25519. It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Round-1-Submissions https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...
  - tialaramex 8y ago
    Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm. NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".
    - chasil 8y ago
      The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update." ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable. On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems. Android, however, cannot do that. p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway. "In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."

Hello71 8y ago

> I also saw nothing anywhere about how if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config as the 'down' will write back the current state of the interface. It's not a big deal, but it messes with the usual workflow of editing the config file of a service (you don't want to down it while updating your config, which could take time). `down` only writes the state of the interface if you put SaveConfig = true in your configuration file. If so... you asked for it. > I'd like to see an easier way of doing the exclusions, inverse CIDRs are not my forte WireGuard uses the standard Linux routing infrastructure. wg-quick uses the powerful Linux policy routing functions along with the suppress_prefixlength policy routing rule in order to use your main routing table for exclusions. Therefore, the command to exclude an IP is simply "ip route add 10.0.1.0/24 via 10.0.0.1 dev eth0". Obviously you should replace the example subnets and interface, and this is not permanent. The beauty of wg-quick is that you don't need to add this rule every time you bring up your VPN, but can instead add it as a temporarily redundant static route.

alias_neo 8y ago
> `down` only writes the state of the interface if you put SaveConfig = true in your configuration file. If so... you asked for it. Nope, it's not in my config file. I didn't even know the option existed until you mentioned it, again, nothing on the Quick Start about it. > WireGuard uses the standard Linux routing infrastructure... I meant more in terms of the Android app, not really a WG issue, but it has a check box to add exclusions to the allowed ip list, by basically adding ranges inverse to what you'd input if you were saying "exclude these". What's the inverse of 192.168.0.0/16? I have no idea without looking it up.
- zx2c4 8y ago
  > I meant more in terms of the Android app, not really a WG issue, but it has a check box to add exclusions to the allowed ip list, by basically adding ranges inverse to what you'd input if you were saying "exclude these". The Android app now has a little checkbox to toggle a common set complement operation ("Exclude private IPs"). If you want to do something wild and include or exclude very particular ranges, then you can compute that yourself and put it in there, since ostensibly you have a very particular networking idea in mind.

zx2c4 8y ago