[Support] binhex - DelugeVPN


Recommended Posts

NEVERMIND FIXED: After discovering there were no config files for deluge-vpn I disabled and re-enabled docker. Config files showed up, copied openvpn files as per usual and I'm back up and running. Leaving this post for others. 

 

Had some kind of event at 3am that killed my dockers. Could have been a power outage I guess, I have a UPS but it has never worked very well with unraid. I'm not even sure that was it as the server was powered on and it shouldn't have been if there was an outage. 

UPDATE: 3am on Sunday is when my dockers auto-update. 

Regardless, all of my dockers came back up except binhex deluge-vpn. When I try to start it I get Execution Error Server Error window. When I check the server logs the only thing that shows up is BELOW. I have had my server set up for IPV4 only in network settings for years. Supervisord.log hasn't been touched since 3am. 

 

UPDATE: I got impatient and deleted the docker and re-installed. On startup I got;

/usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint binhex-delugevpn (af91521bd4e05570c2288cc4ccc838cbe668d260d8971415f2e7ecf929226404): Bind for 0.0.0.0:58946 failed: port is already allocated.

 

The port is not allocated to any other docker though. 

 

UPDATE: Now there are no config files written at all. 

 

 

 

Dec 21 09:23:33 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): veth37e079a: link is not ready
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered blocking state
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered forwarding state
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered disabled state
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered disabled state
Dec 21 09:23:33 tmedia kernel: device veth37e079a left promiscuous mode
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered disabled state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered blocking state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:29:18 tmedia kernel: device vethd741bb1 entered promiscuous mode
Dec 21 09:29:18 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): vethd741bb1: link is not ready
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered blocking state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered forwarding state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:29:18 tmedia kernel: device vethd741bb1 left promiscuous mode
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered blocking state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:32:30 tmedia kernel: device veth63d7cc7 entered promiscuous mode
Dec 21 09:32:30 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): veth63d7cc7: link is not ready
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered blocking state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered forwarding state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:32:30 tmedia kernel: device veth63d7cc7 left promiscuous mode
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered blocking state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state
Dec 21 09:37:49 tmedia kernel: device vethdc3cb46 entered promiscuous mode
Dec 21 09:37:49 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): vethdc3cb46: link is not ready
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered blocking state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered forwarding state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state
Dec 21 09:37:50 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state
Dec 21 09:37:50 tmedia kernel: device vethdc3cb46 left promiscuous mode
Dec 21 09:37:50 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state

 

 

Edited by sol
Link to comment

So, a few months ago I set up DelugeVPN with PIA's wireguard and it worked.  I haven't downloaded anything since then, but now nothing is downloading.  I can access the webUI just fine, I've tried it with port forwarding on and off, but downloads just sit at "downloading."


I cannot find a guide on how to set Wireguard up in the container and unfortunately I can't remember how I did it if the first time.

 

There's a wg0.conf (/appdata/binhex-delugevpn/wireguard/wg0.conf) file that I believe needs to be edited, but I don't know what I should be putting there.

 

Any help would be appreciated!

 

Thanks!

Edited by aidenpryde
added more information
Link to comment
5 hours ago, aidenpryde said:

I can access the webUI just fine

if you can access the web ui then there is nothing wrong with the wireguard configuration, do you see anything download at all?, or is everything at 0?.

 

can you attach a screenshot for the settings screen showing incomplete and completed folder configuration for deluge web ui, as well as screenshot for unraid settings for the docker contianer.

  • Like 1
Link to comment

Hi, I've opened the port 8112 on my router and can successfully access the webui when I am not at home, though it seems that I CANNOT access containers that I route through the delugeVPN container. I followed spaceinvaderone's tutorial on how to route traffic from one container to another, so all can sit behind one VPN. Local access is no problem. I think that it has something to do with IPtables though I do not have enough knowledge to be certain. I tried to modify the IP tables through the console of the container and I managed to get the port 34400 (which is the port I am interested in accessing) to have the same settings as port 8112 when typing `iptables -L`. However it does change anything :/

 

I hope that I have provided enough information, and hopefully my issue is solvable. Thanks in advance.

Link to comment
7 hours ago, binhex said:

if you can access the web ui then there is nothing wrong with the wireguard configuration, do you see anything download at all?, or is everything at 0?.

 

can you attach a screenshot for the settings screen showing incomplete and completed folder configuration for deluge web ui, as well as screenshot for unraid settings for the docker contianer.

Ugh, started the container up today, and now things are downloading.  I didn't make any changes.

Link to comment
3 hours ago, tomas.lejdung said:

Hi, I've opened the port 8112 on my router and can successfully access the webui when I am not at home, though it seems that I CANNOT access containers that I route through the delugeVPN container. I followed spaceinvaderone's tutorial on how to route traffic from one container to another, so all can sit behind one VPN. Local access is no problem. I think that it has something to do with IPtables though I do not have enough knowledge to be certain. I tried to modify the IP tables through the console of the container and I managed to get the port 34400 (which is the port I am interested in accessing) to have the same settings as port 8112 when typing `iptables -L`. However it does change anything :/

 

I hope that I have provided enough information, and hopefully my issue is solvable. Thanks in advance.

have you specified the application web ui port(s) using the "ADDITIONAL_PORTS" env var? you will need to do that when using multiple applications routed through my vpn containers.

Link to comment
1 minute ago, aidenpryde said:

Thanks for looking at my post.

Are there any instructions for changing the servers via the Wireguard settings for PIA?  I've yet to find a guide for setting it up.

Q21 point 5:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md a list of the servers will be shown in the log /config/supervisord.log that support port forwarding.

  • Like 1
Link to comment
38 minutes ago, binhex said:

have you specified the application web ui port(s) using the "ADDITIONAL_PORTS" env var? you will need to do that when using multiple applications routed through my vpn containers.

Thanks for the reply. I have now added the port to the ADDITIONAL_PORTS and it now shows up on the iptables, though the issue still persists... The container that I am trying to route through the delugeVPN container is xTeve, which uses port 34400.

 

I also tried routing radarr through the contains to see if xTeve was the issue but I can't get it to work either...

Edited by tomas.lejdung
more info
Link to comment
4 minutes ago, alturismo said:

@tomas.lejdung which xteve container are you trying to route through this one ? in github u asked about my xteve_vpn container which wont work to route through another vpn container, just as note ...

 

take a regular xteve one, use the --network ... like described in tutorials and it will work just nice, also through binhex vpn container.

I switched to your regular xteve container when trying to route it through binhex's VPN container. But as stated above I did not get it to work with radarr when routing it through delugeVPN, but it works when I dont use any VPN.

Link to comment
On 12/19/2020 at 1:16 PM, wgstarks said:

You can switch to PIA’s next-gen servers to correct your connection issues but this will also require upgrading the docker container (and the Deluge app) to the latest version. You will likely see the original issues with Deluge return since it’s probably still the same version you originally had issues with. I switched docker containers instead. I’m now using binhex-qbittorrentvpn docker with the PIA next-gen servers until Deluge releases an update that hopefully fixes some of their bugs.

Thank you for helping. Think i'll do the same :)

 

Link to comment
On 12/19/2020 at 1:16 PM, wgstarks said:

You can switch to PIA’s next-gen servers to correct your connection issues but this will also require upgrading the docker container (and the Deluge app) to the latest version. You will likely see the original issues with Deluge return since it’s probably still the same version you originally had issues with. I switched docker containers instead. I’m now using binhex-qbittorrentvpn docker with the PIA next-gen servers until Deluge releases an update that hopefully fixes some of their bugs.

So is wireguard the best way to go for speed with PIA?

 

Thanks

 

Link to comment

Super slow download speeds with PIA enabled.  So I weathered the next-gen pia server fiasco and thought it would be great now that bihnexx got deluge to work with the new servers.  However since getting myself setup with the next-gen servers my download speeds are total garbage.  Is PIA still messed up or is it the docker container?  With vpn enabled in the docker I download at 210kib/s.  It takes days to get a download a that speed.  PIA has not responded to my support tickets so am looking to you all for help.  SHould i ditch PIA if so what other VPN services are there that are trusted by the torrent community?

Link to comment
6 hours ago, whitewraith said:

Super slow download speeds with PIA enabled.  So I weathered the next-gen pia server fiasco and thought it would be great now that bihnexx got deluge to work with the new servers.  However since getting myself setup with the next-gen servers my download speeds are total garbage.  Is PIA still messed up or is it the docker container?  With vpn enabled in the docker I download at 210kib/s.  It takes days to get a download a that speed.  PIA has not responded to my support tickets so am looking to you all for help.  SHould i ditch PIA if so what other VPN services are there that are trusted by the torrent community?

What speeds do you get with a well seeded torrent like ubuntu?

 

Have you tried multiple servers? I’ve had good luck with the Canadian servers.

Link to comment

I am trying to set up a thin client on an ubuntu VM running on my Unraid server. The same server as my DelugeVPN docker container.

But I cannot open and edit the auth file? It just say I don't have permission.

How do I connect the thin client? Is there a default username/password? 

Link to comment

Awesome work.

 

Not sure if it's for this or your regular deluge container. But is it possible to run one deluge container entirely through proxy or is it still leaky and insecure? I already have a container to a custom vpn provider with static ip w/ binhex-deluge-vpn but the webui is getting slow so I thought about spinning up another instance and use the same connection, that is proxy to binhex-deluge-vpn.

 

Could I just binhex-delugevpn and the proxy settings in deluge, should I use something else or give up?

Link to comment

Hello, I've been scanning through the last several pages but can't seem to figure out what wrong on my end. My speeds have been so slow for a few weeks now and even after migrating from the :test image I had used as a temporary fix to the newest one via update just now, I am still either not being connected to very busy torrents or getting terrible speeds. Any help would be appreciated, thanks for all your work binhex and other devs!

 

Unraid 6.8.3

latest binhex-delugevpn

ExpressVPN with a .ovpn file and credentials.conf

 

Happy to post logs but the only flags I'm seeing are just depreciated features relating to OVPN 2.6 and cipher options

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.