Bug: OpenVPN no client-side authentication method is specified.
ezekieldas opened this issue · comments
Is this urgent?
Yes
Host OS
Ubuntu 22.04.4
CPU arch
x86_64
VPN service provider
Mullvad
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2024-04-08T07:43:05.096Z (commit 7b4befc)
What's the problem 🤔
I'm near certain this is a new bug. I have no openvpn configuration. I can't spot it exactly (go weakling here) but there are references to openvpn here: 7b4befc
qmcgaw/gluetun:latest (note digest match):
docker image inspect `docker images -q qmcgaw/gluetun:latest` | jq '.[].RepoDigests[]'
"qmcgaw/gluetun@sha256:b0d2bc4af64934b68a8479bf66f5dba12143ede03beeb17740f634728ee3ce80"
I just turned on LOG_LEVEL=debug
to get more details. Will update when available.
Also, will determine if there's a tag to use to avoid this. Could be qmcgaw/gluetun:v3
Share your logs (at least 10 lines)
2024-04-08T21:07:02Z INFO [http server] 200 GET /ip wrote 17B to 10.10.10.1:55170 in 50.643µs
2024-04-08T21:07:03Z INFO [firewall] allowing VPN connection...
2024-04-08T21:07:03Z ERROR [openvpn] No client-side authentication method is specified. You must use either --cert/--key, --pkcs12, or --auth-user-pass
2024-04-08T21:07:03Z INFO [openvpn] Use --help for more information.
2024-04-08T21:07:03Z ERROR [vpn] exit status 1
2024-04-08T21:07:03Z INFO [vpn] retrying in 30s
2024-04-08T21:07:03Z INFO [http server] 200 GET /ip wrote 17B to 10.10.10.1:55180 in 36.99µs
2024-04-08T21:07:04Z INFO [http server] 200 GET /ip wrote 17B to 10.10.10.1:55184 in 37.82µs
2024-04-08T21:07:05Z INFO [http server] 200 GET /ip wrote 17B to 10.10.10.1:55198 in 55.216µs
2024-04-08T21:07:09Z INFO [healthcheck] program has been unhealthy for 10s: restarting VPN
2024-04-08T21:07:09Z INFO [healthcheck] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2024-04-08T21:07:09Z INFO [healthcheck] DO NOT OPEN AN ISSUE UNLESS YOU READ AND TRIED EACH POSSIBLE SOLUTION
2024-04-08T21:07:28Z INFO [healthcheck] program has been unhealthy for 17s: restarting VPN
2024-04-08T21:07:28Z INFO [healthcheck] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2024-04-08T21:07:28Z INFO [healthcheck] DO NOT OPEN AN ISSUE UNLESS YOU READ AND TRIED EACH POSSIBLE SOLUTION
2024-04-08T21:07:33Z INFO [firewall] allowing VPN connection...
2024-04-08T21:07:33Z ERROR [openvpn] No client-side authentication method is specified. You must use either --cert/--key, --pkcs12, or --auth-user-pass
2024-04-08T21:07:33Z INFO [openvpn] Use --help for more information.
2024-04-08T21:07:33Z ERROR [vpn] exit status 1
2024-04-08T21:07:33Z INFO [vpn] retrying in 1m0s
Share your configuration
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
restart: always
dns:
- 127.0.0.1
networks:
- gluetun_net
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- 8000:8000/tcp # control server - https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md
- 8008:8888/tcp # HTTP proxy - https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/http-proxy.md
- 6666:9999/tcp # healthcheck - https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md#internal-healthcheck
- 8053:53/tcp # blocky
- 8053:53/udp # blocky
- 9110:4000/tcp # blocky prometheus exporter
volumes:
- /usr/local/docker/gluetun/gluetun_config:/gluetun
- /usr/local/docker/gluetun/gluetun_config/post-rules.txt:/iptables/post-rules.txt
sysctls:
- net.ipv6.conf.all.disable_ipv6=1
environment:
- LOG_LEVEL=debug
- TZ=Etc/UTC
#
# https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/firewall.md
#
- FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24
# - FIREWALL_DEBUG=on
#
# https://github.com/qdm12/gluetun/issues/2047
#
### - PUBLICIP_API=ip2location
#
# healthcheck - https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/healthcheck.md
#
- HEALTH_TARGET_ADDRESS=1.1.1.1:443
- HEALTH_VPN_DURATION_INITIAL=10s
- HEALTH_VPN_DURATION_ADDITION=7s
- HEALTH_SUCCESS_WAIT_DURATION=7s
- HEALTH_SERVER_ADDRESS=0.0.0.0:9999
#
# providers - https://github.com/qdm12/gluetun-wiki/tree/main/setup/providers
#
- VPN_TYPE=wireguard
- VPN_SERVICE_PROVIDER=${VPN_SERVICE_PROVIDER}
- SERVER_COUNTRIES=${SERVER_COUNTRIES}
- WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
- WIREGUARD_ADDRESSES=${WIREGUARD_ADDRESSES}
- VPN_ENDPOINT_PORT=${VPN_ENDPOINT_PORT}
#
# server list update - https://github.com/qdm12/gluetun-wiki/blob/main/setup/servers.md#update-the-vpn-servers-list
#
- UPDATER_PERIOD=3h
#
# http proxy - https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/http-proxy.md
#
- HTTPPROXY=on
- HTTPPROXY_STEALTH=on
#
# DNS
# https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/dns.md
#
- DOT=off
- DNS_KEEP_NAMESERVER=on
blocky:
image: spx01/blocky
container_name: blocky
restart: always
network_mode: "service:gluetun"
volumes:
# Optional to synchronize the log timestamp with host
- /etc/localtime:/etc/localtime:ro
# config file
- ./blocky_config/config.yml:/app/config.yml
- ./blocky_config/local.blocks.txt:/app/local.blocks.txt
- ./blocky_config/local.allow.txt:/app/local.allow.txt
networks:
gluetun_net:
name: gluetun_net
ipam:
config:
- subnet: 10.10.10.0/24
@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:
- do not ask for updates, be patient
- 👍 the issue to show your support instead of commenting
@qdm12 usually checks issues at least once a week, if this is a new urgent bug,
revert to an older tagged container image
I have multiple Gluetun instances running in my environment. I've left one running with the image noted above and it just barfed. Full log is attached. Other instances are using qmcgaw/gluetun:v3
and doing fine.
Here's a snippet with debug on:
2024-04-09T00:41:56Z INFO [http server] 200 GET /ip wrote 270B to 10.10.10.1:60436 in 44.788µs
2024-04-09T00:43:11Z INFO [vpn] stopping
2024-04-09T00:43:11Z DEBUG [wireguard] closing controller client...
2024-04-09T00:43:11Z DEBUG [wireguard] removing IPv4 rule...
2024-04-09T00:43:11Z DEBUG [wireguard] shutting down link...
2024-04-09T00:43:11Z DEBUG [wireguard] deleting link...
2024-04-09T00:43:11Z INFO [http server] 200 PUT /status wrote 22B to 10.10.10.1:39312 in 132.8803ms
2024-04-09T00:43:11Z INFO [vpn] starting
2024-04-09T00:43:11Z INFO [firewall] allowing VPN connection...
2024-04-09T00:43:11Z DEBUG [firewall] iptables --delete OUTPUT -d 198.54.131.130 -o eth0 -p udp -m udp --dport 2049 -j ACCEPT
2024-04-09T00:43:11Z DEBUG [firewall] iptables --delete OUTPUT -o tun0 -j ACCEPT
2024-04-09T00:43:11Z DEBUG [firewall] ip6tables-nft --delete OUTPUT -o tun0 -j ACCEPT
2024-04-09T00:43:11Z DEBUG [firewall] iptables --append OUTPUT -d 45.134.140.143 -o eth0 -p udp -m udp --dport 2049 -j ACCEPT
2024-04-09T00:43:11Z DEBUG [firewall] iptables --append OUTPUT -o tun0 -j ACCEPT
2024-04-09T00:43:11Z DEBUG [firewall] ip6tables-nft --append OUTPUT -o tun0 -j ACCEPT
2024-04-09T00:43:11Z ERROR [openvpn] No client-side authentication method is specified. You must use either --cert/--key, --pkcs12, or --auth-user-pass
2024-04-09T00:43:11Z INFO [openvpn] Use --help for more information.
2024-04-09T00:43:11Z ERROR [vpn] exit status 1
2024-04-09T00:43:11Z INFO [vpn] retrying in 15s
You'll see alot of:
2024-04-08T22:12:18Z ERROR [http proxy] 10.10.10.1:45312 http://la.speedtest.clouvider.net/backend/garbage.php?ckSize=100: body copy error: write tcp 10.10.10.2:8888->10.10.10.1:45312: write: broken pipe
in this log. I'm used to this and it comes up regularly in normal, non-disrupted operation. I run automated speed tests every so often.
10.144.666.666/32
is fuzzing. I'd be happy to provide more details/test.
The problem is really just an OpenVPN problem:
No client-side authentication method is specified. You must use either --cert/--key, --pkcs12, or --auth-user-pass
I just ran Mullvad+Openvpn successfully with the latest image, are you sure it's not a configuration error? The configuration you shared indicates VPN_TYPE=wireguard
but the logs indicate it's running OpenVPN, so there is already a mismatch there 🤔
I'm unsure how to match up current tags with commit 7b4befc.
I've had v3 running since the time I mentioned this. I just tested with latest, gluetun:test, gluetun:v3.38, v3.37 and was unable to reproduce.
What I recall from the event on Apr 8 inspiring this report is a restart of multiple containers with the exact configuration shown above. All containers then failed with the logs included earlier. Confidence is very high this wasn't a configuration issue.
Since this can't be reproduced at this time, I'd be fine with closing the issue. However, I'd really like to know if there's a practical means of following a commit id (ie, 7b4befc) to a digest reference, specific image tag, or whatever was 'latest' at that time. This has been an ongoing knowledge gap of mine that I'd like to address.
If you could show me how to do that I'd be happy to test against that image. If no reproducer, then I'll close in spite of the mysterious nature.
It was likely due to a large settings refactoring I've done starting with ecc80a5 about a month ago. It should be all fixed up now given there is no directly related issue report about it for now. If it's working now, let's just move on and close this, since that was on the latest image and it's now fixed (this would different if it would be a tagged "more-stable" image such as :v3.38
).
I'm unsure how to match up current tags with commit 7b4befc.
This has been an ongoing knowledge gap of mine that I'd like to address.
The git commit is injected as a docker build argument from the automated build system and is set in the Gluetun Go program at compilation time (here), and is also set as a the org.opencontainers.image.revision
Docker image label (here).
Now you can filter your local Docker images with
docker images --filter "label=org.opencontainers.image.revision=7b4befce61a56d945c3558188d79a856ba22880a"
Note the revision has to be the full git commit hash digest, not just the first 7 characters.
Although I have no idea how to find that image on Gchr or docker hub once it's deleted locally, I would even say it's likely impossible at this time. But it's still re-buildable too! For example:
docker build -t qmcgaw/gluetun https://github.com/qdm12/gluetun.git#7b4befce61a56d945c3558188d79a856ba22880a
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.