[Support] binhex - DelugeVPN


Recommended Posts

9 minutes ago, binhex said:

hmm that looks fairly clean, what is the ip of the machine running the web browser?.

192.168.10.100 have not changed the config. been working for months. Just the latest update broke it.

192.168.10.20 is the server

Edited by orlando500
Link to comment
On 6/1/2021 at 8:28 PM, Autchirion said:

Hey,

 

I'm using pia and I followed spaceinvaders tutorial (and hopefully didn't miss anything), but somehow I can not get a reasonable downloadspeed. I'm stuck at ~1MBit/s. I tested it with ubuntu, with normal qbittorrent I got to ~25Mbit/s (my max down speed), but as soon I'm using deluge with VPN I'm stuck at ~1Mbit/s. Tested it with some other torrents as well, all the same.

No tracker complains about missing port forwarding also I checked if the port is open (and hopefully didn't do anything wrong). I even used it as a proxy and went to speedtest.net where I got good speed.

So what I'm wondering, how am I stuck to ~1Mbit/s as soon I use the VPN?

 

[start of edit with additional information:]

 

setup:

  1. I followed spaceinvaders tutorial (also using pia)
  2. unraid and delugevpn latest version
  3. Router Linksys EA8300 with openwrt (19.xx)
  4. Router which is used as modem has been provided by my isp.

 

issues:

  1. down/upload speed limited to 1mbit/s
  2. as soon the container is running (even with 2 torrents) I get a bad ping (50-500ms) to my modem (modem is a modem-router combi, but set to modem mode only). As router I'm using an Linksys EA3800 with openwrt.

 

findings:

  1. ping to modem is good as soon delugevpn is off, as soon I've got some torrents (not even downloading) in delugevpn my ping to the modem drops significantly. Ping to websites does not drop, but websites are way slower.
  2. My Modem can handle 180+ torrents at the same time (tested with qbittorrent without vpn).

 

what I did:

  1. reinstall delugevpn container (no change)
  2. reset my router to factory defaults and used different versions of openwrt (no change)
  3. didn't use my own router, but used the isp provided router with all router settings active (no change)
  4. tested the speed using privoxy, I was able to get full speed out of my internet connection there
  5. downloaded some torrents using delugevpn and downloaded them using qbittorrent, qbittorrent always gave full speed (used ubuntu and other well shared torrents to make sure I can saturate my internet connection).

 

 

@binhex I have been doing some extensive research and it seems like delugevpn is putting way more pressure on my modem. I'm not sure what is going on and I don't know how to research any deeper, if you are interested to fix this, let me know.

 

Thank you in Advance,

Autchi

After seeing a post here, that showed me how to get the complete logfile (and which one it is), I added this, probably this can help to explain why my modem doesn't survive the container.

Any Help welcome, I'm still at a complete loss, I'm currently only downloading ubuntu and this already is disruptive to my modem.

supervisord.log

Link to comment
49 minutes ago, orlando500 said:

Just the latest update broke it.

you know the last update happened 3 1/2 months ago, or were you simply holding off updating for a long time?, no known issues at this time with latest.

 

ok so onto the issue, i would suspect something has changed on your end, check the following and think about what might of been changed at the time the issue started:-

 

1. try different machine running web browser

2. try different browser

3. ensure router/firewall is not blocking (common issue)

4. shutdown wireguard if running on unraid host

5. check vlan is not blocking

6. try going to 'terminal' of container and issue the following command:-

curl http://localhost:8112

 

if you see output then you know the web ui is operational.

7. restart host

8. try resetting deluge, rename /config/core.conf to /config/core.conf.old and then restart the container.

Link to comment
27 minutes ago, Autchirion said:

After seeing a post here, that showed me how to get the complete logfile (and which one it is), I added this, probably this can help to explain why my modem doesn't survive the container.

Any Help welcome, I'm still at a complete loss, I'm currently only downloading ubuntu and this already is disruptive to my modem.

supervisord.log 88.02 kB · 0 downloads

weak hardware is the normal cause for this, your options really are to reduce the load on the modem (you mean router right?) by reducing the number of connections, you could also reduce the load by slowing your dl and ul rates in deluge, this will most probably get you a more stable connection, but in reality your best bet is to replace that router.

Link to comment
12 minutes ago, binhex said:

you know the last update happened 3 1/2 months ago, or were you simply holding off updating for a long time?, no known issues at this time with latest.

 

ok so onto the issue, i would suspect something has changed on your end, check the following and think about what might of been changed at the time the issue started:-

 

1. try different machine running web browser

2. try different browser

3. ensure router/firewall is not blocking (common issue)

4. shutdown wireguard if running on unraid host

5. check vlan is not blocking

6. try going to 'terminal' of container and issue the following command:-



curl http://localhost:8112

 

if you see output then you know the web ui is operational.

7. restart host

8. try going from scratch, you will of course need to put the vpn config files in the correct place.

 

1) same for different machine

2) same for different browser (tried chrome and MS edge)

3) not blocking any local traffic

4)wireguard is off

5) no vlan use

6) sh-5.1# curl http://localhost:8112
curl: (7) Failed to connect to localhost port 8112: Connection refused
sh-5.1# 

7) host is restarted

8 ) yes it seems i need to start from scratch... strange, it would be nice to have some sort of "check the config/problem solving" script :-) i just dont know what to look for in these stops. And yes i know its been a while for the update. This is the reason i dont like to update so often. It tends to break stuff. All other binhex dockers run fine and i update them once a week.

 

edit: btw: the first curl was from container terminal, here is from server terminal:

root@hal:~# curl http://localhost:8112
curl: (56) Recv failure: Connection reset by peer

Edited by orlando500
Link to comment
3 hours ago, binhex said:

try https://localhost:8112 it might be that you are using https.
 
this is correct, you wont get through from the host terminal (blocked via iptables).

p.s. thanks for the donation

 

https gave the same error.  Im trying to reinstall now.

 

ps: you deserve some support for all your hard work. we take for granted all the hours you put down in the binhex dockers. But from time to time i try to show that i care and want to thank you...

Link to comment

Maybe someone has an idea what's wrong, sorry because probably offtopic:

 

As soon as a torrent is up/downloading my WHOLE internet connection drops in an instant.

Latency up to 500ms or timeout, up/download <1mbit

Happens on all clients, iPhones, iPads, my desktop...

I'm using UniFi-Gear so it should be more than capable to handle the tasks at hand...

 

The only thing I can think of would be to many connections but even the crappiest hardware I've ever used had no problem with the 400-setting in deluge...

Link to comment
18 hours ago, binhex said:

weak hardware is the normal cause for this, your options really are to reduce the load on the modem (you mean router right?) by reducing the number of connections, you could also reduce the load by slowing your dl and ul rates in deluge, this will most probably get you a more stable connection, but in reality your best bet is to replace that router.

Thank you for your answer, as a clarification regarding the router-modem topic. I'm using cable internet, this goes into a device which is provided by my ISP, this can act as a router as well, or just "change" the packets that are comming from the cable to ethernet. I'm using this device merely to do that, it doesn't create a wifi, I can not connect multiple devices to it etc. So all the other stuff (WiFi, DHCP and other services) are done by my router (my own hardware).

As a short explanation what you get from your ISP is a modem-router, but they only call it router, because most people don't care about the difference. Modem (modulator demodulator) de-/modulates the cable (or whatever connection type you use) signal from/to ethernet. The router then provides the packets that are embedded in these signals to the devices in your network. 

My router doesn't have any issues keeping up, that's 100% sure, the device which is provided by my ISP can't keep up, I figured this out with different tries.

 

So, my point is, I used to have 150+ torrents running on qbittorrent (without VPN), but as soon I add one torrent to delugevpn my modem just plainly gives up. Now, why can my modem (of router if you want to) handle 150+ torrents without a vpn, but can't keep up with 1 torrent if I use VPN. I'm not a network expert, I've got only very basic understanding of the ISO-OSI model with TCP/IP. But what I understand VPN is doing, it takes all the packets encrypts them and sends them to a different receiver. This should not generate any additional load on the router, only on the device that runs the VPN. I agree, it might cause a minor increase of traffic by a small one digit percentage, but not significant (1 vs 150+ torrents).

 

So what I'm thinking is, as soon there is a torrent active the openvpn hammers my modem with requests, that it eventual will reject but this will put heavy load on my modem.

 

But I understand this might go beyond what we are handling here, what I'm currently considdering is to use wireshark to record some of the network traffic with delugevpn on, then some with qbittorrent on and one without any of these on and see if there is a major differences in messages. If not, my ISP fucked up the modem-router software and I'm screwed, because changing this usually causes big trouble with my ISP.

Link to comment
30 minutes ago, Autchirion said:

but as soon I add one torrent to delugevpn my modem just plainly gives up. Now, why can my modem (of router if you want to) handle 150+ torrents without a vpn, but can't keep up with 1 torrent if I use VPN. I'm not a network expert, I've got only very basic understanding of the ISO-OSI model with TCP/IP. But what I understand VPN is doing, it takes all the packets encrypts them and sends them to a different receiver. This should not generate any additional load on the router, only on the device that runs the VPN.

the load on your modem will be increased by having to send fully encrypted packets to a remote vpn endpoint, but yeah the load should not be significant as its not doing the encryption, however badly designed firmware can cause issues here, especially if not fully tested with a vpn connection, so i would suspect the combination of mediocre hardware in your modem and the combination of poor firmware is most probably the culprit, perhaps check if there is an firmware update for your modem, or google around the make and model of your modem and see if anybody has a resolution for your issue.

Link to comment
On 6/7/2021 at 8:42 AM, binhex said:

from your log:-

 






2021-06-06 22:52:05 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

2021-06-06 22:52:05 TLS Error: TLS handshake failed

so its either a issue with connectivity to the vpn endpoint or an issue with their certificate that they issued, try a different endpoint and/or downloading the latest openvpn config files.

Thanks for looking at the log file. I didn't think to go back and look if my config files were still there. 

 

When I toggle the VPN_ENABLED "off" in the edit I am able to access the WEBui, when I turn it back on no access to WEBui.

 

When my appdata/binhex-delugevpn/openvpn folder was empty I dropped in my .conf and .ovpn files from a backup. This got the log file dancing, but I could not get into the WEBui still.

 

I grabbed a fresh .ovpn file from my VPN provider (UDP type) and deleted the previous .conf file. A new .conf file was generated when I restarted the container. Still no luck getting into WEBui and the log file was actively writing. 

 

I also have changed my password with the VPN hoping that might update something on their end for me. Hasn't seemed to, I still have the same scrambled username and password to input into the docker I had been using for nearly a year. 

 

It feels like I am getting closer now. 

2021-06-08 Log File.txt

Link to comment
18 hours ago, binhex said:

the load on your modem will be increased by having to send fully encrypted packets to a remote vpn endpoint, but yeah the load should not be significant as its not doing the encryption, however badly designed firmware can cause issues here, especially if not fully tested with a vpn connection, so i would suspect the combination of mediocre hardware in your modem and the combination of poor firmware is most probably the culprit, perhaps check if there is an firmware update for your modem, or google around the make and model of your modem and see if anybody has a resolution for your issue.

Here is the catch with that, when using the privoxy tunnel of said container with my other PC and checking the speed with speedtest.net I get 260mbit/s down and 51mbit/s up (I've got a 250/50 line, so this is the maximum I can expect). Also I get full speed using the official app on my PC, which is again an argument against a general problem with the modem having issues. But I also received a new version of the router/modem from my provider. I first have to check if I can operate it as a modem, as soon I know this is possible, I'll switch to said modem and hope for the best.

But this is only a thought I'm having right now, as I said I'll look further into it and keep you posted on the topic. So you might be able to help the next person that has the same issue. 🙂

 

One more question, do you plan on using/enabling wireguard for this container? I'm using wireguard for other things a lot and I think it's the supperior protocoll.

Link to comment

Hi everyone,

 

Yesterday I was playing with HW transcoding settings in Plex that caused me to bounce my machine several times. Since then, I've had almost ~4k of my torrents sitting in "Queued", with just under 2k seeding. I use PIA as my VPN. 

My Queue settings are:

Total - 8000

Download - 4000

Uploading - 6000

 

I have just under 6k torrents total, with 244 on Downloading. Any ideas?

Link to comment
6 hours ago, binhex said:

authentication failure now, from your log:-

 


2021-06-08 22:22:10,145 DEBG 'start-script' stdout output:
2021-06-08 22:22:10 AUTH: Received control message: AUTH_FAILED

see Q16:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Thanks, got it going now.

 

My issues likely were:

  • old ovpn file, replaced with new one
  • didn't wait long enough for new password to update with VPN provider before trying it with the container
  • Like 1
Link to comment

Hey Guys,

 

I'm using PIA with the current delugevpn container. It worked fine once, then I rebooted now it isn't working perfectly any more. So, one of my trackers requires that I can be contacted from outside (aka port is forwarded). This tracker reports (which it wasn't before the restart), that I'm not reachable now.

I used https://www.yougetsignal.com/tools/open-ports/ to check if the port is opened, but it isn't. I couldn't find any error message in the log file or anything that would indicate that something went wrong. Also I checked in deluge, the incoming port is exactly set as the same port which is used by the VPN.

 

Anything else I need to check? I already attached a log file, I don't understand what is happening here.

 

I could try fireguard (I would love to use this in future), but I'm not sure if something else is going wrong and I don't want to mess with too much stuff.

 

Thank you in advance,

Autchi

Link to comment
11 minutes ago, binhex said:

did you put in the external ip assigned to you from the vpn provider? (shown in the log), otherwise if using your isp's assigned ip it will show the port closed.

could have pointed that out, sorry. Yes, I did that.

Currently it's:

2021-06-10 14:15:49,273 DEBG 'watchdog-script' stdout output:
[debug] VPN incoming port is 20694
[debug] Deluge incoming port is 20694
[debug] VPN IP is 10.23.112.2
[debug] Deluge IP is 10.23.112.2

feel free to double check.

 

It just fixed itself (at least according to the tracker), I don't know what happened, but it seems like it takes more than half an hour to get the port forwarded... or something else happened. But checking on the website still reports as port is not forwarded.

 

I added the log file where this must have happened. 

supervisord.log

Edited by Autchirion
fixed itself
Link to comment
10 minutes ago, Autchirion said:

could have pointed that out, sorry. Yes, I did that.

Currently it's:


2021-06-10 14:15:49,273 DEBG 'watchdog-script' stdout output:
[debug] VPN incoming port is 20694
[debug] Deluge incoming port is 20694
[debug] VPN IP is 10.23.112.2
[debug] Deluge IP is 10.23.112.2

feel free to double check.

ahh sorry my bad, looks like i echo out the internal tunnel ip address not the external ip, so for your example above 10.23.112.2 will be internal only, you need the external ip, this can be found by opening terminal for the container and running the command:-

curl ifconfig.io

this will return an ip, copy and paste this into https://www.yougetsignal.com/tools/open-ports/ with the currently assigned port (check log as it can change) and test it, i think you will find its open.

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

ahh sorry my bad, looks like i echo out the internal tunnel ip address not the external ip, so for your example above 10.23.112.2 will be internal only, you need the external ip, this can be found by opening terminal for the container and running the command:-


curl ifconfig.io

this will return an ip, copy and paste this into https://www.yougetsignal.com/tools/open-ports/ with the currently assigned port (check log as it can change) and test it, i think you will find its open.

 

Thank you, that worked out well, so I would assume it's a tracker issue because of the randomly changing port after a reboot of the container.

 

Suggestion: Add the output of the external IP into the log.

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.