• Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Adamm's Achievements


Newbie (1/14)



  1. Its a bug with the latest qbittorrent, revert to "binhex/arch-qbittorrentvpn:4.2.5-1-12"
  2. So I finally found the issue after spending too many hours investigating and pulling my hair out. For reference, the reason the port was being shown as closed is because PIA will only show open when data is flowing through it, so because my port was never being changed in qBittorrent this never applied. Anyway.... the issue turns out to be how you interact with qBittorrents API in, the curl commands you use don't support https nor self signed certs. curl -i -X POST -d "json={\"listen_port\": ${VPN_INCOMING_PORT}}" "http://localhost:${WEBUI_PORT}/api/v2/app/setPreferences" &> /dev/null The above command will first fail if the user has HTTPS enabled as you specifically query http://localhost:(etc), this needs to be changed to dynamically tell if HTTPS is enabled. Secondly the request will fail if the user has a self signed cert; curl: (60) SSL certificate problem: self signed certificate More details here: curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. To fix this you will also need to add the -k flag ( -k, --insecure Allow insecure server connections when using SSL) to allow curl to accept self signed certs. With that being said, I tested the changes locally and everything works smoothly. Hope this helps. Edit; Made a pull request for convenience
  3. Tried 5 different endpoints, still no dice. I put in a ticket to PIA see if they have any idea why the ports aren't being opened, how frustrating.
  4. Right, wasn't aware of that limitation. In any case now the API is returning a port, it never seems to actually get opened. I also confirmed this behavior on my router directly using a separate OpenVPN instance. skynet@RT-AX88U-DC28:/tmp/home/root# curl --interface tun11 skynet@RT-AX88U-DC28:/tmp/home/root# curl -4 --interface tun11 {"port":36870} 2020-02-29 02:56:09,464 DEBG 'start-script' stdout output: [info] Curl successful for, response code 200 2020-02-29 02:56:09,495 DEBG 'start-script' stdout output: [info] Successfully assigned incoming port 47431 2020-02-29 02:56:10,456 DEBG 'start-script' stdout output: [info] Successfully retrieved external IP address Not quite sure what to make of the whole situation as it seems port forwarding on their end is broken?
  5. Seems like the API for assigning ports is failing for me, when I SSH into the container and issue the commands manually; [root@6da3ac31a1e6 root]# client_id=`head -n 100 /dev/urandom | sha256sum | tr -d " -"` [root@6da3ac31a1e6 root]# echo $client_id fcff19a59ef4d909cb7b21de116ffea6258988b53d090c823b4efc36c45076d6 [root@6da3ac31a1e6 root]# curl --interface tun0 curl: (56) Recv failure: Connection reset by peer [root@6da3ac31a1e6 root]# curl --interface tun0 Any idea why this might be happening?
  6. Ah your right, the port is closed. So it looks like the port is never being opened in the first place as the result is the same after restarting the docker image.
  7. So I went through my Sonarr bot logs and noticed this issue occurred exactly a week ago, the same day 4.2.1-1-04 was tagged. I reverted back to 4.2.1-1-03 to experiment and the issue is resolved. Seems to be a problem with that particular build.
  8. Unfortunately not, that was one of my first suspicions when I noticed it misbehaving.
  9. I tried with a different endpoint, same result. After 30 minutes the port was marked as closed and once OpenVPN restarted torrents were unable to establish connections; Here is the full log;
  10. So I've been having an issue the last week or so after successfully using this image (latest branch) on my QNAP TVS-672XT NAS the past year. Every 30 minutes the watchdog is marking the incoming port as closed and restarting OpenVPN etc. To make things worse, once this happens all connections from torrents fail (0 seeders 0 peers) until the docker container is manually restarted. I'm currently using PIA with the Toronto endpoint so everything should be fine there. Below is a snippet of the end of my log; Let me know if you require any other info.