Bug: Control Server is broken for Wireguard (works only for OpenVPN)

Aubermean commented 3 months ago

Is this urgent?

Yes

Host OS

No response

CPU arch

aarch64

VPN service provider

Custom

What are you using to run the container

docker-compose

What is the version of Gluetun

2024-03-07T12:32:25.391Z (commit 3254fc8)

What's the problem 🤔

Using the Control Server, trying to 'start' a wireguard server results in some bug whereby it switches over to openvpn and the container needs restarting.

This version works: 2024-03-07T12:32:25.391Z (commit 3254fc8)

the latest, v3.39, v3.38, v3.37 tags do not work.

I don't use OpenVPN, I never have. The commit tag above works fine, this log I am adding is from the latest versions so you can see it decides to switch to openvpn after i stop-start via control server.

Share your logs (at least 10 lines)

gluetun_a-1  | 2024-08-24T20:22:38Z INFO [wireguard] Using available kernelspace implementation
gluetun_a-1  | 2024-08-24T20:22:38Z INFO [wireguard] Connecting to ....
gluetun_a-1  | 2024-08-24T20:22:38Z 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 Wireguard connection is not working.
gluetun_a-1  | 2024-08-24T20:22:38Z INFO [dns] downloading DNS over TLS cryptographic files
gluetun_a-1  | 2024-08-24T20:22:39Z INFO [healthcheck] healthy!
gluetun_a-1  | 2024-08-24T20:22:40Z INFO [dns] downloading hostnames and IP block lists
gluetun_a-1  | 2024-08-24T20:22:45Z INFO [dns] init module 0: validator
gluetun_a-1  | 2024-08-24T20:22:45Z INFO [dns] init module 1: iterator
gluetun_a-1  | 2024-08-24T20:22:45Z INFO [dns] start of service (unbound 1.20.0).
gluetun_a-1  | 2024-08-24T20:22:45Z INFO [dns] generate keytag query ....
gluetun_a-1  | 2024-08-24T20:22:45Z INFO [dns] ready
gluetun_a-1  | 2024-08-24T20:22:46Z INFO [ip getter] Public IP address is ....
gluetun_a-1  | 2024-08-24T20:22:46Z INFO [vpn] There is a new release v3.39.0 (v3.39.0) created 15 days ago
gluetun_a-1  | 2024-08-24T20:22:48Z INFO [http server] 200 GET /ip wrote 210B to 172.16.238.1:54854 in 182.84µs
gluetun_a-1  | 2024-08-24T20:22:53Z INFO [vpn] stopping
gluetun_a-1  | 2024-08-24T20:22:53Z INFO [vpn] starting
gluetun_a-1  | 2024-08-24T20:22:53Z INFO [firewall] allowing VPN connection...
gluetun_a-1  | 2024-08-24T20:22:53Z ERROR [openvpn] No client-side authentication method is specified.  You must use either --cert/--key, --pkcs12, or --auth-user-pass
gluetun_a-1  | 2024-08-24T20:22:53Z INFO [openvpn] Use --help for more information.
gluetun_a-1  | 2024-08-24T20:22:53Z ERROR [vpn] exit status 1
gluetun_a-1  | 2024-08-24T20:22:53Z INFO [vpn] retrying in 15s

Share your configuration

no

github-actions[bot] commented 3 months ago

@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
:+1: 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

qdm12 commented 3 months ago

Which route are you using to (re)start wireguard through the control server? Also can you share some logs, for example in the latest image to see how it misbehaves? Thanks!

Aubermean commented 3 months ago

Hi Quentin, latest behaves the same as log above, but attaching full log using latest for your reference. v1 is generally quite an (ahem) 'anti-pattern' API, but also very useful! v2 one day would be great. <3

> curl -X PUT http://localhost:8005/v1/openvpn/status -H "Content-Type: application/json" -d '{"status": "stopped"}'
{"outcome":"stopped"}
> curl -X PUT http://localhost:8005/v1/openvpn/status -H "Content-Type: application/json" -d '{"status": "running"}'
{"outcome":"crashed"}

gluetun_log.txt

qdm12 commented 3 months ago

The documentation was a bit wrong, this is fixed in https://github.com/qdm12/gluetun-wiki/commit/4a0075784796908ad13f316225643ee8bd06dc0e

There are routes defined in the code but not documented, because they are subject to change without notice (notably #2238):

/v1/vpn/status (GET and PUT) which works for both wireguard and openvpn
/v1/vpn/settings (GET and PUT) which works for both wireguard and openvpn

These are likely to stay, but default no-access-without-user-defined-authentication might be set on them soon, and the settings JSON object might change in the future, as long as these routes are not documented still. Once it's documented it will stay retro-compatible.

Aubermean commented 3 months ago

Hi, so the endpoint was renamed from /v1/openvpn to /v1/vpn?

Since you made the wise choice of starting off with api versioning, if you change the API it would really make sense to use v2 and leave the old endpoints so things don't break. Otherwise I have to integrate testing on my side to make sure new releases don't break the API client library I have written.

Also #2238 doesn't make sense I think there is a typo?

github-actions[bot] commented 3 months 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.

joejose97 commented 2 months ago

In spirit of easier maintainability, asking for backwards compatibility for undocumented api is a bit much don't you think? @Aubermean I think you should have a test suite on your end to make sure your needs are served well.

Aubermean commented 2 months ago

In spirit of easier maintainability, asking for backwards compatibility for undocumented api is a bit much don't you think? @Aubermean I think you should have a test suite on your end to make sure your needs are served well.

You are mistaken, the API has never been undocumented. The API /v1/ had its endpoints changed completely and silently and the documentation was not updated.

Speaking of easier maintainabilitiy, the solution is definitely not everyone having 'a test suite on their end'. The solution is:

Making use of the API versioning that is already implemented
Updating the documentation should the API change
Avoiding anti-patterns to follow good design principles with all iterative changes

qdm12 / gluetun