hi,
atm to have different metrics per link you have to define a concentrator (i call the wireguard instance) and peer for every different link cause you can only set the metric for the concentrator and not the peer. this is needed on duplicate destinations via different links.
if we could set the routing metric for every peer instead, we could have one concentrator per instance and attach severals peers with different metrics to it. this would enhance usability a lot.
any thoughts?
I wrote a different response then upon review I wondered:
Are you asking for Wireguard to permit the same route, via different peers on the same WG interface?
Then in addition (as your title says), allowing metrics for each route/peer?
(Initially, I thought you meant MTU, given the design of Wireguard includes the IPs its routing - 'cryptokey routing' is the term they use. This restricts assignment of the same IPs to different peers.)
Better use one interface per peer you want to route otherwise the cryptokey routing might cause trouble
in general yes.
there are routes to the same networks but with different peers.....maybe different hoppcount to the same nets.
Since this is the case, to be clear, you won't be able to configure them on the same Wireguard interface. See: https://www.wireguard.com/#cryptokey-routing for more information. You'll need to utilize 2 separate Wireguard interfaces for this use case.
I'm not sure how that relates to the "inside" or encapsulated traffic within the tunnel, but OK.
imho this is no Cryptokey Routing Table problem instead of a ip/route problem.
in luci the metric is taken from the plain network settings. so nothing wireguard specific. i have to dive into this a bit to see how its done. there should be a way to do it for each peer.
manually i can set the metric for sure.
Yes, and you'd set the metric for 2 separate Wireguard interfaces.
Correct, hence why there isn't a per peer metric setting.
Feel free to verify the information we provided yourself.
Just to be clear, this isn't a "table", it's a builtin feature of Wireguard. Wireguard is designed so multiple peers on the same interface cannot have overlapping network ranges. Since using the term "table" could have other meaning and implications in this discussion, I wanted to highlight that point.
I agree with @lleachii a use case for metric is usally multiple default routes which need 0.0.0.0/0 as allowed IPs if you have this the same for multiple peers it will lead to undefined behaviour of the crypto key routing.
So just create another tunnel to do this, you can create as much tunnels as you want 
It is trivial to make it, I did just for fun but I do not see a valid use case for it
Note that using metrics for WireGuard is not working at all at the moment in Master/Main Snapshot builds, I created a PR to implement this: https://github.com/openwrt/openwrt/pull/23280
ah, i see. i know felix.
dhrm1k addresses this peer metrik problem in your pr
Well that always comes in handy
