ideas/features

Hello,

as I mentioned before I'm learning WireGuard and there are certain things that I need but didn't find them yet in the docs (either because I didn't read enough yet or because it's just not there). I'll list them here and you'll tell whether it is worth for a new feature or not; or whether I should continue reading...

1. Labels.

Is it possible to add an optional label to a peer to make it a bit more usable for humans (who tend not to remember IPs or keys). A label associated with a peer is just a string (could be a first/last name, email, "NY Office" or whatever). So if you read through the .conf file or query wg for that label - you can get the right IP to SSH to, if needed.

In the .conf file it could probably be realized through some sort of comments before each [Peer] section (didn't check whether # or something actually work). But querying wg from command line for a label is also handy...

2. Includes in .conf files.

Is it possible to include .conf files in the main wg0.conf file? Like:

[Interface]
...

Include ./us_peers.conf
Include ./eu_peers.conf

[Peer]
...

This way you can group peers into pools, so there will be a bit more order/structure...

But what I envision it for is easy maintenance of an N:N mesh of nodes where each node can communicate with all others. Each node's .conf file will consist of only 2 things: its own [Interface] with private data and one Include ./my_complete_mesh.conf with the public data of all [Peer]s. This single Include file can be put in a central location (or mirrored to several locations for failover) and all peers will pull it from there once in a while through a cron job or it can be pushed to them with rsync/ansible/ssh or whatever.

What do you think?

Thanks.

Don't ask whether you should read the docs. Of course you should, that's the whole purpose of documentation! :)

This has been suggested a few times already, but so far noone has bothered to implement it. I don't see any fundamental issues with the idea, though.

As documented in wg(8), wireguard's config files can indeed contain comments.

The config parser doesn't support file inclusion. It doesn't seem to be worth the hassle to add it either, since there's another way to combine multiple config files: wg's "addconf" verb. It'll load a config file without wiping out prior configuration, so you can combine config files by chaining multiple "wg addconf" verbs.

If atomicity is desired, you could also concatenate the config files to a temporary file which you then supply to wg setconf (or perhaps even pipe the concatenated files to "wg setconf /proc/self/fd/0").

Cheers,
Luis

I would probably just use a hosts file for this. That way, applications don't have to worry about "how do I get this info from wg," they just resolve it in the normal way. Am I missing something?

This way you'll have to maintain two files, hope that Peers' IPs do not change too often, so you have to re-map them. But generally it's a solution. Thank you!

Hi ST,

A lot of people have asked for this; there's some discussion on the list. I'm not entirely opposed to it, but the use case does seem extremely limited. Often times you want a label so that you can then correlate it with another piece of information to find more info in a database or in an API. But in that case, why not use the public key as the piece of correlating information? On the other hand, it would make things a bit nicer from an administrative perspective if you're using the basic wg utility and want a bit more information in there.

I've implemented this feature in a branch, but keep hesitating each time I think about merging it. I should revisit it and come up with something definitive one way or another.

Seems useful, though a bit awkward to have in the .ini syntax. Many systems, instead of include directives, choose to either go with an external preprocessor (m4, cpp, bash, etc) for this kind of thing, or go with the conf.d approach:
/etc/wireguard/someserver.conf.d/{001-something,002-anotherpart,003-alsothis}. The conf.d approach has the advantage of being very easy to understand and deal with, and one can see clearly how it would work with wireguard -- wg setconf wg0 <(cat /etc/wireguard/someserver.conf.d/*). Would that handle your use case?

Jason