[Support] binhex - DelugeVPN

8536 posts in this topic Last Reply

Recommended Posts

9 minutes ago, Malaki said:

I'm running 2.0.4.dev38_g23a48dd01-2-15. I'm using latest for the repo.

You could try the recommended NS's and see what happens-,,,,,,,


Edited by wgstarks
Link to post
  • Replies 8.5k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

There has been an issue raised on GitHub related to tracker announce request IP leakage under certain circumstances, after careful review of iptables i have tightened up the rules to prevent this. A n

OK guys, multi remote endpoint support is now in for this image please pull down the new image (this change will be rolled out to all my vpn images shortly).   What this means is that the im

ok thats fine, so you are using privoxy in this case and NOT network binding multiple containers.   so good news, at long last i am able to replicate one of the issues here, so if i set sona

Posted Images

21 minutes ago, wgstarks said:

Binhex-qbittorrentvpn has worked great for me. The switch was fairly painless if you want to go that route. You will need to re-add all your torrents so you need to be sure you have the torrent files (and maybe backup copies 🤞).


Edit: you’re welcome to pm me if you need details.

thank you for this.  i may need to go that route.  i dread the thought of having to recheck my 2100+ torrents all living in different folders with various labels.  but if thats what i gotta do.... ;)

Link to post
1 hour ago, DontWorryScro said:

ok can anyone chime in on a specific 2.0.4 build that plays nice with the most amount of private trackers without getting you banned/blocked/timedout?

Give me your favorite tag!  TIA


Edit: tho i guess the real issue is they're all dev versions.  No stable version.  So I'm up a creek.

Most trackers I'm on have a banned list that you cannot use, and an approved list that is supported/preferred, leaving a grey area for certain clients and/or versions of those clients.

I would do some research on your tracker's forums etc to see if there is a grey area that allows use of these version of deluge.


Link to post
31 minutes ago, wgstarks said:

Nevermind. I see that's what you already have set.

I did double-check those. I tried the binhex/qbittorrent container just for fun. I set it up using the same info - VPN settings, name servers, etc. - it connected right up. Switching back to deluge, I got an auth failed message so I double-checked the password. It's now back to the same error...

warn] Response code 000 from curl != 2xx
[warn] Exit code 7 from curl != 0


I'm assuming that binhex is using the same openvpn client on both so I'll keep working with the deluge container. I'm sure it's a user error somewhere, I might just just from scratch with it. At least qbittorent works, so that might become my go-to system.


Thanks wgstarks, it was one of your other comments about qbittorrent that prompted me to try that.

Link to post
9 hours ago, helpermonkey said:

they are also in my container settings.... i just double checked and had no problem signing into the PIA website from my browser and all of my other clients are logging in without a problem.

I had the same issue with Toronto. Switched to Vancouver. It’s working fine now for me.

Link to post
6 hours ago, PacificVibe said:

I had the same issue with Toronto. Switched to Vancouver. It’s working fine now for me.

So I downloaded the 4th gen configuration files from here: https://www.privateinternetaccess.com/helpdesk/kb/articles/where-can-i-find-your-ovpn-files and vancouver isn't an option but i did switch to DE Frankfurt and made the adjustments suggested in this thread by @binhex and others and it's still not working :-(. what version of the config files are you using?


Edited by helpermonkey
Link to post

Okay.. so I'm using these files: 




Apparently Toronto allows port forwarding?


FAQ says to put them in /config/openvpn/   but I just see /openvpn/ no config folder?  





2)  If wget -qO-http://ipecho.net/plain | xargs echo      --> Displays Public IP




Is different than the Deluge test torrent IP...





Then it's working right? I just want to make sure because it is a little different than the FAQ. 



Edited by Supa
Link to post

Hi All - I've been having trouble connecting to the WebUI of Binhex's DelugeVPN and can't seem to figure out what's going wrong. I followed space invader one's video step by step, doing everything exactly as he suggested. I'm currently using the Romania configurations (which last time I checked, supports port forwarding). My other dockers are working fine. Would anyone be able to make any suggestions? I get "This Site can't be reached - (port 8112) refused to connect". That is my server's IP, and here are my configuration settings. 



And cert locations


Link to post
10 minutes ago, jdlancaster13 said:

Hi All - I've been having trouble connecting to the WebUI of Binhex's DelugeVPN and can't seem to figure out what's going wrong.

Attach the supervisord log to your next post. Be sure to redact user/password.

Link to post
3 minutes ago, helpermonkey said:

is there anything else i can share with you to see what might be going on with my setup? I have followed that Q22 tutorial and that did not seem to fix the problem.

Have you tried other servers? I’m using CA Montreal and haven’t had any issues at all.

Link to post
2 minutes ago, wgstarks said:

Have you tried other servers? I’m using CA Montreal and haven’t had any issues at all.

i have - i've used CA Montreal and Netherlands and keep getting that message.


Currently trying CA Montreal and this is what the top of that file looks like:

dev tun
proto udp
remote ca-montreal.privacy.network 1198
resolv-retry infinite
cipher aes-256-gcm
auth sha1
remote-cert-tls server

auth-user-pass credentials.conf
verb 1

here's the recent log:

2020-11-07 23:02:03,600 DEBG 'start-script' stdout output:
2020-11-07 23:02:03 DEPRECATED OPTION: --cipher set to 'aes-256-gcm' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-256-gcm' to --data-ciphers or change --cipher 'aes-256-gcm' to --data-ciphers-fallback 'aes-256-gcm' to silence this warning.

2020-11-07 23:02:03,601 DEBG 'start-script' stdout output:
2020-11-07 23:02:03 WARNING: file 'credentials.conf' is group or others accessible
2020-11-07 23:02:03 OpenVPN 2.5.0 [git:makepkg/a73072d8f780e888+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 27 2020
2020-11-07 23:02:03 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10

2020-11-07 23:02:03,601 DEBG 'start-script' stdout output:
2020-11-07 23:02:03 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2020-11-07 23:02:03,601 DEBG 'start-script' stdout output:
2020-11-07 23:02:03 CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
-----END X509 CRL-----

2020-11-07 23:02:03,601 DEBG 'start-script' stdout output:
2020-11-07 23:02:03 TCP/UDP: Preserving recently used remote address: [AF_INET]
2020-11-07 23:02:03 UDP link local: (not bound)
2020-11-07 23:02:03 UDP link remote: [AF_INET]

2020-11-07 23:02:03,727 DEBG 'start-script' stdout output:
2020-11-07 23:02:03 [montreal411] Peer Connection Initiated with [AF_INET]

2020-11-07 23:02:04,729 WARN received SIGTERM indicating exit request
2020-11-07 23:02:04,729 DEBG killing watchdog-script (pid 173) with signal SIGTERM
2020-11-07 23:02:04,729 INFO waiting for start-script, watchdog-script to die
2020-11-07 23:02:04,746 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 23342285760160 for <Subprocess at 23342286252352 with name watchdog-script in state STOPPING> (stdout)>
2020-11-07 23:02:04,746 DEBG fd 15 closed, stopped monitoring <POutputDispatcher at 23342285988768 for <Subprocess at 23342286252352 with name watchdog-script in state STOPPING> (stderr)>
2020-11-07 23:02:04,746 INFO stopped: watchdog-script (terminated by SIGTERM)
2020-11-07 23:02:04,747 DEBG received SIGCHLD indicating a child quit
2020-11-07 23:02:04,747 DEBG killing start-script (pid 172) with signal SIGTERM
2020-11-07 23:02:04,896 DEBG 'start-script' stdout output:
2020-11-07 23:02:04 AUTH: Received control message: AUTH_FAILED

is it possible that it's having a problem b/c I have 2 factor enabled on PIA? I can't imagine that's it b/c that's been in place for a long long time but that's the only thing i can think of ... shrug.

Link to post

Hello, i wanted to make a 2nd deluge container but all my preferences are empty, nothin in plugins, ip is n/a...

Daemon port is 58946 but im using 58947 as host port and i cant start another daemon with this port.

Edited by Kishin
Link to post
1 hour ago, binhex said:

so i have verified that my username and password are correct - i do see where it says you should only use simple alpha numeric numbers; however, i have had the same password for years so that can't be the problem. Perhaps the logs i posted in this recent thread might help us figure out what's going on:


Link to post
On 11/1/2020 at 1:07 PM, DAVIDP said:



Seems like it didn't like a 99 character password all of a sudden???? I shortened my PIA password, updated the docker config and it connected instantly..... is there a limitation in the build for password length maybe? i've had the same 99 char password for about 6 months now without incident...

Thanks for this. It appears to be a limitation on PIA's side; my old >99 character password did not work on any device. What a waste of 3 hours troubleshooting connectivity.

Link to post
On 11/1/2020 at 8:27 AM, tjb_altf4 said:

Seeing an issue from time to time where vpn connection is active, but nothing downloads or uploads.

I actually saw it in the last few days of using legacy + deluge 1.3, and assumed the old servers were cactus.


The only fix is to restart the container then everything comes to life again.

Is this something others are seeing? Maybe something happening in the PIA network?

This issue is still happening, logs show this on repeat (wireguard connection)

2020-11-09 10:59:03,623 DEBG 'watchdog-script' stdout output:

2020-11-09 11:00:38,903 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '41561'

2020-11-09 11:15:39,838 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '41561'

2020-11-09 11:29:30,654 DEBG 'watchdog-script' stdout output:

2020-11-09 11:29:34,772 DEBG 'watchdog-script' stdout output:
[warn] Incoming port site 'https://portchecker.co/' failed to web scrape, marking as failed

I can connect to UI and STRICT_PORT_FORWARD is enabled, so there is an established vpn connection (based on previous experience), but nothing actually connects.

Restart the container and everything starts to connect again.


Other than that its working quite well.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.