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.
Why? WireGuard is a VPN, it's pretty normal for VPN solutions to expose themselves as a network interface.
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.
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
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.
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.
nothing prevents you from running bgp over wireguard for route exchange. and there are many quality bgp daemons available*
(* for linux and bsd)
How do I configure my iPhone with BGP routes? Write my own app for VPN? Android, Windows? Linux users who have no idea what BGP is? That won't work, if you're small.
huh yeah, too focused on my infra side of things; mobile vpn is another can of worms.
though I don't know what would prevent any bgp daemon from running in e.g. the wireguard iOS app? there are bgp daemons like gobgp that can be easily integrated in other software.
but this was more meant to be a joke than anything. wireguard is batteries definitely not included, and is why tailscale and the like do exist.
You mean "dynamically" push routes and DNS configurations while the tunnel is already up?
Because you can definitively configure routes and DNS at connection time.
I'm generally comparing it with OpenVPN and it allows to do all that.
What you'd normally think of as Wireguard allows routes at connection time sure, however OP wants a VPN which allows peer B ("server") to define a route and advertise that route to peer A ("client"). So one day the client would route 10.1.0.0/24 down the wireguard tunnel, but not 10.2.0.0/24, the next day however from changing peer B, the config on peer A would change.
Obviously there are many things you could do to allow this (run a routing protocol, build a custom client which gets route information, etc), but the "out of the box" wireguard is a kernel interface, a wg command, and a utility script (wg-quick). I think there are some gui based clients for non-linux based OSes, but it's the same principle.
DNS is nothing to do with the wireguard kernel or userspace, it's configured in the "wg-quick script" (there's a bash function called set_dns), but you can do that however you want.
Wireguard alone isn't what an enterprise would consider to be a "VPN solution", it doesn't push configs from a central location, it's very much a peer-to-peer tool. You can build "enterprise" features like centrally defined routes or DNS on top of that, or not, it's not opinionated.
Yep, this one too.
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/ 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.
But why don't use the nice smelling IPSEC if that ticks your boxes?
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.
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.
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/
Aren’t encrypted files like noise?