[Support] binhex - DelugeVPN


Recommended Posts

  

Hi,

I am getting some issue with deluge lately, it seems there is some recursive routing, but I am only using the VPN for deluge and a torrent indexer. I am using CyberGhost VPN with OpenVPN. I can still download torrent, though it spams the log file and the VPN seem to drop and restart every couple minutes and also torrent goes sometime in error. Has anyone encountered a similar issue?

Here are the logs when it seems to restart:
 

2021-09-01 15:41:20,270 DEBG 'watchdog-script' stdout output:
[info] No torrents with state 'Error' found

2021-09-01 15:41:20,741 DEBG 'start-script' stdout output:
2021-09-01 15:41:20 us=739881 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:20,093 DEBG 'start-script' stdout output:
2021-09-01 15:41:20 us=93338 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=93371 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=93386 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=93459 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:20,094 DEBG 'start-script' stdout output:
2021-09-01 15:41:20 us=94796 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:20,095 DEBG 'start-script' stdout output:
2021-09-01 15:41:20 us=94945 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=94956 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=94965 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=94974 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443
2021-09-01 15:41:20 us=95128 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:20,270 DEBG 'watchdog-script' stdout output:
[info] No torrents with state 'Error' found

2021-09-01 15:41:20,741 DEBG 'start-script' stdout output:
2021-09-01 15:41:20 us=739881 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:24,403 DEBG 'start-script' stdout output:
2021-09-01 15:41:24 us=403033 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:25,404 DEBG 'start-script' stdout output:
2021-09-01 15:41:25 us=403897 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:25,419 DEBG 'start-script' stdout output:
2021-09-01 15:41:25 us=418975 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

2021-09-01 15:41:25,404 DEBG 'start-script' stdout output:
2021-09-01 15:41:25 us=403897 Recursive routing detected, drop tun packet to [AF_INET]193.176.85.96:443

 

Link to comment

Hello,

     I've done a topic search and was unable to find an answer to this, so apologies if this was already stated somewhere else in this thread/topic.

 

Is there a way to have Deluge send a notification if the VPN fails / drops connection?  Ideally through Unraids agents, but I'll take any path that is available and easy`ish to implement.   Recently had a VPN provider make some changes and put deluge down, which broke other services until I corrected the Wireguard connection file.  I was unaware of the problem until a user brought it to my attention, so having a notification for this would be handy.

Thanks!

Link to comment

I searched for it and can not find an answer. Maybe someone has a hint how this can be done:

i have two DSL Internet connections at home which I load balanced with pfsense. When I download from other pages or via ftp I get the speed of both connections. 
Only delugevpn is using only one of these connections. Is there a way to get this to work?

Edited by boris
Link to comment
40 minutes ago, binhex said:

ensure unraid is using both connections and you will be set, i would suspect this is not the case right now.

Thanks for the reply. Unraid itself is using both connections. My pfsense is on a different machine (not on my unraid machine) and the load balancing is happening there. All docker except delugevpn can take advantage of both DSL connections.

Link to comment

Hi I recently installed Delugevpn but I've been having trouble setting it up. To my knowledge it should say "privoxy process listening to port 8118" at the bottom but it doesn't and I can't access the webui. I'm pretty new to docker and vpns in general so I apologize if the fix is really obvious. I've looked around and I can't work out what the issue is so any help would be appreciated. I'm on arch-linux by the way.
Here's the logs when I start it 

image.thumb.png.17deda4b6bbf4626b759a9416e23a03a.png

and here's the compose file

image.png.5a95aabd4deef1e5665939af3ff70650.png

Edited by jodirt
to add some extra context
Link to comment
On 9/12/2021 at 2:23 AM, jodirt said:

Hi I recently installed Delugevpn but I've been having trouble setting it up. To my knowledge it should say "privoxy process listening to port 8118" at the bottom but it doesn't and I can't access the webui. I'm pretty new to docker and vpns in general so I apologize if the fix is really obvious. I've looked around and I can't work out what the issue is so any help would be appreciated. I'm on arch-linux by the way.
Here's the logs when I start it 

 

and here's the compose file

I have the same issue. I have confirmed that VPN tunnel is UP (see below). I can ping the container, but nothing on port 8112. My VPN provider is Windscribe and I am using OpenVPN.

 

I am able to connect when I turn off VPN. 

 

sh-5.1# ping google.com
PING google.com (142.250.176.206) 56(84) bytes of data.
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=1 ttl=120 time=12.0 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=2 ttl=120 time=11.1 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=3 ttl=120 time=12.2 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=4 ttl=120 time=11.5 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=5 ttl=120 time=14.0 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=6 ttl=120 time=15.3 ms
^C
--- google.com ping statistics ---
7 packets transmitted, 6 received, 14.2857% packet loss, time 6009ms
rtt min/avg/max/mdev = 11.114/12.681/15.269/1.481 ms

 


sh-5.1# curl ifconfig.io
185.232.22.215

 


sh-5.1# ss -tulpen
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Netid        State         Recv-Q        Send-Q                   Local Address:Port                Peer Address:Port        Process                                                                                                                      
udp          UNCONN        0             0                              0.0.0.0:6771                     0.0.0.0:*            users:(("deluged",pid=585,fd=21)) uid:99 ino:1389810279 sk:5001 cgroup:unreachable:1 <->                                    
udp          UNCONN        0             0                           127.0.0.11:59772                    0.0.0.0:*            ino:1389810785 sk:5002 cgroup:unreachable:1 <->                                                                             
udp          UNCONN        0             0                    10.112.82.69%tun0:35759                    0.0.0.0:*            users:(("deluged",pid=585,fd=17)) uid:99 ino:1389810255 sk:5003 cgroup:unreachable:1 <->                                    
udp          UNCONN        0             0                         10.112.82.69:35967                    0.0.0.0:*            users:(("deluged",pid=585,fd=18)) uid:99 ino:1389810276 sk:5004 cgroup:unreachable:1 <->                                    
udp          UNCONN        0             0                              0.0.0.0:53641                    0.0.0.0:*            users:(("openvpn",pid=348,fd=3)) ino:1389804412 sk:5005 cgroup:unreachable:1 <->                                            
tcp          LISTEN        0             5                    10.112.82.69%tun0:35759                    0.0.0.0:*            users:(("deluged",pid=585,fd=16)) uid:99 ino:1389810254 sk:5006 cgroup:unreachable:1 <->                                    
tcp          LISTEN        0             50                             0.0.0.0:8112                     0.0.0.0:*            users:(("deluge-web",pid=617,fd=8)) uid:99 ino:1389768200 sk:5007 cgroup:unreachable:1 <->                                  
tcp          LISTEN        0             4096                        127.0.0.11:36595                    0.0.0.0:*            ino:1389810786 sk:5008 cgroup:unreachable:1 <->                                                                             
tcp          LISTEN        0             50                             0.0.0.0:58846                    0.0.0.0:*            users:(("deluged",pid=585,fd=13)) uid:99 ino:1389831372 sk:5009 cgroup:unreachable:1 <->  

 

EDIT: I added supervisord.log.

deludged.log

supervisord.log

Edited by sit_rp
Link to comment
2 hours ago, knowpistons said:

My container will not start up if I have the VPN enabled,  the problem started a week ago. I am using nordVPN nothing has changed in the past 6 months but all of a sudden it isn't working.  What can I do to get this working again?

supervisord.log 31.46 kB · 0 downloads

most probably an out of date ovpn file, check your vpn provider, this from your log indicates cert issues:-

2021-09-14 01:56:07 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-09-14 01:56:07 TLS Error: TLS handshake failed

 

Link to comment
4 hours ago, binhex said:

most probably an out of date ovpn file, check your vpn provider, this from your log indicates cert issues:-

2021-09-14 01:56:07 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2021-09-14 01:56:07 TLS Error: TLS handshake failed

 

That worked, thank you

Link to comment
  • 2 weeks later...

Hi.

 

I believe I have finally deciphered how to make this work.  However, I cannot access the web gui directly from Unraid's docker menu. 

 

Once I remove the network from, say, Sonarr and add it to the binhex-delugevpn network, the "WebUI" option on the Docker screen in UnRAID disappears for Sonarr.   If I visit the IP:Port directly in a web browser, it works

 

However, the containers seem to communicate fine.  Sonarr tests fine when I run the "Test" button for the download clients.  I'm still working through getting the Indexers working as well as they don't respond at all from Sonarr, but that's another issue I suspect.  I just wanted to ask about the missing WebUI link in UnRAID itself for now.

 

Is it intended behavior for the "WebUI" option to disappear from UnRAID's docker menu for any containers directly passed to the binhex-delugevpn network?  If so, may I make a suggestion for the official documentation to add this caveat to Q25/A25?

 

Overview:

image.thumb.png.6cfb47872890ae6df4af6fb885fcec73.png

 

binhex-delugevpn configuration:

image.thumb.png.9084da6f420d121ceb71c6c1551c1db6.png

 

binhex-sonarr configuration:

image.thumb.png.924c4b7c17be5f7f341f73953caf30c5.png

 

UnRAID Docker WebUI Missing:

image.png.4f6259a6c5a94408d76d33c7b21e762c.png

Edited by Jason Harris
Link to comment
8 minutes ago, Jason Harris said:

Is it intended behavior for the "WebUI" option to disappear from UnRAID's docker menu for any containers directly passed to the binhex-delugevpn network?

in a word, yes, you can add it back in if you really want i think, or simply bookmark the ip:port and be happy 🙂

  • Thanks 1
Link to comment
1 minute ago, binhex said:

in a word, yes, you can add it back in if you really want i think, or simply bookmark the ip:port and be happy 🙂

Ok no problem.  I was just pulling my hair out this past week trying to see why it wasn't working.  Totally fine with the bookmark method, that's what I was thinking I had to do.  Cheers :)

  • Like 1
Link to comment

So I'm having issues connecting with NordVPN UDP. Logs show the following repeated constantly:

 

2021-09-27 22:21:47,937 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.

2021-09-27 22:21:47,938 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 WARNING: file 'credentials.conf' is group or others accessible
2021-09-27 22:21:47 OpenVPN 2.5.1 [git:makepkg/f186691b32e68362+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 24 2021
2021-09-27 22:21:47 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10

2021-09-27 22:21:47,939 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 WARNING: --ping should normally be used with --ping-restart or --ping-exit
2021-09-27 22:21:47 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2021-09-27 22:21:47,940 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
2021-09-27 22:21:47 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

2021-09-27 22:21:47,940 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 TCP/UDP: Preserving recently used remote address: [AF_INET]89.187.182.71:1194
2021-09-27 22:21:47 Socket Buffers: R=[212992->212992] S=[212992->212992]
2021-09-27 22:21:47 UDP link local: (not bound)
2021-09-27 22:21:47 UDP link remote: [AF_INET]89.187.182.71:1194

2021-09-27 22:21:47,954 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 TLS: Initial packet from [AF_INET]89.187.182.71:1194, sid=df5141ca 49f1b7f1

2021-09-27 22:21:47,988 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA

2021-09-27 22:21:47,988 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA6

2021-09-27 22:21:47,989 DEBG 'start-script' stdout output:
2021-09-27 22:21:47 VERIFY KU OK
2021-09-27 22:21:47 Validating certificate extended key usage
2021-09-27 22:21:47 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-09-27 22:21:47 VERIFY EKU OK
2021-09-27 22:21:47 VERIFY OK: depth=0, CN=us6722.nordvpn.com

2021-09-27 22:21:50,007 DEBG 'start-script' stdout output:
2021-09-27 22:21:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
2021-09-27 22:21:50 [us6722.nordvpn.com] Peer Connection Initiated with [AF_INET]89.187.182.71:1194

2021-09-27 22:21:50,007 DEBG 'start-script' stdout output:
2021-09-27 22:21:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
2021-09-27 22:21:50 [us6722.nordvpn.com] Peer Connection Initiated with [AF_INET]89.187.182.71:1194

2021-09-27 22:21:51,157 DEBG 'start-script' stdout output:
2021-09-27 22:21:51 SENT CONTROL [us6722.nordvpn.com]: 'PUSH_REQUEST' (status=1)

2021-09-27 22:21:51,171 DEBG 'start-script' stdout output:
2021-09-27 22:21:51 AUTH: Received control message: AUTH_FAILED

2021-09-27 22:21:51,172 DEBG 'start-script' stdout output:
2021-09-27 22:21:51 SIGTERM[soft,auth-failure] received, process exiting

 

Debug is enabled, credentials are recently changed, have no special characters, and have been verified to work in browser. openvpn directory contains the UDP .ovpn file, as well as the cert files for the associated server. Both delugevpn and Unraid are up to date at the time of writing this. Any ideas here?

Edited by TechGeek01
Link to comment

So it was working on Unraid, as was sabnzbdvpn. I was attempting to get a second instance up and running (testing with my login, but setting up for a friend), and after running into these same issues, I changed the password, and updated the containers on Unraid. The only thing changed was the password. It's alphanumeric with no special characters, and 64 characters. Does it maybe need to be shortened a bit?

Link to comment

I am running binhex-nzbget thru binhex-delugevpn. Up till yesterday no problem, then this error message in binhex-nzbget:

 

- TLS certificate verification failed for news.eweka.nl: certificate has expired. For more info visit http://nzbget.net/certificate-verification

 

I downloaded a new conf file from PIA, no change. Before I start the Self signed certificate process, is there another way to fix this?

 

Most happy for any help.

 

 

Edited by frodr
Link to comment

I've been using DelugeVPN for a while and things were fine. I just noticed though that torrents do not download. They just sit there doing nothing. If I look under the Peers tab, I don't see anything listed.

 

- I know the torrents are fine, I can open on my pc in Transmission and they start downloading

- DelugePVN is working, I can properly use it as a proxy for my browsers and it works. 

- I don't see any errors in the log. Connection to PIA and port forwarding are working. 

- I think this may have started when I updated the container to the latest version recently, not positive though.

 

So it seems like everything is working but downloading torrents. I'm really not sure where to look to troubleshoot that.

 

Any thoughts or ideas?

 

Link to comment

Q6A:

Q21. I now see that you support WireGuard, how do i switch from OpenVPN to WireGuard client?

A21. Yes you are correct, all binhex VPN created images now support OpenVPN and WireGuard, for PIA and other VPN providers.

If you're a PIA user then please follow this procedure:-

Change Docker parameter from --cap-add=NET_ADMIN to --privileged=true (WireGuard requires privileged permissions).

 

 

Where in binhex-delugevpn do I find --cap-add=NET_ADMIN? This is what I see:

 

1896586703_Screenshot2021-10-02at19_39_56.png.ecfb9dd83d186891e8779efb81c9a3dd.png

 

 

// Frode

 

Link to comment
On 10/1/2021 at 8:23 AM, frodr said:

I am running binhex-nzbget thru binhex-delugevpn. Up till yesterday no problem, then this error message in binhex-nzbget:

 

- TLS certificate verification failed for news.eweka.nl: certificate has expired. For more info visit http://nzbget.net/certificate-verification

 

I downloaded a new conf file from PIA, no change. Before I start the Self signed certificate process, is there another way to fix this?

 

Most happy for any help.

 

 

Im experiencing a similar problem with sonarr and radarr.  We’re you able to find a solution.

Link to comment
11 hours ago, binarymelon said:

Im experiencing a similar problem with sonarr and radarr.  We’re you able to find a solution.

No, I'm sorry. I have to start all over again with binhex-delugevpn as Wireguard. binhex-delugevpn is working, but how do I see that Wireguard setup is working?

Link to comment

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.