[Support] binhex - DelugeVPN


8536 posts in this topic Last Reply

Recommended Posts

Still having issues with this... Current log file errors:

 

Current settings in the OVPN file:

 

client
dev tun
proto udp
remote ca-montreal.privacy.network 1198
resolv-retry infinite
nobind
persist-key
data-ciphers-fallback aes-256-gcm
ncp-disable
auth sha1
tls-client
remote-cert-tls server

auth-user-pass credentials.conf
compress
verb 1


 

2020-11-03 10:30:29,801 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 AUTH: Received control message: AUTH_FAILED

2020-11-03 10:30:29,801 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 SIGTERM[soft,auth-failure] received, process exiting

2020-11-03 10:30:29,802 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2020-11-03 10:30:29,807 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6

2020-11-03 10:30:29,807 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 WARNING: file 'credentials.conf' is group or others accessible

2020-11-03 10:30:29 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-03 10:30:29 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10

2020-11-03 10:30:29,807 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2020-11-03 10:30:29,808 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
XXXXX
-----END X509 CRL-----


2020-11-03 10:30:29,808 DEBG 'start-script' stdout output:
2020-11-03 10:30:29 TCP/UDP: Preserving recently used remote address: [AF_INET]172.98.71.91:1198
2020-11-03 10:30:29 UDP link local: (not bound)
2020-11-03 10:30:29 UDP link remote: [AF_INET]172.98.71.91:1198

2020-11-03 10:30:30,014 DEBG 'start-script' stdout output:
2020-11-03 10:30:30 [montreal402] Peer Connection Initiated with [AF_INET]172.98.71.91:1198

 

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

I am also having a bit of trouble; for reference, unraid is behind pfsense, which I've been using for a while. The new update doesn't allow deluge to connect. On current build with nextgen files added. IPv6 enabled or disabled, still the same issue and won't get past this part:

kernel: docker0: port 4(veth5cfa152) entered disabled state
kernel: device veth5cfa152 left promiscuous mode
kernel: docker0: port 4(veth5cfa152) entered disabled state
avahi-daemon[7207]: Withdrawing address record for fe80::5c93:22ff:fef5:3030 on veth5cfa152.
kernel: docker0: port 4(vethebe7b8a) entered blocking state
kernel: docker0: port 4(vethebe7b8a) entered disabled state
kernel: device vethebe7b8a entered promiscuous mode
kernel: docker0: port 4(vethebe7b8a) entered blocking state
kernel: docker0: port 4(vethebe7b8a) entered forwarding state
kernel: eth0: renamed from vethe5d019a
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethebe7b8a: link becomes ready
avahi-daemon[7207]: Joining mDNS multicast group on interface vethebe7b8a.IPv6 with address fe80::5c84:3aff:fe61:9d57.
avahi-daemon[7207]: New relevant interface vethebe7b8a.IPv6 for mDNS.
avahi-daemon[7207]: Registering new address record for fe80::5c84:3aff:fe61:9d57 on vethebe7b8a.*.     <--------won't get past this part

 

 

 

EDIT: if you are running into a similar problem, I found switching servers was the answer. Originally, I was trying to connect to DE Frankfurt, as it was part of the BETA, but wouldn't connect. UK Manchester does work though. More testing will need to be done to find an acceptable server.

Edited by Psycho249
Link to post

Nada - the log file just keeps spitting out log errors. Web UI won't load and it starts to bog down the server.


 

2020-11-03 10:44:37,594 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2020-11-03 10:44:37,599 DEBG 'start-script' stdout output:
2020-11-03 10:44:37 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6

2020-11-03 10:44:37,599 DEBG 'start-script' stdout output:
2020-11-03 10:44:37 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-03 10:44:37 WARNING: file 'credentials.conf' is group or others accessible

2020-11-03 10:44:37 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-03 10:44:37 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10

2020-11-03 10:44:37,599 DEBG 'start-script' stdout output:
2020-11-03 10:44:37 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2020-11-03 10:44:37,599 DEBG 'start-script' stdout output:
2020-11-03 10:44:37 CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
xxxxxxx
-----END X509 CRL-----


2020-11-03 10:44:37,600 DEBG 'start-script' stdout output:
2020-11-03 10:44:37 TCP/UDP: Preserving recently used remote address: [AF_INET]199.36.223.212:1198
2020-11-03 10:44:37 UDP link local: (not bound)
2020-11-03 10:44:37 UDP link remote: [AF_INET]199.36.223.212:1198

2020-11-03 10:44:37,715 DEBG 'start-script' stdout output:
2020-11-03 10:44:37 [montreal410] Peer Connection Initiated with [AF_INET]199.36.223.212:1198

2020-11-03 10:44:38,888 DEBG 'start-script' stdout output:
2020-11-03 10:44:38 AUTH: Received control message: AUTH_FAILED

2020-11-03 10:44:38,888 DEBG 'start-script' stdout output:
2020-11-03 10:44:38 SIGTERM[soft,auth-failure] received, process exiting

 

Link to post

Q22 complete and still can't connect properly.  I've tried several servers across various countries.

 

Currently on romania with config:

client
dev tun
proto udp
remote ro.privacy.network 1198
remote nl-amsterdam.privacy.network 1198
remote uk-manchester.privacy.network 1198
remote ca-vancouver.privacy.network 1198
remote ca-montreal.privacy.network 1198
remote ca-toronto.privacy.network 1198
remote ca-ontario.privacy.network 1198
resolv-retry infinite
nobind
persist-key
cipher aes-256-gcm
ncp-disable
auth sha1
tls-client
remote-cert-tls server

It seems to connect, webui works, downloads start, then drop to 0 KiB/s quickly.  This behavior is the same after each deluge reboot, no matter what I change it seems. Any ideas?

 

 

Link to post
This behavior is the same after each deluge reboot, no matter what I change it seems. Any ideas?


Maybe try the WireGuard option instead of OpenVPN? It’s working very well for me, none of these cipher problems.
Although your problem seems unrelated if it actually connects successfully at first.
Are your trackers blocking you? Have you run out of space on any disks that deluge are using?


Sent from my iPhone using Tapatalk
Link to post
1 hour ago, Jorgen said:

 


Maybe try the WireGuard option instead of OpenVPN? It’s working very well for me, none of these cipher problems.
Although your problem seems unrelated if it actually connects successfully at first.
Are your trackers blocking you? Have you run out of space on any disks that deluge are using?


Sent from my iPhone using Tapatalk

 

Tried switching to wireguard, same result.  Disks look good on space.  Not sure on trackers.  I'm going to check out the deluge forums to see if anyone is experiencing anything similar.

Link to post
3 hours ago, KillahPwnz said:

Tried switching to wireguard, same result.  Disks look good on space.  Not sure on trackers.  I'm going to check out the deluge forums to see if anyone is experiencing anything similar.

Couldn't find much on deluge forums - only that people had success switching to QBitTorrent.  I switched to QBitTorrent (by binhex) and I'm getting the same result.  The torrent(s) is added to the client, then almost immediately drops to 0 KiB/s after starting (upon container reboot).  I'm at a loss here, not sure what else I can try.  Keep in mind, everything worked fine just a few days ago.

Link to post
Couldn't find much on deluge forums - only that people had success switching to QBitTorrent.  I switched to QBitTorrent (by binhex) and I'm getting the same result.  The torrent(s) is added to the client, then almost immediately drops to 0 KiB/s after starting (upon container reboot).  I'm at a loss here, not sure what else I can try.  Keep in mind, everything worked fine just a few days ago.

So is the VPN still up when the download drops to 0? I guess it must be if you can access the deluge web UI.
You have tried other endpoints?
Debug logs might reveal something, but I agree that this seems to be a problem outside the container, especially since the other container has the same problem.


Sent from my iPhone using Tapatalk
Link to post
6 hours ago, KillahPwnz said:

Couldn't find much on deluge forums - only that people had success switching to QBitTorrent.  I switched to QBitTorrent (by binhex) and I'm getting the same result.  The torrent(s) is added to the client, then almost immediately drops to 0 KiB/s after starting (upon container reboot).  I'm at a loss here, not sure what else I can try.  Keep in mind, everything worked fine just a few days ago.

Have you tried a well seeded torrent? Ubuntu maybe.

Link to post
5 hours ago, Jorgen said:


So is the VPN still up when the download drops to 0? I guess it must be if you can access the deluge web UI.
You have tried other endpoints?
Debug logs might reveal something, but I agree that this seems to be a problem outside the container, especially since the other container has the same problem.


Sent from my iPhone using Tapatalk

Yeah I've tried several endpoints and the logs don't seem to show anything wrong.

Link to post

recently restored my cache, but delugevpn no longer working as it was

i believe it has to do with the .ovpn file in app data folder

 

i've used the spaceinvader one tutorial (2017), but it may be out of date at this point

please let me know if these files are correct, or if i should be looking at something else

 

In my  appdata>binhex-delugevpn>openvpn folder i have pasted the following 3 files

<crl.rsa.2048.pem>

<ca.rsa.2048>

CA Toronto.ovpn           (i've tried Israel, Netherlands, Romania & Switzerland as well)

 

the PIA site suggests US has port forwarding available too, but unclear to me exactly what to paste in app data folder

 

 

Link to post
35 minutes ago, strykn said:

recently restored my cache, but delugevpn no longer working as it was

i believe it has to do with the .ovpn file in app data folder

 

i've used the spaceinvader one tutorial (2017), but it may be out of date at this point

please let me know if these files are correct, or if i should be looking at something else

 

In my  appdata>binhex-delugevpn>openvpn folder i have pasted the following 3 files

<crl.rsa.2048.pem>

<ca.rsa.2048>

CA Toronto.ovpn           (i've tried Israel, Netherlands, Romania & Switzerland as well)

 

the PIA site suggests US has port forwarding available too, but unclear to me exactly what to paste in app data folder

 

 

See Q19 and Q22 in the FAQ to get up and running: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

Link to post

First off thank you Binhex for all your hard work on keeping all your apps up to date.

 

I recently switched over to the wireguard setup following A21 in the FAQ doc:
https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

 

The switch was painless and easy to get up and running.  You made it very easy to follow.  Thank you!

 

One question I have on changing endpoints, we just need to change the first part of this line, and leave the port at 1337 correct?

Endpoint = nl-amsterdam.privacy.network:1337

 

When I look at the nextgen Netherlands.ovpn file I see this line:

remote nl-amsterdam.privacy.network 1198

 

I am assuming the ports are specific to the type of connection, udp or wireguard, and should be left untouched.

Link to post
20 minutes ago, Burizado said:

One question I have on changing endpoints, we just need to change the first part of this line, and leave the port at 1337 correct?

yes, dont touch the port, 1337 is pia's choosen port for wireguard, port 1198 is used for openvpn.

  • Like 1
  • Thanks 1
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.

Guest
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.