Anyone else having the issue of how to distinguish traffic from specific peers, and how did you solve it?

Other than having an interface per peer of course.

Doesn't the peer have a VPN-IP that you know?

Eg: my SQL server has one WG and I've got N clients. They are each connecting with their key and assigned IP. So firewall rules will do it.

Well, yes, but then you are relying on IP address based auth of some sort. It's just more stuff to keep around, share, and make sure its correct.

If routing was possible with just the public key, after wg has verified the packets, I would assume it'd be easier to maintain (and more flexible).

For example, I could run a "public" wg peer where peers could just join me without me messing with cidrs and whatnot. I wouldn't care what their vpn ip is, as I may not be their only peer and they could be using any number of internal addressess.

I assume you're looking at encrypted traffic on the wire? You can see the endpoint it's going to, and "sudo wg" will show those endpoint IP/port, each of which will be unique.

Obviously inside the tunnel that's what the source IP is for.

"any peer public IP can impersonate any other (if it has the required WireGuard peer key"

Right. So you want to put in IP filtering on top of that, having already had a compromised connection?

The biggest issue I have with wireguard is the tendancy for clients to actually show the private key. It shouldn't generally be visible, there's no needs.

It makes a little sense, for instance say you've got a public server on a fixed IP that an attacker manages to exfiltrate the key but nothing else. This'd keep them out of your network.

But I think it'd probably be better to alert the administrator rather than simply blocking them.

Swiss cheese theory, or defense in depth.

So, install and use ufw or another simple filtering tool or iptables directly.

I'm no expert in Wireguard other than setting it up for personal use at home, so don't quite know more advanced configurations, but this seems like a separate issue relatively easily handled. That said, for my own use case, I wouldn't want to restrict IPs beyond maybe nation restrictions as I expect to connect from untrusted locations.

Agreed this ask makes no sense to me.

It sounds like they want the system to somehow know which IP is supposed to be associated with a particular key.

You already can restrict public IPs using iptables…

That actually sounds kind of useful. The firewall doesn’t know about keys. It might be handy to say “this key can only ever connect from this IP”, like when setting up links between fixed business systems. If you know a key can never be legitimately used from any other IP in the world, why not add defense in depth?

I wouldn’t lose sleep over not having that. It’d be a nice bonus though.

This doesn't work because you don't want every peer to be ip-range locked, you want this peer to be ip-range locked.

Say you have a WG server on a VPS that your laptop and your Plex server connect to. Your laptop should be allowed to connect anywhere, but you should be suspicious if your Plex server connects from anywhere other than your home address.

You're probably familiar with this feature if you've ever used MySQL, users have a username and host spec.

I'm slightly confused. What the author seems to be saying (although he doesn't state it quite so directly) is that even if you specify "Endpoint = ip:port" in the configuration, that Wireguard will update that if it receives a correctly authenticated packet from a different IP address.

At first, I thought this sounded like a bug, but actually reading the documentation [1] it's clearly as-designed. It's referred to as "initial configuration" (their italics) and then explains how it updates.

I see there's an official mailing list for wireguard. Perhaps he should suggest a new feature there to disable that roaming functionality.

[1] https://www.wireguard.com/ in the "Built-in Roaming" section