Bug: Surfshark wireguard account blocked #2595
Comments
|
@qdm12 is more or less the only maintainer of this project and works on it in his free time.
|
Did Surfshark tell you it was about those handshakes??? These might be unrelated to the ban if not. By default the keepalive / handshakes is disabled Line 106 in 68ddbfc But the VPN server can do it if it wants to, which seems to be the case here 🤔 Honestly I'm not too sure! But let me know what Surfshark told you, and, if they didn't specify, ask their support why this happened? |
qdm12
changed the title
Yes that's how keepalive works. And these are debug logs logged out by the wireguard-go userspace implementation. From the logs you showed, it doesn't seem like the VPN is self restarting (aka auto healing) at all. Plus these logs seem to be about the 17 november, not the 19 or 21 november which might be more relevant according to the events.
That's really a BS answer really. If they can track your connection activity over multiple days and ban your account, they ARE in fact storing this information. Which is fine really, the only not fine part is to use this as an excuse to not dig out what the hell happened.
As long as you use the same wireguard configuration, this acts as a single 'peer' (aka client device), especially since there is no connection or disconnection notification with Wireguard (unlike openvpn), so even if it reconnects many times, it would still act as one connection. Now for DDoS attack, that's also quite unlikely, depending on the containers you have using gluetun. Finally, what I would recommend is to set back the log level to info to discard all this wireguard debug information, which is just normal behavior as far as I know. For context, the kernelspace wireguard implementation doesn't log anything (since it's, well, in the kernel) and likely behaves the same as the userspace implementation (developed by the Wireguard team). Closing this because it's a bit of a dead end at this point; if you ever find what's wrong and that something can be fixed in Gluetun for this, please open another issue referencing this one! Thanks! |
|
Closed issues are NOT monitored, so commenting here is likely to be not seen. This is an automated comment setup because @qdm12 is the sole maintainer of this project |
|
Hello @qdm12, Thanks for your great support.
Unfortunately, they didn't confirm if it was the reason, in several emails exchanged, the answer was they don't have logs.
+1
The account has been unlocked, at first moment, 24h after it was permanent blocked. After this I tried to investigate and I get this container logs, and this container was in trouble for a long time. According to this logs, at least it takes 3 days constantly trying to connect. It starts here And permanent until here: I suspect that the connection was killed, and after this it starts try self restart without success I have a sequence of ~16300 line with: It wasn't every second but it was constantly, and the first account block notification was at 19/11/2024, 17:46, the permanent block was 21/11, 07:40. I need to monitor the container in feature, and adjust the variable. |
Is this urgent?
Yes
Host OS
Debian
CPU arch
aarch64
VPN service provider
Surfshark
What are you using to run the container
docker-compose
What is the version of Gluetun
v3.39.1
What's the problem 🤔
I already received an email saying that my account was blocked.
I tried to get more information in my container about what caused the account to be blocked, what I found was many wireguard handshake and keepalive attempts.
Can you help if I'm missing something in the configurations that cause this loop?
Share your logs (at least 10 lines)
Share your configuration
The text was updated successfully, but these errors were encountered: