Since apparently I'm gonna dig out all the issues today :o
I noticed that for some reason Wireguard has started thinking there is an active connection with the last connected device even after that device has disconnected. I've been using this current config for ages and ages now, haven't made any type of change other than the recent upgrade to 23.7.x. I initially thought my key was somehow compromised when I saw an active connection that wasn't mine. But after some testing I can reproduce the problem 100% of the time. The only way to clear the old connection is to restart the service, which would be hard to do obviously if I was remote ;D. I'm using the os-wireguard vs go, not sure if there was a recent update to the plugin that maybe broke it? Thoughts? Without logs I'm not sure how to troubleshoot why this is happening.
From what I understand, wireguard is stateless. It doesnt destroy idle connections where a handshake didn't happen for some time. A client also doesn't send "Im disconnected now" to a wireguard server.
Quote from: Monviech on August 28, 2023, 06:17:58 AM
From what I understand, wireguard is stateless. It doesnt destroy idle connections where a handshake didn't happen for some time. A client also doesn't send "Im disconnected now" to a wireguard server.
It used to show active connections under the status tab. They will fall off on disconnecting, how that mechanism works I'm not sure. The issue here is with the active connection up it won't let me connect until that existing connection is no longer connected. The only way I've found is restarting the service.
Sent from my Pixel 6 Pro using Tapatalk
I am also experience the same problems with wireguard kernel and was that the reason why I was still using the go version. The best solution I could find for now is to configure the endpoint with [Keepalive Interval = 25]
hope this will be fixed also
Quote from: RamSense on August 28, 2023, 07:37:14 AM
I am also experience the same problems with wireguard kernel and was that the reason why I was still using the go version. The best solution I could find for now is to configure the endpoint with [Keepalive Interval = 25]
hope this will be fixed also
Has anyone put in a bug report? If not I'd be glad too. Surprised more aren't talking about this if it's a bug though.
I'll check out adding a keepalive ot the endpoint.
Edit:
Adding the keepallve didn't seem to help, my session still remains open. Which is sorta what I would expect from a keepalive, but thought maybe it might fail to send a keepalive and terminate the existing connection to allow a new one. I'm a derp, added it to the server side you clearly said client. I added this to my client config and it indeed seems to solve the issue. I have zero clue how that fixes things, but glad it's a solid workaround.
Edit #2: This feels like a new issue, I didn't see this issue till after the .2 update.
Wireguard requiring keepalive 25 isn't a new issue. It was introduced in 23.1 IIRC.
Perhaps the issue will be resolved in the new plugin rewrite but since keepalive 25 works for the time being I haven't felt the need to dig into what the root cause is.
Quote from: CJ on August 28, 2023, 03:29:02 PM
Wireguard requiring keepalive 25 isn't a new issue. It was introduced in 23.1 IIRC.
Perhaps the issue will be resolved in the new plugin rewrite but since keepalive 25 works for the time being I haven't felt the need to dig into what the root cause is.
Hmm, maybe I somehow didn't notice the vpn being broken after the upgrade till now. Regardless I'm glad there is a workaround.
Sent from my Pixel 6 Pro using Tapatalk