Status and search

[qippur]

Not a bug, but a feature request.
Because this seems to me the most complete pure python approach to wireguard.

1. Is it possible to pick a peer by friendly name or by public key? I mean a method that returns a peer given a friendly name or a public key? Friendly names should be checked to be unique.
2. Is it possible to manage a status for a peer? Active, Inactive, Banned. Something like: inactive and banned peers entries in config file are prepended by a # and a distinctive character (e.g #! for inactive, #* for banned)

These two features could be the foundation of a new set of possibilities, like inactivate idle peers and - with little additional effort - 2FA for wireguard.

[jaharkes]

I looked at the friendly name, but the most straight forward solution ended up being a trivial 'iterate through the peers and return as soon as the friendly name matches'.

As far as the active/inactive/banned, I am not quite getting a clear picture of the idea. In theory we could probably recognize a commented Peer section and treat that as inactive, and when a peer is deactivated, write it's entries prefixed with '# '. The normal wg/wg-quick tools would simply ignore the commented peers and not pass them to the wireguard device. And when the peer's keys don't exist, as far as wireguard routing is concerned, the peer doesn't exist and will not be able to connect. But there would be no functional difference between inactive or banned, so I don't understand why there would be two different types of indicating that the peer should be ignored.

So it seems like you have some higher level thinking about activating/deactivating/banning peers possibly with some 2fa mechanism. But at that point you could also do something like rebuilding the wireguard config based on your internal state, whether we comment or not, the file needs to be rewritten either way.

[qippur]

Hi. Thank you for your reply! States are meant to store the availability of a connection directly inside the wireguard config file. In our plan, once a user connects, is restricted to a VLAN with just an authentication page. If authentication succeeds, the peer is allowed to connect to the real allowed hosts. We would use the "friendly name" field to store the username associated with the peer. We also wanted to differentiate between "inactive" and "banned". "inactive" is for a peer that makes no traffic for some time. "banned" is for someone that fails login for a number of times. I realize that if a peer is in an "inactive" state it could not connect to authenticate. This state would be useful only if the authentication is performed before the connection of the peer. In the current scenario only "active" and "inactive" (commented out) states are sufficient. Also, a "comment" line to better identify the person behind the peer would be useful. Does that make sense? ciao Il giorno mer 18 feb 2026 alle ore 05:26 Jan Harkes < ***@***.***> ha scritto:

…

*jaharkes* left a comment (cmusatyalab/wireguard-tools#23) <#23 (comment)> I looked at the friendly name, but the most straight forward solution ended up being a trivial 'iterate through the peers and return as soon as the friendly name matches'. As far as the active/inactive/banned, I am not quite getting a clear picture of the idea. In theory we could probably recognize a commented Peer section and treat that as inactive, and when a peer is deactivated, write it's entries prefixed with '# '. The normal wg/wg-quick tools would simply ignore the commented peers and not pass them to the wireguard device. And when the peer's keys don't exist, as far as wireguard routing is concerned, the peer doesn't exist and will not be able to connect. But there would be no functional difference between inactive or banned, so I don't understand why there would be two different types of indicating that the peer should be ignored. So it seems like you have some higher level thinking about activating/deactivating/banning peers possibly with some 2fa mechanism. But at that point you could also do something like rebuilding the wireguard config based on your internal state, whether we comment or not, the file needs to be rewritten either way. — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXMXUODRO7JRRATGSGHJKD4MPSYNAVCNFSM6AAAAACQKQRK3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMJYGUZDANRXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>