Hello My friends!
I want to make sure that only one person can use a WireGuard config at a time.
If someone copies the config file to another device, I don’t want both of them to be able to connect at the same time.
Is there a way to block or prevent two users from using the same WireGuard config?
I copied the tunnel configuration from my Windows machine to another Windows machine, and I was able to activate both tunnels at the same time so but I don’t want that to happen.
And you didn’t run into conflicts with allowed IP addresses etc ?
As @holvoetn implies, your testing was somehow faulty.
Wireguard can never connect two peers that have the same key. This is a characteristic of the wireguard protocol itself and cannot in fact be altered.
NO.
I was monitoring the current ENDpoint in the peer window, and when the other machine activate the tunnel the IP changed.
Please send a screenshot showing the two connections simultaneously present with the same key.
Endpoint IP perhaps.
But not the internal IP of the peer.
I would like to see you can send traffic over both peers at the same time.
@holvoetn: It’s not really just about the IP conflict. Wireguard employs what’s called cryptokey routing. This means that the only identity the peer has is the asymmetric key for the peer. The endpoint address, ephemeral key and routing information and all other things are associated only to that.
I know.
The key combo is used for the wireguard server to determine what needs to be send where.
A sort of internal routing table.
If 2 peers have the same key and use the tunnel at the same time, that whole tunnel will break down since the server will not know where to go to.
I was just asking to send traffic from both sites to make it clear it will not work.
Technically, your tests appear to “work” because WireGuard is built with roaming support in its design. Your two Windows machines with the exact same WG configuration would appear to the other side (for example the peer that is your router) as though they are a single client that is constantly roaming. Depending on which of the Windows machines tries to re-establish the handshake with the other side last, the other side (router peer) will update the last known endpoint of the “roaming” peer accordingly.
In theory, you can, on one of the PC, load a full website in the web browser, with all traffic tunneled through WG. Then switch to the 2nd PC, and load another website, also through the tunnel, and everything work. You can even switch back to the 1st PC and load something else that use the tunnel and it would work too. There might be some delay and packet lost that need retransmission, and each time a new handshake must be performed, but those are similar to what happens when you use WG on your mobile device and roam between 5G and WiFi networks while walking.
In theory, some open TCP connections on the two machines might survive the back & fort “roaming” too, with the condition that they are not constantly transferring data at the same time. If the two machines are not constantly transferring data but only in bursts with multiple seconds of inactivity in between (like when you are browsing website or chatting) then you won’t even notice the delays and hick ups.
So, back to the original question: there would be no way to prevent what you describe, because otherwise roaming wouldn’t work anymore.
Interesting read here:
https://www.procustodibus.com/blog/2021/01/same-key-multiple-peers/
@CGGXANNX: Your point is roughly correct: the tunnel will work for the peer with whom the last handshake was performed.
The situation, however, is different from roaming. During roaming the endpoint ip changes because a cryptographically sound packet arrives from a new ip address. The packets are validated according to the ephemeral key, which in case of real roaming is preserved. In the described case the two clients have the same asymmetric key, but different ephemeral keys, so data sent over the tunnel will fail validation. It’s only by doing a new handshake that the endpoint address changes.
And if I may add … that roaming works beautifully well.
Used it already with connection from laptop to home while driving 130km/h on highway in France (and before anyone starts: I wasn’t driving, my wife was 
)
Minor disconnects when phone hopped from cell to cell but each time the connection came right back up.
Yes, that why I wrote above that each time, a new handshake needs to be performed by the last client, which will cause some delay. But WG handshake are nearly instant, so if the devices take turn to talk to the other side, the problems caused by the handshake might not be noticeable.
That’s my point: no handshake will be initiated until the ephemeral key times out. Data will simply be sent with the existing one and dropped silently on the other side.
Otherwise yes, intermittently a somewhat functioning connection will probably be present.
Hello my friend, yes you are right.
The mistake was on my side. However, I still have the issue that the same interface (WireGuard configuration) can be used on multiple devices.
What I mean is: is there a way to lock the configuration to a specific PC?
To put it simply: I created a WireGuard tunnel and ran it on my PC, but when I copied the configuration to another PC, it worked there as well.
But again: you can NOT use both connections at the same time.
Anything using SSH keys or certificates has the same problem.
If you can copy those from the first device, you can use it again on the second one.
How do you handle that ?
A second layer is needed then. Account/passwd or so.
MFA over WG is not yet that common (Tailscale has already been mentioned before).
It seems there are services available who can take that burden out of your hands (defguard being the first one I encounter but I have no experience how it works).
This is not quite true. There are multiple situations where a new handshake might be performed before the ephemeral key times out:
Protocol & Cryptography - WireGuard
The “ephemeral key timeout” is related to the REKEY_AFTER_TIME and REKEY_AFTER_MESSAGES. However. this might apply earlier if keep-alive is set:
- If we have sent a packet to a given peer but have not received a packet after from that peer for
KEEPALIVE + REKEY_TIMEOUTms, we initiate a new handshake.
Here is where the limits are defined messages.h « wireguard « net « drivers - wireguard-linux - WireGuard for the Linux kernel.
So if the “wrong” peer (the Windows PC that is not the one with the lastest handshake) tries to send something, its packets will be silently dropped by the other side. But with a usual recommended keep-alive setting from 25s and REKEY_TIMEOUT being 5s, after about 30s that Windows PC will initiate a new handshake. This is much shorter than the 120s of REKEY_AFTER_TIME.
Yep. And also all sorts of beat-like interaction/synchronization of these timers is possible. What you won’t get is a stable connection from either endpoint.
Typically a wireguard configuration will have a different public Key generated per device so windowsA laptop and WindowsB laptop have different public Keys and different assigned wg IP addresses.
So if you need something else on top…perhaps
@anav Hello anav.! How are you!
Based on your experience with WireGuard, is there a solution out there for this problem?
**What I mean is: is there a way to lock the configuration to a specific PC?
To put it simply: I created a WireGuard tunnel and ran it on my PC, but when I copied the configuration to another PC, it worked there as well.**
How can I lock the WireGuard tunnel so that only one user can use it?
In case someone steals my tunnel configuration from my Windows machine without my knowledge, I want to prevent them from being able to run the tunnel and access my network.