[Support] binhex - DelugeVPN


Recommended Posts

On 1/18/2019 at 7:26 AM, binhex said:

lol well that will do it, how odd that its not ALL qnap users that are affected by this.

 

if i were you i would remove that line from that file and see what happens.

Just a heads up that I had the same problem -- thanks to @WarezMonkey for finding the root cause. Removing this line from /etc/daemon_mgr.conf seems to do the trick (different number in my daemon list apparently, but same idea):

DAEMON65 = openvpn, stop, /usr/sbin/openvpn

When I add the line back, things break after about 30 seconds, manifesting as a lot of entries like this in deluge:

 

Error: Cannot assign requested address


And on the docker logs:

 

[info] Deluge listening interface IP 10.8.10.6 and VPN provider IP 10.31.10.6 different, marking for reconfigure                            

I'm suspecting the reason it wasn't an issue for other users in the past may have to do with QNAP switching the default network mode on Docker to NAT instead of bridge at some point, but I'm not sure about that.

If it helps, I'm on a QNAP TS-251 running 4.3.6.0805, on ContainerStation 1.9.3590.

 

I also suspect if @WarezMonkey is right about how daemon_mgr works, simply renaming the docker image's openvpn binary to something else would do the trick, but that'd also involve updating all the scripts that call into it (and possibly os-level stuff in the image?)

 

Thanks for the hard work here; this beats the heck out of the hacked-together VM image I was using for this purpose before!

Edited by droppedD
Link to comment
8 hours ago, droppedD said:

simply renaming the docker image's openvpn binary to something else would do the trick, but that'd also involve updating all the scripts that call into it (and possibly os-level stuff in the image?)

i really dont want to do this, as the issue is specific to qnap only, i think you guys should be feeding back to qnap support and ask the question why are they killing specific/all openvpn processes, seems a very bad thing to do in my opinion, you could always drop qnap and use unraid, its sooo much better 🙂

Link to comment
6 hours ago, binhex said:

i really dont want to do this, as the issue is specific to qnap only, i think you guys should be feeding back to qnap support and ask the question why are they killing specific/all openvpn processes, seems a very bad thing to do in my opinion, you could always drop qnap and use unraid, its sooo much better 🙂

Yeah... I'm guessing at the very least they need to modify their nanny script to ignore processes namespaced to docker/containerstation since those won't really conflict with the OS processes anyways; I filed a ticket with their support people about this. Unraid sounds like the right solution for my next NAS, I'm sure!

Link to comment

I'm experiencing something very similar with my QNAP.  I moved from unraid and it was working then it was not.  I looked at /etc/daemon_mgr.conf but only found "DAEMON53 = openvpn, start, QNAP_QPKG=QVPN /usr/sbin/openvpn --config /etc/openvpn/server.conf --daemon ovpn-server" and not the  "stop" other have removed to solve the problem. My logs look good on the container but access is a no go. 

 

I'm receiving the error:

 

192.168.1.54 took too long to respond.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_TIMED_OUT

 

Link to comment
3 hours ago, daddygrant said:

I'm experiencing something very similar with my QNAP.  I moved from unraid and it was working then it was not.  I looked at /etc/daemon_mgr.conf but only found "DAEMON53 = openvpn, start, QNAP_QPKG=QVPN /usr/sbin/openvpn --config /etc/openvpn/server.conf --daemon ovpn-server" and not the  "stop" other have removed to solve the problem. My logs look good on the container but access is a no go. 

 

I'm receiving the error:

 

192.168.1.54 took too long to respond.

Try:

Checking the connection

Checking the proxy and the firewall

ERR_CONNECTION_TIMED_OUT

 

im assuming then that you are running an openvpn server on your qnap box right?.

Link to comment
8 minutes ago, darrenyorston said:

I am having difficulty with the VPN side of the container.

 

Its installed successfully and starts fine with VPN turned off. But with VPN turned on I am getting the "site cannot be reached" error. I feel have my PIA details inserted correctly. I know they are correct as I can copy paste from the template into PIA's logon in page and successfully access my account. I have PIA's openvpn certificates and OpenVPN files situated in appdata/binhex-delugevpn/openvpn/ but am still getting the error.

 

If I turn off VPN in the template, deluge opens fine. Stop the container, select use VPN and the error re-appears. So I have something wrong with the VPN side but cant work out what it is.

 

I have checked my install against gridrunner's YT video of 27 Sep 17 and my template seems correct.

 

Any advice?

 

 

Nobody can help you without a log, please follow this procedure: https://forums.unraid.net/topic/44108-support-binhex-general/?do=findComment&comment=435831

 

Link to comment
7 minutes ago, Chad Kunsman said:

Hello, what's the best way to validate that the ports (incoming and outgoing) are all set up correctly and everything is working okay? I am getting upload speeds lower than I would expect and am not sure how to validate the ports are good end to end. 

 

Which provider do you use?

 

Also, From the FAQ:

 

Quote

Q10. How can i confirm that my incoming port is working when the VPN tunnel is established?

 

A10. To do this you can use the website https://www.yougetsignal.com/tools/open-ports/ this allows you to put in your public IP address for your VPN connection (can be found in the /config/supervisord.log) and the incoming port that you have manually configured (or in the case of PIA auto configured) for the application. Once you have entered in these details hit the "check" button to confirm the port is open.

 

Link to comment
1 hour ago, neuk34 said:

Hello,

I followed VPN Docker FAQ but I'm still experiencing slow downloads.

I subscribed to PIA, using port forwarding endpoint (France), port are opened, using reiserfs filesystem, Rate limit IP overhead is unticked.

Could you please help me to find the reason?

Thanks

supervisord.log

 

If you read the FAQ you should have seen that you need to redact your vpn user/pass from the log. The first thing you need to do is change your password asap.

Also in the FAQ (somewhere), you should've seen that in order to get the optimal speed you should reduce your upload speed, have you done that? You need to limit it to about 80%  of what your connection can handle. 

 

And you have followed the rest of the FAQ, specifically Q6 here: https://forums.unraid.net/topic/44108-support-binhex-general/?do=findComment&comment=433613

 

 

 

In addition to that here's another tip:

 

Quote

your ISP might be throttling your vpn connection. Try different ports and protocol if your vpn provider supports it. It's been a couple years since I tried PIA but at least then they supported connection over different ports and protocols, don't know if that has changed. I remember when I was using PIA, the only way I could get decent speed was when I was connecting over TCP port 53 and maybe 443. All UDP ports were throttled by my ISP. I know where I live ISP's are commonly throttling UDP VPN connections. I've had this issue with several ISP's and VPN providers. But switching port/protocol usually does the trick. 

 

Link to comment

Hi @binhex, using the DelugeVPN docker with wlvpn (the free VPN of NewsHosting account), but I got a new Windscribe account (Pro version Lifetime deal).   Windscribe now support "Port Forwarding".  I would like to know if I can use this with DelugeVPN docker?  Do I only need what is the Port Number that i'm assigned by Windscribe and add it as a Variable of the docker page of DelugeVPN ?  Thanks!

Link to comment
22 hours ago, Pducharme said:

Hi @binhex, using the DelugeVPN docker with wlvpn (the free VPN of NewsHosting account), but I got a new Windscribe account (Pro version Lifetime deal).   Windscribe now support "Port Forwarding".  I would like to know if I can use this with DelugeVPN docker?  Do I only need what is the Port Number that i'm assigned by Windscribe and add it as a Variable of the docker page of DelugeVPN ?  Thanks!

as long as windscribe supports openvpn clients then yep it should work just fine, just download the openvpn config file(s) and certs, put them in /config/openvpn and then set the vpn username and password credentials via the env vars. as far as port forwarding goes, if windscribe allocate you a static port them you simply go to deluge and set the port through the deluge web ui and you are done.

Link to comment

[Update: issue resolved via this FAQ entry:

 

Q13. I can see from the '/config/supervisord.log' file that the openvpn process keeps getting killed every 30 seconds on my QNAP appliance, what could be the cause of this?

 

A13. For some reason (unknown at this time) QNAP decided to kill any openvpn process running on the host by adding in a line to the 'daemon_mgr.conf' file. In order to prevent this you need to delete the following line from the 'daemon_mgr.conf':-

 

DAEMONxx = openvpn, stop, /usr/sbin/openvpn

Where xx will be 2 random digits.

 

Additional note: found instructions on how to use WinSCP to edit the daemon_mgr.conf file on QNAP here: https://forum.qnap.com/viewtopic.php?t=117004#p519883

 

end update.]

 

 

Hi, been working through setting up DelugeVPN in a Docker container on QNAP. Have it basically working, but get occasional errors. Using this script:

docker run  \

    --cap-add=NET_ADMIN \

    -p 8112:8112 \

    -p 8118:8118 \

    -p 58846:58846 \

    -p 58946:58946 \

    --name=delugevpn \

    -v /share/CACHEDEV1_DATA/appdata/delugevpn/data:/data \

    -v /share/CACHEDEV1_DATA/appdata/delugevpn/config:/config \

    -v /etc/localtime:/etc/localtime:ro \

    -e VPN_USER=[removed] \

    -e VPN_PASS=[rempved]  \

    -e VPN_PROV=torguard \

    -e STRICT_PORT_FORWARD=yes \

    -e ENABLE_PRIVOXY=yes \

    -e LAN_NETWORK=192.168.1.0/24 \

    -e NAME_SERVERS=209.222.18.222,37.235.1.174,1.1.1.1,8.8.8.8,209.222.18.218,37.235.1.177,1.0.0.1,8.8.4.4 \

    -e DELUGE_DAEMON_LOG_LEVEL=info \

    -e DELUGE_WEB_LOG_LEVEL=info \

    -e DEBUG=false \

    -e UMASK=000 \

    -e PUID=0 \

    -e PGID=0 \

    binhex/arch-delugevpn

I seem to get it running, and it does connect through VPN and show the right VPN external IP address. However, I regularly see this error:

2019-01-29 11:09:20,815 DEBG 'start-script' stdout output:
Tue Jan 29 11:09:20 2019 ERROR: Linux route add command failed: external program exited with error status: 2

Is this something of concern?

Possibly related, when I go to the Privoxy port (8118), a web page loads but I only see this error message: "Invalid header received from client."

 

Appreciate any feedback or assistance, with thanks!

Edited by Dublindog
Solved problem.
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.