3 ms·

I always felt the disappointment of wireguard was wrapping it up into an opinionated network interface. It really should have been a generic "filter" that you

I always felt the disappointment of wireguard was wrapping it up into an opinionated network interface. It really should have been a generic "filter" that you could attach to any type of file handle. Then the configuration would be far less strongly coupled, less weirdly communicated to the kernel, and the status of your connection more immediately obvious. Plus, you could have wireguard files on your local or remote filesystems, or any character device, or named pipes if you felt like it. You could use a "jit" daemon to build tap or other interfaces for you, or just do it individually at the application layer. You could have pre registered keys with the kernel, or you could manage that directly, or generate them randomly. It's always been a weird smelling underspecified IPSEC clone to me, when it could have been so much more.

mellutussa 3y ago
But why don't use the nice smelling IPSEC if that ticks your boxes?
- akira2501 3y ago
  It doesn't. It just foresaw the need to be able to dynamically configure tunnels on first connection and specified all of that. Which seems to me is a lot of what fly io has just mostly reimplemented here. In any case the point is I would prefer to just have the basic components available and let me piece them together however I want. Mostly to allow using the underlying technology in more contexts that it is currently available in.
  - medstrom 3y ago
    Heh, it really sounds like your needs would be better served with IPSec or something. WireGuard was born precisely because they saw that the whole problem making other existing solutions difficult to audit and insecure-in-practice was their thousand ways to configure. So they did the opposite. Low lines of code, few possibilities. In software you often choose between a small monolith and a big kitchen sink. Once you have 1 more need than the monolith covers, you have to go over to the kitchen sink.
d-z-m 3y ago
> I always felt the disappointment of wireguard was wrapping it up into an opinionated network interface. Why? WireGuard is a VPN, it's pretty normal for VPN solutions to expose themselves as a network interface. > It really should have been a generic "filter" that you could attach to any type of file handle. What's the use-case you had in mind here? I'm not sure how generifying it to a "filter" on any type of file descriptor looks for an interactive protocol like wireguard. > It's always been a weird smelling underspecified IPSEC clone to me[...] Just because there isn't an RFC? I've always found the wireguard paper[0] to be quite readable and thorough in it's specification of the protocol. [0]:https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf
- justsomehnguy 3y ago
  Not the OP, but the main problem with WireGuard[0] is not the protocol[1], it's good, but the opinionated tooling around it, be it .INI style configurations (god I hate it), mutual incompatibility of wg and wg-quick or just outright stupid decisions around storing config files and interacting with the user in the Windows client. Though there are some nuances with the routing selection/filtering too, which gets troublesome when you just need a pipe and run a proper routing protocols over it. ::/0 solves most of it but still there are some rough edges. [0] well, for *me* [1] One of the amusing things I discovered what I have a full 10MB/s+ to the SMB server in the DC over the WireGuard tunnel (and that's because it's 100Mbit/s uplink), while the Synology which sits on the same router on a 1Gbit port only makes 3-5MB/s.
  - aragilar 3y ago
    You don't ever need to use the configuration files, netlink on linux or the cross platform interface documented at https://www.wireguard.com/xplatform/ https://www.wireguard.com/xplatform/ mean you can write your own tooling around an existing inteface. The cryptokey routing is pretty fundamental to wireguard, I'm not sure you could have one without the other.
  - vbezhenar 3y ago
    wg is low-level binary, wg-quick is high-level script wrapper. They're not supposed to have any compatibility at all. You can build any kind of high-level wrapper for wg. One of that wrappers is Network Manager, for example. My issue with wireguard is that it's not enough for full-fledged VPN solution, for example there's no way to push routes to the client or DNS configuration or something like that. Those are very basic needs. If you have 100 users and you decide to change routing scheme, well, you're in a trouble. It is supposed to be solved by higher-level protocols, but I'm not aware of any open standard-de-facto ones with quality implementations.
deleted 3y ago
[deleted]
api 3y ago
Wireguard is more or less just Noise (IK I think) for IP packets. It wouldn’t make much sense for files since there is no counterparty. File encryption is done differently. Edit: http://noiseprotocol.org/ http://noiseprotocol.org/
- actionfromafar 3y ago
  Aren’t encrypted files like noise?
  - ramchip 3y ago
    Noise has one-way handshake patterns for things like file encryption, but the pattern implemented by Wireguard is an interactive one. Compare sections 7.4 and 7.5 in the spec.

mellutussa 3y ago

But why don't use the nice smelling IPSEC if that ticks your boxes?

akira2501 3y ago
It doesn't. It just foresaw the need to be able to dynamically configure tunnels on first connection and specified all of that. Which seems to me is a lot of what fly io has just mostly reimplemented here. In any case the point is I would prefer to just have the basic components available and let me piece them together however I want. Mostly to allow using the underlying technology in more contexts that it is currently available in.
- medstrom 3y ago
  Heh, it really sounds like your needs would be better served with IPSec or something. WireGuard was born precisely because they saw that the whole problem making other existing solutions difficult to audit and insecure-in-practice was their thousand ways to configure. So they did the opposite. Low lines of code, few possibilities. In software you often choose between a small monolith and a big kitchen sink. Once you have 1 more need than the monolith covers, you have to go over to the kitchen sink.

d-z-m 3y ago

> I always felt the disappointment of wireguard was wrapping it up into an opinionated network interface. Why? WireGuard is a VPN, it's pretty normal for VPN solutions to expose themselves as a network interface. > It really should have been a generic "filter" that you could attach to any type of file handle. What's the use-case you had in mind here? I'm not sure how generifying it to a "filter" on any type of file descriptor looks for an interactive protocol like wireguard. > It's always been a weird smelling underspecified IPSEC clone to me[...] Just because there isn't an RFC? I've always found the wireguard paper[0] to be quite readable and thorough in it's specification of the protocol. [0]:https://www.wireguard.com/papers/wireguard.pdf https://www.wireguard.com/papers/wireguard.pdf

justsomehnguy 3y ago
Not the OP, but the main problem with WireGuard[0] is not the protocol[1], it's good, but the opinionated tooling around it, be it .INI style configurations (god I hate it), mutual incompatibility of wg and wg-quick or just outright stupid decisions around storing config files and interacting with the user in the Windows client. Though there are some nuances with the routing selection/filtering too, which gets troublesome when you just need a pipe and run a proper routing protocols over it. ::/0 solves most of it but still there are some rough edges. [0] well, for *me* [1] One of the amusing things I discovered what I have a full 10MB/s+ to the SMB server in the DC over the WireGuard tunnel (and that's because it's 100Mbit/s uplink), while the Synology which sits on the same router on a 1Gbit port only makes 3-5MB/s.
- aragilar 3y ago
  You don't ever need to use the configuration files, netlink on linux or the cross platform interface documented at https://www.wireguard.com/xplatform/ https://www.wireguard.com/xplatform/ mean you can write your own tooling around an existing inteface. The cryptokey routing is pretty fundamental to wireguard, I'm not sure you could have one without the other.
- vbezhenar 3y ago
  wg is low-level binary, wg-quick is high-level script wrapper. They're not supposed to have any compatibility at all. You can build any kind of high-level wrapper for wg. One of that wrappers is Network Manager, for example. My issue with wireguard is that it's not enough for full-fledged VPN solution, for example there's no way to push routes to the client or DNS configuration or something like that. Those are very basic needs. If you have 100 users and you decide to change routing scheme, well, you're in a trouble. It is supposed to be solved by higher-level protocols, but I'm not aware of any open standard-de-facto ones with quality implementations.

deleted 3y ago

[deleted]

api 3y ago

Wireguard is more or less just Noise (IK I think) for IP packets. It wouldn’t make much sense for files since there is no counterparty. File encryption is done differently. Edit: http://noiseprotocol.org/ http://noiseprotocol.org/

actionfromafar 3y ago
Aren’t encrypted files like noise?
- ramchip 3y ago
  Noise has one-way handshake patterns for things like file encryption, but the pattern implemented by Wireguard is an interactive one. Compare sections 7.4 and 7.5 in the spec.