Closed clpir3s closed 2 days ago
github-actions[bot]
commented
4 days ago @qdm12 is more or less the only maintainer of this project and works on it in his free time. Please:
qdm12
commented
3 days ago 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.
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
https://github.com/qdm12/gluetun/blob/68ddbfc0fed316f2e22c3b979b2186522a194da1/Dockerfile#L106
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
commented
2 days ago I suspect that the connection was killed, and after this it starts try self restart without success It wasn't every second but it was constantly I have a sequence of ~16300 line with
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.
Following our commitment to the No-logs Policy, we do not store information about what exactly triggered the blocking of any particular account. So I am not able to specify the exact reason for which your account was blocked.
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.
Our automated infrastructure maintenance system blocked your account again because it detected network resource usage anomalies associated with service abuse. Such anomalies may result from irregular traffic volumes (e.g. DDoS attacks), extremely large numbers of connected devices, and similar triggers. Repeated service abuse results in permanent account termination, thus this time we are unable to unblock your account nor issue a refund.
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!
github-actions[bot]
commented
2 days ago Closed issues are NOT monitored, so commenting here is likely to be not seen. If you think this is still unresolved and have more information to bring, please create another issue.
This is an automated comment setup because @qdm12 is the sole maintainer of this project which became too popular to monitor issues closed.
clpir3s
commented
1 day ago Hello @qdm12,
Thanks for your great support.
Did Surfshark tell you it was about those handshakes??? These might be unrelated to the ban if not.
Unfortunately, they didn't confirm if it was the reason, in several emails exchanged, the answer was they don't have logs.
Unfortunately, as Surfshark guarantees a strict no-logs policy for Surfshark services, meaning that your activities using Surfshark services are provided by an automated technical process, and are not monitored, recorded, logged, stored, or passed to any third party in any way, we will not be able to specify the reason of your account suspension. We do not store connection time stamps, session information, used bandwidth, traffic logs, IP addresses, or any other data in any form.
+1
Following our commitment to the No-logs Policy, we do not store information about what exactly triggered the blocking of any particular account. So I am not able to specify the exact reason for which your account was blocked.
Our automated infrastructure maintenance system blocked your account again because it detected network resource usage anomalies associated with service abuse. Such anomalies may result from irregular traffic volumes (e.g. DDoS attacks), extremely large numbers of connected devices, and similar triggers. Repeated service abuse results in permanent account termination, thus this time we are unable to unblock your account nor issue a refund.
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
2024-11-13T21:19:55Z INFO [healthcheck] healthy!
2024-11-17T03:43:40Z WARN Caught OS signal terminated, shutting down
2024-11-17T03:43:44Z INFO updater ticker: terminated āļø
2024-11-17T03:43:44Z INFO http server: terminated āļø
2024-11-17T03:43:44Z INFO dns ticker: terminated āļø
2024-11-17T03:43:44Z INFO control: terminated āļø
2024-11-17T03:43:44Z INFO updater: terminated āļø
2024-11-17T03:43:44Z INFO tickers: terminated āļø
2024-11-17T03:43:44Z INFO HTTP health server: terminated āļø
2024-11-17T03:43:44Z DEBUG [wireguard] closing controller client...
2024-11-17T03:43:44Z DEBUG [wireguard] removing IPv4 rule...
2024-11-17T03:43:45Z WARN Shutdown timed out
========================================
========================================
=============== gluetun ================
========================================
=========== Made with ā¤ļø by ============
======= https://github.com/qdm12 =======
========================================
========================================
Running version v3.39.1 built on 2024-09-29T18:16:23.495Z (commit 67ae5f5)
š£ All control server routes will become private by default after the v3.41.0 release
š§ Need help? ā Discussion? https://github.com/qdm12/gluetun/discussions/new/choose
š Bug? āØ New feature? https://github.com/qdm12/gluetun/issues/new/choose
š» Email? quentin.mcgaw@gmail.com
š° Help me? https://www.paypal.me/qmcgaw https://github.com/sponsors/qdm12
2024-11-17T03:46:49Z INFO [routing] default route found: interface eth0, gateway 10.0.1.1, assigned IP 10.0.1.238 and family v4
2024-11-17T03:46:49Z INFO [routing] local ethernet link found: eth0
2024-11-17T03:46:49Z INFO [routing] local ipnet found: 10.0.0.0/16
2024-11-17T03:46:50Z INFO [firewall] enabling...
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --policy INPUT DROP
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --policy OUTPUT DROP
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --policy FORWARD DROP
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --policy INPUT DROP
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --policy OUTPUT DROP
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --policy FORWARD DROP
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --append INPUT -i lo -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i lo -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o lo -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o lo -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/ip6tables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-17T03:46:50Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o eth0 -s 10.0.1.238 -d 10.0.0.0/16 -j ACCEPT
2024-11-17T03:46:51Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -d ff02::1:ff/104 -j ACCEPT
2024-11-17T03:46:51Z DEBUG [firewall] /sbin/iptables --append INPUT -i eth0 -d 10.0.0.0/16 -j ACCEPT
2024-11-17T03:46:51Z INFO [firewall] enabled successfully
2024-11-17T03:47:22Z INFO [storage] merging by most recent 20478 hardcoded servers and 20478 servers read from /gluetun/servers.json
2024-11-17T03:47:31Z DEBUG [netlink] IPv6 is not supported after searching 1 routes
2024-11-17T03:47:31Z INFO Alpine version: 3.20.3
2024-11-17T03:47:31Z INFO OpenVPN 2.5 version: 2.5.10
2024-11-17T03:47:31Z INFO OpenVPN 2.6 version: 2.6.11
2024-11-17T03:47:31Z INFO Unbound version: 1.20.0
2024-11-17T03:47:31Z INFO IPtables version: v1.8.10
2024-11-17T03:47:31Z INFO Settings summary:
āāā VPN settings:
| āāā VPN provider settings:
| | āāā Name: surfshark
| | āāā Server selection settings:
| | āāā VPN type: wireguard
| | āāā Countries: Finland
| | āāā Wireguard selection settings:
| āāā Wireguard settings:
| āāā Private key: QL8...Gs=
| āāā Interface addresses:
| | āāā 10.14.0.2/16
| āāā Allowed IPs:
| | āāā 0.0.0.0/0
| | āāā ::/0
| āāā Network interface: tun0
| āāā MTU: 1400
āāā DNS settings:
| āāā Keep existing nameserver(s): no
| āāā DNS server address to use: 127.0.0.1
| āāā DNS over TLS settings:
| āāā Enabled: no
āāā Firewall settings:
| āāā Enabled: yes
| āāā Debug mode: on
| āāā Outbound subnets:
| āāā 192.168.1.0/24
āāā Log settings:
| āāā Log level: debug
āāā Health settings:
| āāā Server listening address: 127.0.0.1:9999
| āāā Target address: 1.1.1.1:443
| āāā Duration to wait after success: 30s
| āāā Read header timeout: 100ms
| āāā Read timeout: 500ms
| āāā VPN wait durations:
| āāā Initial duration: 10s
| āāā Additional duration: 11s
āāā Shadowsocks server settings:
| āāā Enabled: no
āāā HTTP proxy settings:
| āāā Enabled: yes
| āāā Listening address: :8888
| āāā User:
| āāā Password: [not set]
| āāā Stealth mode: yes
| āāā Log: yes
| āāā Read header timeout: 1s
| āāā Read timeout: 3s
āāā Control server settings:
| āāā Listening address: :8000
| āāā Logging: yes
| āāā Authentication file path: /gluetun/auth/config.toml
āāā OS Alpine settings:
| āāā Process UID: 1030
| āāā Process GID: 101
| āāā Timezone: Europe/Lisbon
āāā Public IP settings:
| āāā Fetching: every 720h0m0s
| āāā IP file path: /tmp/gluetun/ip
| āāā Public IP data API: ipinfo
āāā Version settings:
āāā Enabled: yes
2024-11-17T03:47:33Z INFO [routing] default route found: interface eth0, gateway 10.0.1.1, assigned IP 10.0.1.238 and family v4
2024-11-17T03:47:33Z DEBUG [routing] ip rule add from 10.0.1.238/32 lookup 200 pref 100
2024-11-17T03:47:33Z INFO [routing] adding route for 0.0.0.0/0
2024-11-17T03:47:33Z DEBUG [routing] ip route replace 0.0.0.0/0 via 10.0.1.1 dev eth0 table 200
2024-11-17T03:47:33Z INFO [firewall] setting allowed subnets...
2024-11-17T03:47:33Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o eth0 -s 10.0.1.238 -d 192.168.1.0/24 -j ACCEPT
2024-11-17T03:47:33Z INFO [routing] default route found: interface eth0, gateway 10.0.1.1, assigned IP 10.0.1.238 and family v4
2024-11-17T03:47:33Z INFO [routing] adding route for 192.168.1.0/24
2024-11-17T03:47:33Z DEBUG [routing] ip route replace 192.168.1.0/24 via 10.0.1.1 dev eth0 table 199
2024-11-17T03:47:33Z DEBUG [routing] ip rule add to 192.168.1.0/24 lookup 199 pref 99
2024-11-17T03:47:33Z DEBUG [routing] ip rule add to 10.0.0.0/16 lookup 254 pref 98
2024-11-17T03:47:33Z INFO [dns] using plaintext DNS at address 1.1.1.1
2024-11-17T03:47:33Z INFO [http proxy] listening on :8888
2024-11-17T03:47:33Z INFO [http server] http server listening on [::]:8000
2024-11-17T03:47:33Z INFO [healthcheck] listening on 127.0.0.1:9999
2024-11-17T03:47:33Z DEBUG [wireguard] Wireguard server public key: +nv/Z8I2VS0eRdZwkpQW3U9RmsboTz2MUF94jVg5w10=
2024-11-17T03:47:33Z DEBUG [wireguard] Wireguard client private key: QL8...Gs=
2024-11-17T03:47:33Z DEBUG [wireguard] Wireguard pre-shared key: [not set]
2024-11-17T03:47:33Z INFO [firewall] allowing VPN connection...
2024-11-17T03:47:33Z DEBUG [firewall] /sbin/iptables --append OUTPUT -d 193.56.113.48 -o eth0 -p udp -m udp --dport 51820 -j ACCEPT
2024-11-17T03:47:33Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o tun0 -j ACCEPT
2024-11-17T03:47:33Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o tun0 -j ACCEPT
2024-11-17T03:47:33Z DEBUG [netlink] wireguard family not found, trying to load wireguard kernel module
2024-11-17T03:47:33Z DEBUG [netlink] failed loading wireguard kernel module: getting modules information: modules directory not found: /lib/modules/6.8.0-1014-raspi, /usr/lib/modules/6.8.0-1014-raspi are
2024-11-17T03:47:33Z INFO [wireguard] Using userspace implementation since Kernel support does not exist
2024-11-17T03:47:37Z INFO [wireguard] Connecting to 193.56.113.48:51820
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: handshake worker 2 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: encryption worker 1 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: decryption worker 1 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: handshake worker 1 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: encryption worker 2 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: decryption worker 2 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: handshake worker 4 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: encryption worker 3 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: decryption worker 3 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: handshake worker 3 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: encryption worker 4 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: decryption worker 4 - started
2024-11-17T03:47:37Z DEBUG [wireguard] UAPI: Updating private key
2024-11-17T03:47:37Z DEBUG [wireguard] UAPI: Updating fwmark
2024-11-17T03:47:37Z DEBUG [wireguard] UAPI: Removing all peers
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - UAPI: Created
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - UAPI: Updating endpoint
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - UAPI: Removing all allowedips
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - UAPI: Adding allowedip
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - UAPI: Adding allowedip
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: TUN reader - started
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: event worker - started
2024-11-17T03:47:37Z DEBUG [wireguard] Interface up requested
2024-11-17T03:47:37Z DEBUG [wireguard] UDP bind has been updated
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Starting
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: receive incoming v4 - started
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Routine: sequential sender - started
2024-11-17T03:47:37Z DEBUG [wireguard] Interface state was Down, requested Up, now Up
2024-11-17T03:47:37Z DEBUG [wireguard] Routine: receive incoming v6 - started
2024-11-17T03:47:37Z DEBUG [wireguard] Interface up requested
2024-11-17T03:47:37Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Routine: sequential receiver - started
2024-11-17T03:47:37Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the
2024-11-17T03:47:39Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Sending handshake initiation
2024-11-17T03:47:39Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Received handshake response
2024-11-17T03:47:39Z INFO [healthcheck] healthy!
2024-11-17T03:47:40Z INFO [ip getter] Public IP address is 193.56.113.49 (Finland, Uusimaa, Helsinki)
2024-11-17T03:47:41Z INFO [vpn] You are running the latest release v3.39.1
2024-11-17T03:47:52Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
2024-11-17T03:48:03Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Sending keepalive packetAnd permanent until here:
2024-11-20T08:12:01Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
2024-11-20T08:12:31Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
2024-11-20T08:13:01Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
2024-11-20T08:13:31Z DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packetI suspect that the connection was killed, and after this it starts try self restart without success
2024-11-20T08:13:45Z WARN Caught OS signal terminated, shutting down
2024-11-20T08:13:45Z INFO updater ticker: terminated āļø
2024-11-20T08:13:45Z INFO dns ticker: terminated āļø
2024-11-20T08:13:45Z INFO http server: terminated āļø
2024-11-20T08:13:45Z INFO control: terminated āļø
2024-11-20T08:13:45Z INFO updater: terminated āļø
2024-11-20T08:13:45Z INFO tickers: terminated āļøI have a sequence of ~16300 line with:
DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
DEBUG [wireguard] peer(+nv/ā¦5w10) - Sending keepalive packet
DEBUG [wireguard] peer(+nv/ā¦5w10) - Sending keepalive packet
DEBUG [wireguard] peer(+nv/ā¦5w10) - Sending keepalive packet
DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
DEBUG [wireguard] peer(+nv/ā¦5w10) - Receiving keepalive packet
DEBUG [wireguard] peer(+nv/ā¦5w10) - Sending handshake initiationIt 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