search

binhex / arch-qbittorrentvpn

Docker build script for Arch Linux base with qBittorrent, Privoxy and OpenVPN
GNU General Public License v3.0
443 stars 47 forks source link

Current Latest Image version fails to start #233

Closed Fribb closed 4 months ago

Fribb commented 5 months ago

The current Latest release of the Docker image seems to be broken. I currently get the below message output in the docker logs over and over without being able to access the WebUI of the container.

When I roll back to the binhex/arch-qbittorrentvpn:2024033106 tag, the container starts without issues.

Running on Unraid 6.12.6

Docker Log output below with potential private information redacted.

2024-05-01 05:28:29,774 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 VERIFY ERROR: CRL not loaded
2024-05-01 05:28:29 OpenSSL: error:0A000086:SSL routines::certificate verify failed:
2024-05-01 05:28:29 TLS_ERROR: BIO read tls_read_plaintext error
2024-05-01 05:28:29 TLS Error: TLS object -> incoming plaintext read error
2024-05-01 05:28:29 TLS Error: TLS handshake failed

2024-05-01 05:28:29,775 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 SIGHUP[soft,tls-error] received, process restarting

2024-05-01 05:28:29,775 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 

2024-05-01 05:28:29,775 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 WARNING: file 'credentials.conf' is group or others accessible
2024-05-01 05:28:29 OpenVPN 2.6.10 [git:makepkg/ba0f62fb950c56a0+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Mar 20 2024
2024-05-01 05:28:29 library versions: OpenSSL 3.3.0 9 Apr 2024, LZO 2.10
2024-05-01 05:28:29 DCO version: N/A

2024-05-01 05:28:30,776 DEBG 'start-script' stdout output:
2024-05-01 05:28:30 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-05-01 05:28:30,776 DEBG 'start-script' stdout output:
2024-05-01 05:28:30 OpenSSL: error:068000E9:asn1 encoding routines::utctime is too short:
2024-05-01 05:28:30 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revocationDate, Type=X509_REVOKED
2024-05-01 05:28:30 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revoked, Type=X509_CRL_INFO
2024-05-01 05:28:30 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=crl, Type=X509_CRL
2024-05-01 05:28:30 OpenSSL: error:0488000D:PEM routines::ASN1 lib:
2024-05-01 05:28:30 CRL: cannot read CRL from file [[INLINE]]
2024-05-01 05:28:30 CRL: loaded 0 CRLs from file -----BEGIN X509 CRL-----
redacted
-----END X509 CRL-----

2024-05-01 05:28:30 TCP/UDP: Preserving recently used remote address: [AF_INET]redacted
2024-05-01 05:28:30 UDPv4 link local: (not bound)
2024-05-01 05:28:30 UDPv4 link remote: [AF_INET]redacted
cybrdyne commented 5 months ago

Same issue on my end.

gabort-snow commented 5 months ago

This appears to be related to the EDNS Client Subnet posted on the Readme.

Due to Google and OpenDNS supporting EDNS Client Subnet it is recommended NOT to use either of these NS providers. The list of default NS providers in the above example(s) is as follows:-

84.200.x.x = DNS Watch 37.235.x.x = FreeDNS 1.x.x.x = Cloudflare

Try removing the Google and OpenDNS Name Servers and see if you can start the container.

Fribb commented 5 months ago

Correct me if I am wrong but I don't think that this applies here, at least not with my configuration.

I have the following NAME_SERVERS env variable defined (which is the same as the Docker compose in the readme

84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1

According to the part you quoted this would mean that:

So, this should be OK, right? Because no OpenDNS or Google Name Servers are being listed/used.

Still, with that, the Containers fail to work properly.

HazMatt69 commented 5 months ago

The current Latest release of the Docker image seems to be broken. I currently get the below message output in the docker logs over and over without being able to access the WebUI of the container.

When I roll back to the binhex/arch-qbittorrentvpn:2024033106 tag, the container starts without issues.

Running on Unraid 6.12.6

Docker Log output below with potential private information redacted.

2024-05-01 05:28:29,774 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 VERIFY ERROR: CRL not loaded
2024-05-01 05:28:29 OpenSSL: error:0A000086:SSL routines::certificate verify failed:
2024-05-01 05:28:29 TLS_ERROR: BIO read tls_read_plaintext error
2024-05-01 05:28:29 TLS Error: TLS object -> incoming plaintext read error
2024-05-01 05:28:29 TLS Error: TLS handshake failed

2024-05-01 05:28:29,775 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 SIGHUP[soft,tls-error] received, process restarting

2024-05-01 05:28:29,775 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 

2024-05-01 05:28:29,775 DEBG 'start-script' stdout output:
2024-05-01 05:28:29 WARNING: file 'credentials.conf' is group or others accessible
2024-05-01 05:28:29 OpenVPN 2.6.10 [git:makepkg/ba0f62fb950c56a0+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Mar 20 2024
2024-05-01 05:28:29 library versions: OpenSSL 3.3.0 9 Apr 2024, LZO 2.10
2024-05-01 05:28:29 DCO version: N/A

2024-05-01 05:28:30,776 DEBG 'start-script' stdout output:
2024-05-01 05:28:30 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-05-01 05:28:30,776 DEBG 'start-script' stdout output:
2024-05-01 05:28:30 OpenSSL: error:068000E9:asn1 encoding routines::utctime is too short:
2024-05-01 05:28:30 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revocationDate, Type=X509_REVOKED
2024-05-01 05:28:30 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revoked, Type=X509_CRL_INFO
2024-05-01 05:28:30 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=crl, Type=X509_CRL
2024-05-01 05:28:30 OpenSSL: error:0488000D:PEM routines::ASN1 lib:
2024-05-01 05:28:30 CRL: cannot read CRL from file [[INLINE]]
2024-05-01 05:28:30 CRL: loaded 0 CRLs from file -----BEGIN X509 CRL-----
redacted
-----END X509 CRL-----

2024-05-01 05:28:30 TCP/UDP: Preserving recently used remote address: [AF_INET]redacted
2024-05-01 05:28:30 UDPv4 link local: (not bound)
2024-05-01 05:28:30 UDPv4 link remote: [AF_INET]redacted

Same issue on Debian 12

danielb7390 commented 5 months ago

Having same issue. This is probably related: https://github.com/openssl/openssl/discussions/24301

binhex commented 5 months ago

I would agree with @danielb7390 that does look like the issue, interestingly though i am using PIA and i switched to openvpn to see the issue for myself and it does not occur for me!, so possibly the CRL i have inline in my ovpn file is not malformed, you can as a temporary fix try my attached ovpn file (unzip and place in /config/openvpn/ and rename the extension for any other ovpn files) pia-ng.zip

The real fix though as detailed in the link above is to get PIA to fix up their ovpn config files so the CRL is no longer malformed, please raise a ticket with PIA if you want to get it fixed (outside my control).

EDIT - linked ovpn file does NOT fix the issue.

danielb7390 commented 5 months ago

🤔 the inlined crl and cert are exactly the same in mine, yours, and the fresh downloaded ones from PIA... Only difference in the opvn file is the cipher aes-128-cbc vs aes-256-gcm and auth sha1 in mine/fresh vs yours that doesn't have it. Made both of this changes just to rule it out. Same result.

HazMatt69 commented 5 months ago

Yup!, also tried that and it still fails: "2024-05-01 11:26:14,690 DEBG 'start-script' stdout output: 2024-05-01 11:26:14 OpenSSL: error:068000E9:asn1 encoding routines::utctime is too short: 2024-05-01 11:26:14 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revocationDate, Type=X509_REVOKED 2024-05-01 11:26:14 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revoked, Type=X509_CRL_INFO 2024-05-01 11:26:14 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=crl, Type=X509_CRL 2024-05-01 11:26:14 OpenSSL: error:0488000D:PEM routines::ASN1 lib: 2024-05-01 11:26:14 CRL: cannot read CRL from file [[INLINE]] 2024-05-01 11:26:14 CRL: loaded 0 CRLs from file -----BEGIN X509 CRL----- MIICWDCCAUAwDQYJKoZIhvcNAQENBQAwgegxCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJDQTETMBEGA1UEBxMKTG9zQW5nZWxlczEgMB4GA1UEChMXUHJpdmF0ZSBJbnRl cm5ldCBBY2Nlc3MxIDAeBgNVBAsTF1ByaXZhdGUgSW50ZXJuZXQgQWNjZXNzMSAw HgYDVQQDExdQcml2YXRlIEludGVybmV0IEFjY2VzczEgMB4GA1UEKRMXUHJpdmF0 ZSBJbnRlcm5ldCBBY2Nlc3MxLzAtBgkqhkiG9w0BCQEWIHNlY3VyZUBwcml2YXRl aW50ZXJuZXRhY2Nlc3MuY29tFw0xNjA3MDgxOTAwNDZaFw0zNjA3MDMxOTAwNDZa MCYwEQIBARcMMTYwNzA4MTkwMDQ2MBECAQYXDDE2MDcwODE5MDA0NjANBgkqhkiG 9w0BAQ0FAAOCAQEAQZo9X97ci8EcPYu/uK2HB152OZbeZCINmYyluLDOdcSvg6B5 jI+ffKN3laDvczsG6CxmY3jNyc79XVpEYUnq4rT3FfveW1+Ralf+Vf38HdpwB8EW B4hZlQ205+21CALLvZvR8HcPxC9KEnev1mU46wkTiov0EKc+EdRxkj5yMgv0V2Re ze7AP+NQ9ykvDScH4eYCsmufNpIjBLhpLE2cuZZXBLcPhuRzVoU3l7A9lvzG9mjA 5YijHJGHNjlWFqyrn1CfYS6koa4TGEPngBoAziWRbDGdhEgJABHrpoaFYaL61zqy MR6jC0K2ps9qyZAN74LEBedEfK7tBOzWMwr58A== -----END X509 CRL-----"

binhex commented 5 months ago

Ahh damn it!, i had a cached image, force pulled and i now see the issue, OK so at this point right now the options to get a working system are:-

  1. switch to wireguard (no CRL)
  2. revert back to tagged image 2024033106 (see Q5 if you do not know how to do this)
  3. Edit the OpenVPN config file and remove CRL section and switch off compression - see https://old.reddit.com/r/synology/comments/jwbtld/1819_trouble_connecting_to_pia/

I would encourage you all though to raise an issue with PIA in regards to this, otherwise it will not get fixed, link to the issue posted here in your support ticket to PIA https://github.com/binhex/arch-qbittorrentvpn/issues/233#issuecomment-2088169448

EDIT - I have raised a support ticket, but feel free to create a ticket too, the more people that complain about this the higher the priority and hopefully the faster it gets fixed!.

EDIT2 - I see a workaround has been posted on https://github.com/openssl/openssl/discussions/24301 and I have confirmed it works (see 3. above), it MAY have security implications though so proceed with caution.

danielb7390 commented 5 months ago

Well, this was a nice excuse to finally switch to wireguard 😅 Anyways, i also submitted a support ticket, will see if i can get through to the technical department.

HazMatt69 commented 5 months ago

Well, this was a nice excuse to finally switch to wireguard 😅 Anyways, i also submitted a support ticket, will see if i can get through to the technical department.

Exactly what I also did, works like a charm (also submitted a ticket at PIA for the sake of it)!

RonnieBlaze commented 5 months ago

Well, this was a nice excuse to finally switch to wireguard 😅 Anyways, i also submitted a support ticket, will see if i can get through to the technical department.

Exactly what I also did, works like a charm (also submitted a ticket at PIA for the sake of it)!

How did you change it to wireguard?

danielb7390 commented 5 months ago

Well, this was a nice excuse to finally switch to wireguard 😅 Anyways, i also submitted a support ticket, will see if i can get through to the technical department.

Exactly what I also did, works like a charm (also submitted a ticket at PIA for the sake of it)!

How did you change it to wireguard?

You can see how to enable wireguard in the readme of this repo.

gabort-snow commented 5 months ago

Yeah, I initially had the same issue and removed the DNS entries and updated to WireGuard. Guess I had assumed it was the dns removal that fixed it. Incorrect thought on my part. But working now with the WireGuard setup.

binhex commented 5 months ago

@jrupert37 please don't post on the unraid forum and here, one or the other, a member on the forum has already posted the solution to your issue.

jrupert37 commented 5 months ago

@jrupert37 please don't post on the unraid forum and here, one or the other, a member on the forum has already posted the solution to your issue.

My sincerest apologies, didn't see the response in the unraid forum. Thank you.

RonnieBlaze commented 5 months ago

I changed to wireguard and changed the location, and now when starting my unraid docker it says this

[warn] Unable to successfully download PIA json to generate token from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

binhex commented 5 months ago

What location?

RonnieBlaze commented 5 months ago

What location?

spain.privacy.network

binhex commented 5 months ago

What location?

spain.privacy.network

ive just tested using this location with wireguard on latest image and it connected first time, so i can only assume either you are blocking 'https://www.privateinternetaccess.com/gtoken/generateToken' or it was an intermittent connectivity issue on PIA's end, maybe give it a retry.

RonnieBlaze commented 5 months ago

What location?

spain.privacy.network

ive just tested using this location with wireguard on latest image and it connected first time, so i can only assume either you are blocking 'https://www.privateinternetaccess.com/gtoken/generateToken' or it was an intermittent connectivity issue on PIA's end, maybe give it a retry.

it working now. so it must just have been a issue on PIA's side when I was trying to connect.

Fribb commented 4 months ago

I tried switching to Wireguard but then I cannot access the WebUI at all. I switch the VPN_CLIENT to wireguard and have the sysctl set in the extra parameters and the container is running in privileged mode. When I start the container, the VPN works but the WebUI is running in a timeout

This is the log output which would indicate everything is running correctly...

2024-05-02 09:25:37,464 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '23021'

2024-05-02 09:25:37,645 DEBG 'watchdog-script' stdout output:
[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP redacted different, marking for reconfigure

2024-05-02 09:25:37,657 DEBG 'watchdog-script' stdout output:
[info] qBittorrent not running

2024-05-02 09:25:37,661 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2024-05-02 09:25:37,661 DEBG 'watchdog-script' stdout output:
[info] qBittorrent incoming port 6881 and VPN incoming port 23021 different, marking for reconfigure

2024-05-02 09:25:37,662 DEBG 'watchdog-script' stdout output:
[info] qBittorrent config file already exists, skipping copy
[info] Removing session lock file (if it exists)...

2024-05-02 09:25:37,691 DEBG 'watchdog-script' stdout output:
[info] Attempting to start qBittorrent...

2024-05-02 09:25:37,696 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started
[info] Waiting for qBittorrent process to start listening on port 8080...

2024-05-02 09:25:37,807 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8080

2024-05-02 09:25:37,837 DEBG 'watchdog-script' stdout output:
[info] Attempting to start Privoxy...

2024-05-02 09:25:38,844 DEBG 'watchdog-script' stdout output:
[info] Privoxy process started
[info] Waiting for Privoxy process to start listening on port 8118...

2024-05-02 09:25:38,849 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

from this, it looks like qbittorrent is expecting to be accessible through 8080, my port exposure is 172.17.0.31:8080/TCP <-> 192.168.178.3:8085. When switching back to OpenVPN, same configuration, after some wait time the WebUI is accessible again. Even Waiting for a long time with the wireguard configuration, it just doesn't want to load the WebUI

pbiswal commented 4 months ago

Hey folks,

I am having issue after enabling wireguard. 

2024-05-02 14:17:22,694 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...

2024-05-02 14:17:22,704 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2024-05-02 14:17:22,710 DEBG 'start-script' stderr output:
[#] ip link add wg0 type wireguard

2024-05-02 14:17:22,712 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63

2024-05-02 14:17:22,715 DEBG 'start-script' stderr output:
[#] ip -4 address add 10.1.X.X dev wg0

2024-05-02 14:17:22,721 DEBG 'start-script' stderr output:
[#] ip link set mtu 1420 up dev wg0

2024-05-02 14:17:22,729 DEBG 'start-script' stderr output:
[#] wg set wg0 fwmark 51820

2024-05-02 14:17:22,729 DEBG 'start-script' stderr output:
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820

2024-05-02 14:17:22,731 DEBG 'start-script' stderr output:
[#] ip -4 rule add not fwmark 51820 table 51820

2024-05-02 14:17:22,732 DEBG 'start-script' stderr output:
[#] ip -4 rule add table main suppress_prefixlength 0

2024-05-02 14:17:22,736 DEBG 'start-script' stderr output:
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1

2024-05-02 14:17:22,737 DEBG 'start-script' stderr output:
[#] iptables-restore -n

2024-05-02 14:17:22,740 DEBG 'start-script' stderr output:
iptables-restore v1.8.10 (legacy): iptables-restore: unable to initialize table 'raw'
Error occurred at line: 1
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

2024-05-02 14:17:22,744 DEBG 'start-script' stderr output:
[#] ip -4 rule delete table 51820

2024-05-02 14:17:22,749 DEBG 'start-script' stderr output:
[#] ip -4 rule delete table main suppress_prefixlength 0

2024-05-02 14:17:22,756 DEBG 'start-script' stderr output:
[#] ip link delete dev wg0

2024-05-02 14:17:22,786 DEBG 'start-script' stdout output:
[warn] WireGuard interface failed to come 'up', exit code is '1'

After changing wg0.conf that is generated from AllowedIPs = 0.0.0.0/0 to AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 it proceeds further but then the container is not able to access google.com

2024-05-02 11:47:46,371 DEBG 'start-script' stderr output:
/root/wireguard.sh: line 96: /config/wireguard/wg0.conf: Read-only file system

2024-05-02 11:47:46,372 DEBG 'start-script' stdout output:
[info] Attempting to bring WireGuard interface 'up'...

2024-05-02 11:47:46,381 DEBG 'start-script' stderr output:
Warning: `/config/wireguard/wg0.conf' is world accessible

2024-05-02 11:47:46,387 DEBG 'start-script' stderr output:
[#] ip link add wg0 type wireguard

2024-05-02 11:47:46,390 DEBG 'start-script' stderr output:
[#] wg setconf wg0 /dev/fd/63

2024-05-02 11:47:46,392 DEBG 'start-script' stderr output:
[#] ip -4 address add 10.55.X.X dev wg0

2024-05-02 11:47:46,398 DEBG 'start-script' stderr output:
[#] ip link set mtu 1420 up dev wg0

2024-05-02 11:47:46,404 DEBG 'start-script' stderr output:
[#] ip -4 route add 0.0.0.0/1 dev wg0

2024-05-02 11:47:46,406 DEBG 'start-script' stderr output:
[#] '/root/wireguardup.sh'

2024-05-02 11:47:46,441 DEBG 'start-script' stdout output:
[debug] Waiting for valid VPN gateway IP addresses from tunnel...
[debug] Waiting for valid VPN adapter IP addresses from tunnel...

2024-05-02 11:47:47,450 DEBG 'start-script' stdout output:
[debug] Valid local IP address from tunnel acquired '10.55.X.X'

2024-05-02 11:47:47,450 DEBG 'start-script' stdout output:
[debug] Valid gateway IP address from tunnel acquired '10.68.X.X'

2024-05-02 11:47:47,512 DEBG 'start-script' stdout output:
[debug] Checking we can resolve name 'www.google.com' to address...

The container is running on a Synology NAS where I have firewall in place. Not sure if it has anything to do with it. I had everything working couple of days back set to openvpn. So a bit lost on what to do. I know I can switch back to openvpn as mentioned above, but would like to make this future proof to not have to go to this problem later.

Any help would be super appreciated.

Thanks.

sameep22 commented 4 months ago

Thanks for this thread. I had a similar issue with my setup after the latest upgrade. PIA user. Resolved with a change to wireguard.

Baltimorepc commented 4 months ago

having the same issue now since the update 2 days ago

danielb7390 commented 4 months ago

Just an update, PIA support already replied, they seem aware of the problem and someone is looking into it:

Similar reports regarding this matter are coming in, but we're not sure if this is an issue that affects a larger number of customers or just a select few. However, the relevant team has been notified of the situation. While waiting for a solution, we recommend you to a lower OpenSSL version.

binhex commented 4 months ago

Hi guys, i don't want to be snowed under with support due to this issue so i have taken the executive decision of downgrading openssl to 3.2.0 (ignores the issue), this will get openvpn up and running again whilst we await to see if PIA will actually do anything to address the problem.

Please pull latest image at your convenience and switch back to openvpn.

Fribb commented 4 months ago

Hi guys, i don't want to be snowed under with support due to this issue so i have taken the executive decision of downgrading openssl to 3.2.0 (ignores the issue), this will get openvpn up and running again whilst we await to see if PIA will actually do anything to address the problem.

Please pull latest image at your convenience and switch back to openvpn.

Thank you for that, I just force-update the Container with the latest image and it works as expected. I am going to close this.

binhex commented 3 months ago

Just an update on this before i lock this issue, i have since decided to code in removal of CRL from the OpenVPN configuration files, as rolling back to a previous version of OpenSSL got hard due to the rolling nature of Arch Linux (base distro).