I second this, I would like to be able to setup different keys for multiple wireguard interfaces too.

Best Regards,
afics

This sounds like a good improvement!

I propose to create a concept "named key-pairs", a key-pair could be used on one or multiple interfaces as the user wish'es. And if the user dont specify a key, a default key is selected for him. Allso when specifying a non-existant key-pair the key-pair could be autogenerated with that name.

I don't think it's a good idea, for several reasons.

@jonaswre Can you please point me to the specs where it recommends to use for each interface it's own private key?

@hagbard It's not stated that you MUST use a new private key for each interface. But it states that

[e]ach network interface has a private key [...]
https://www.wireguard.com/#simple-network-interface ⇒ Cryptokey Routing

to set a private key for each interface only makes sense when you are allowed to use different keys for different interfaces. If there would be any withdraw in using multiple keys they would have just omitted the "privateKey" in the config file and set i globally. Since they didn't do that I can't imagine there is one. But I would be interested in learning what withdraws you see that the developers don't see.

Another quote from the papers:

The interface itself has a private key [...]
https://www.wireguard.com/papers/wireguard.pdf ⇒ Cryptokey Routing [p.4]

I think it is a bad idea to use a single key for all tunnels. If you need to change your key on one interface, that would mean disabling all other connections until changed everywhere. And since a normal wireguard install lets you set a private key per interface why shouldn't you be able to do that on vyos?

@runar I would second the "named key-pairs" idea, I had the same in mind. But I wouldn't make auto generation a high priority.

@jonaswre

[e]ach network interface has a private key [...]

Where does it say that you need a different private key for another interface?

The big disadvantage is if you deal with many wireguard users, with multiple interfaces and crypto routing. You will need to identify the correct key for each connection terminate on an interface, the correct port (endpoint as well) and the IP addresses (allowed-ips - both IPv6 and IPv4). That's the first hassle. Now let's imagine one private key might have been compromised, let's say out of 500 interfaces and each interface let's say has 10 peers. With a single pK, a job of a few minutes since you can share the public key with your peer publically.

As I said before I don't see any benefit nor did I find any specification that a new wg interface would need it's own key.

Maybe you could comment on this @zx2c4 ?

Don't use the same private key in two places at the same time. This means it's not a good idea to copy private keys between computers and use it in two places, and probably also means you shouldn't assign the private key to two interfaces on the same computer at the same time, unless you have a really particular and weird setup and know precisely the implications of it. Doesn't sound like that's the case here. So you're probably best doing a private key per interface.

@zx2c4 The private key stays on the system it is generated in a directory only accessible by the user who created it. Now when you create an interface let's say wg01 with 20 peers set up, you hand out 20 time the same public key and to decrypt the incoming traffic you use the single private key. Now, let's say you create an interface wg02, also with 20 peers. Why would it be better to generate a new key pair for wg02 on the same system and use a new private key just for that interface?

Why not specify the keys or the key file location via CLI like other VPN implementations do it?

Well, it's not so much the technical implementation via cli. The private key gets exposed on the computer you generate it, then you transfer it to the vyos box, now you have a duplicate if the origin is not removed. It creates multiple points where you can get the private key. If you have that key and the connection is not secured via pre-shared key, you can decrypt the traffic easily. Or do i See that completely wrong?

@hagbard the private key should stay where its generated. But thats not the point. The point @zx2c4 and I are making, is each interface represent a diffrent Identity. There are only some special cases where you would need the same private key on two interface. Useally you would just add all peers that connect with the same publickey to the same interface. You only need a second interface if there is a second identity you want to assume. For example wg01 might be used to connect to your workplace and wg02 to a vpn service. In that case you would want peers in wg01 and wg02 to know you under different identities.

To be honest i dont understand the difficulty just let the user add a keyalias to the interface.

if config[keyalias] is set {
  If keypair_in_folder(keyalias) {
    privatekey = privateKeys[config[keyalias]]
  } else {
    error
} else {
  privatekey = defaultkey
}

nothing brakes, no mandatory changes to the config. Just more functionality. Feels to me like a no brainer.

i agree with allowing this.

I Don't use this myself, but i can se clear benefits of allowing to use custom key's per interface or on a group of interfaces. this is especially important when we are talking about multi-tendancy and vrf is implemented. (a customer with tunnel X should under no means have any posibillity to enter another customers tunnel Y and so on, in these cases the identity will be in the virtual router and not in this physical device. This also makes sense in the case @jonaswre noted in his last post .

another reason for allowing this is the comments from the author of this protocol @zx2c4, and that the protocol itself is made for doing this.

i propose:

• Creating possibility to generate "named" keys via extending the op-mode generate command
• add a optional key-pair node to the wg interface and use something like @jonaswre purpose to set the custom key if selected.

Then, if the user specifies a key, he will get that key or else it will set the default key.

It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201909102147-amd64.iso or later

In T1572#42883, @hagbard wrote:

It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

Thanks for being quick with the implementation.
Just to clarify the benefit is not really that you could recive traffic over two different Interfaces but sending using two interfaces with sperate identities. Your company may require to change privatekeys frequently while you dont want to change the privatekey for your personal tunnel.

There is no such thing like separate identities. You can either decrypt a package or you can't, that's about it. You basically have to hand out more public keys, you have to maintain more keys. As I mentioned before I only see currently disadvantages so far. However the user can chose what way to go and multiple options are always good. If it helps you, well that's nice to hear.