[Support] binhex - DelugeVPN


Recommended Posts

Got a serious issue with fragmentation of IPv4 packets using traffic over PIA.

I got 100/100 and when i get around 3MB/s, my cisco router goes to 100% CPU usage due to fragmentation of packets.

Verified the fragmentation with Netdata on the server itself, on 500kb/s i get well over 1000 fragmentet packets/s

Tried setting the MTU in unraid as low as 1300, but no help in that.

 

Found a solution to this on this site: http://stackoverflow.com/questions/36306243/what-is-difference-between-mtu-and-fragment-option-in-openvpn2-0-configuration

Links to OpenVPN Manual, and there i find something interesting

--fragment max

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).

 

--fragment adds 4 bytes of overhead per datagram.

 

See the --mssfix option below for an important related option to --fragment.

 

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

 

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

 

--mssfix max

Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

 

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

 

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

 

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

 

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

 

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

 

--tun-mtu 1500 --fragment 1300 --mssfix

 

Is there a possibility to get these options for easy tinkering and testing?

Tried to manually edit the .ovpn file, but as an unraid/docker-noobie, i could not seem to get it to work, ovpn file gets overwritten all the time

Link to comment

Got a serious issue with fragmentation of IPv4 packets using traffic over PIA.

I got 100/100 and when i get around 3MB/s, my cisco router goes to 100% CPU usage due to fragmentation of packets.

Verified the fragmentation with Netdata on the server itself, on 500kb/s i get well over 1000 fragmentet packets/s

Tried setting the MTU in unraid as low as 1300, but no help in that.

 

Found a solution to this on this site: http://stackoverflow.com/questions/36306243/what-is-difference-between-mtu-and-fragment-option-in-openvpn2-0-configuration

Links to OpenVPN Manual, and there i find something interesting

--fragment max

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).

 

--fragment adds 4 bytes of overhead per datagram.

 

See the --mssfix option below for an important related option to --fragment.

 

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

 

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

 

--mssfix max

Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

 

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

 

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

 

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

 

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

 

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

 

--tun-mtu 1500 --fragment 1300 --mssfix

 

Is there a possibility to get these options for easy tinkering and testing?

Tried to manually edit the .ovpn file, but as an unraid/docker-noobie, i could not seem to get it to work, ovpn file gets overwritten all the time

 

at the moment, no there is no facility to add in additional command line options, however i could code this in in the future to allow this as an env var. for now if you want to have a play you will have to docker exec in and then modify the script /root/openvpn.sh, e.g.:-

 

docker exec -it <name of container> /bin/bash
nano /root/openvpn.sh

 

then add the additional command line optons you want to the variable defined as "openvpn_cli", link to source code (line 4):- https://github.com/binhex/arch-openvpn/blob/master/apps/root/openvpn.sh

Link to comment

one thing to try, can you try removing these two lines from your ovpn file:-

 

script-security 2
redirect-gateway def1

 

save and restart the container.

 

Okay so this morning I deleted everything and started from scratch. Pulled the latest version but I'm still unable to connect.

 

However, I deleted everything once more and force pulled an older version of your repo, v1.3.13-31. And voila, deluge is back up with the exact same ovpn and template configurations.

 

For now I'm good if I don't update, but I don't like the idea of not updating my server services, especially when it comes to security stuff like a VPN.

 

I'm gonna dig into redirect-gateway and script-security later today, but I'm starting to wonder if the changes you made since 1.3.13-32 might crumple a bit my VPN provider.  :-\

Do you remember if one of your modifications over the last updates could lead into client/server disagreement?

 

Thanks

Link to comment

I'm gonna dig into redirect-gateway and script-security later today, but I'm starting to wonder if the changes you made since 1.3.13-32 might crumple a bit my VPN provider.  :-\

Do you remember if one of your modifications over the last updates could lead into client/server disagreement?

 

Thanks

 

hmm no not really, i have a theory its around the way the openvpn command line is constructed as this was slightly altered in the latest build, possibly one or more of your env variables is causing an issue with the latest build, i have put in some additional logging and just built a new image with the tag "test", please can you give this a go, make sure to set debug to true, just to be clear i do expect this to not work but it will log out the command its attempting to run at least, the output im interested in will start with ""OpenVPN command line" please post it here.

 

Link to comment

Got a serious issue with fragmentation of IPv4 packets using traffic over PIA.

I got 100/100 and when i get around 3MB/s, my cisco router goes to 100% CPU usage due to fragmentation of packets.

Verified the fragmentation with Netdata on the server itself, on 500kb/s i get well over 1000 fragmentet packets/s

Tried setting the MTU in unraid as low as 1300, but no help in that.

 

Found a solution to this on this site: http://stackoverflow.com/questions/36306243/what-is-difference-between-mtu-and-fragment-option-in-openvpn2-0-configuration

Links to OpenVPN Manual, and there i find something interesting

--fragment max

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).

 

--fragment adds 4 bytes of overhead per datagram.

 

See the --mssfix option below for an important related option to --fragment.

 

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

 

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

 

--mssfix max

Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

 

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

 

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

 

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

 

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

 

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

 

--tun-mtu 1500 --fragment 1300 --mssfix

 

Is there a possibility to get these options for easy tinkering and testing?

Tried to manually edit the .ovpn file, but as an unraid/docker-noobie, i could not seem to get it to work, ovpn file gets overwritten all the time

 

at the moment, no there is no facility to add in additional command line options, however i could code this in in the future to allow this as an env var. for now if you want to have a play you will have to docker exec in and then modify the script /root/openvpn.sh, e.g.:-

 

docker exec -it <name of container> /bin/bash
nano /root/openvpn.sh

 

then add the additional command line optons you want to the variable defined as "openvpn_cli", link to source code (line 4):- https://github.com/binhex/arch-openvpn/blob/master/apps/root/openvpn.sh

 

Thank you!

trying out some things now, but due to different reasons not getting high speeds..

 

My total openvpn command is now

/usr/bin/openvpn --cd /config/openvpn --config openvpn.ovpn --daemon --auth-user-pass credentials.conf --disable-occ --dev tun0 --remote nl.privateinternetaccess.com 1198 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --tun-mtu 1500 --fragment 1300 --mssfix

Fragmentation on 3MB/s went from 4-5k fragments/sec to measly 130 frag/s

Router CPU usage went from 60-70% to 40-45%

 

Huge improvement, gotta look into what happens on the router now. Atleast majority of the fragmentation on client side is gone. Hopefully much better on router as well, gotta get a hold of my cisco bud :P

 

Edit:

Spoke to soon...

6MB/s down, 62 open connections over 5 torrents

75% CPU usage on router

2k frag/s on client

Openvpn showing 20-30% cpu usage in the docker container (readout from top command)

 

It did the above for 10 mins, then dropped to what i reported before the edit... while having 6MB/s download..

 

It can fragment til the server goes sluggy, as long as it doesn't make my router get down on it's knees

Link to comment

Got a serious issue with fragmentation of IPv4 packets using traffic over PIA.

I got 100/100 and when i get around 3MB/s, my cisco router goes to 100% CPU usage due to fragmentation of packets.

Verified the fragmentation with Netdata on the server itself, on 500kb/s i get well over 1000 fragmentet packets/s

Tried setting the MTU in unraid as low as 1300, but no help in that.

 

Found a solution to this on this site: http://stackoverflow.com/questions/36306243/what-is-difference-between-mtu-and-fragment-option-in-openvpn2-0-configuration

Links to OpenVPN Manual, and there i find something interesting

--fragment max

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).

 

--fragment adds 4 bytes of overhead per datagram.

 

See the --mssfix option below for an important related option to --fragment.

 

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

 

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

 

--mssfix max

Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

 

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

 

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

 

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

 

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

 

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

 

--tun-mtu 1500 --fragment 1300 --mssfix

 

Is there a possibility to get these options for easy tinkering and testing?

Tried to manually edit the .ovpn file, but as an unraid/docker-noobie, i could not seem to get it to work, ovpn file gets overwritten all the time

 

at the moment, no there is no facility to add in additional command line options, however i could code this in in the future to allow this as an env var. for now if you want to have a play you will have to docker exec in and then modify the script /root/openvpn.sh, e.g.:-

 

docker exec -it <name of container> /bin/bash
nano /root/openvpn.sh

 

then add the additional command line optons you want to the variable defined as "openvpn_cli", link to source code (line 4):- https://github.com/binhex/arch-openvpn/blob/master/apps/root/openvpn.sh

 

Thank you!

trying out some things now, but due to different reasons not getting high speeds..

 

My total openvpn command is now

/usr/bin/openvpn --cd /config/openvpn --config openvpn.ovpn --daemon --auth-user-pass credentials.conf --disable-occ --dev tun0 --remote nl.privateinternetaccess.com 1198 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --tun-mtu 1500 --fragment 1300 --mssfix

Fragmentation on 3MB/s went from 4-5k fragments/sec to measly 130 frag/s

Router CPU usage went from 60-70% to 40-45%

 

Huge improvement, gotta look into what happens on the router now. Atleast majority of the fragmentation on client side is gone. Hopefully much better on router as well, gotta get a hold of my cisco bud :P

 

im curious, there must be some side effects to this right?, it sounds too good to be true to reduce cpu load whilst maintaining the same dl/ul rate :-)

Link to comment

Got a serious issue with fragmentation of IPv4 packets using traffic over PIA.

I got 100/100 and when i get around 3MB/s, my cisco router goes to 100% CPU usage due to fragmentation of packets.

Verified the fragmentation with Netdata on the server itself, on 500kb/s i get well over 1000 fragmentet packets/s

Tried setting the MTU in unraid as low as 1300, but no help in that.

 

Found a solution to this on this site: http://stackoverflow.com/questions/36306243/what-is-difference-between-mtu-and-fragment-option-in-openvpn2-0-configuration

Links to OpenVPN Manual, and there i find something interesting

--fragment max

Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).

 

--fragment adds 4 bytes of overhead per datagram.

 

See the --mssfix option below for an important related option to --fragment.

 

It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.

 

Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.

 

--mssfix max

Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself.

 

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

 

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

 

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

 

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

 

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

 

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

 

--tun-mtu 1500 --fragment 1300 --mssfix

 

Is there a possibility to get these options for easy tinkering and testing?

Tried to manually edit the .ovpn file, but as an unraid/docker-noobie, i could not seem to get it to work, ovpn file gets overwritten all the time

 

at the moment, no there is no facility to add in additional command line options, however i could code this in in the future to allow this as an env var. for now if you want to have a play you will have to docker exec in and then modify the script /root/openvpn.sh, e.g.:-

 

docker exec -it <name of container> /bin/bash
nano /root/openvpn.sh

 

then add the additional command line optons you want to the variable defined as "openvpn_cli", link to source code (line 4):- https://github.com/binhex/arch-openvpn/blob/master/apps/root/openvpn.sh

 

Thank you!

trying out some things now, but due to different reasons not getting high speeds..

 

My total openvpn command is now

/usr/bin/openvpn --cd /config/openvpn --config openvpn.ovpn --daemon --auth-user-pass credentials.conf --disable-occ --dev tun0 --remote nl.privateinternetaccess.com 1198 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --tun-mtu 1500 --fragment 1300 --mssfix

Fragmentation on 3MB/s went from 4-5k fragments/sec to measly 130 frag/s

Router CPU usage went from 60-70% to 40-45%

 

Huge improvement, gotta look into what happens on the router now. Atleast majority of the fragmentation on client side is gone. Hopefully much better on router as well, gotta get a hold of my cisco bud :P

 

im curious, there must be some side effects to this right?, it sounds too good to be true to reduce cpu load whilst maintaining the same dl/ul rate :-)

 

New tests... Not sure if this is worth anything to you, but nice to have the data logged anyho.

/usr/bin/openvpn --cd /config/openvpn --config openvpn.ovpn --daemon --auth-user-pass credentials.conf --disable-occ --dev tun0 --remote nl.privateinternetaccess.com 1198 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --mssfix 1200

This was a bust.. 90% on the router with 3MB/s only.. even putty started to get sluggish

 

/usr/bin/openvpn --cd /config/openvpn --config openvpn.ovpn --daemon --auth-user-pass credentials.conf --disable-occ --dev tun0 --remote nl.privateinternetaccess.com 1198 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --tun-mtu 1200 --mssfix 1200

This fails to resolve tracker.... or, seems like it, not sure what to make of it.

 

/usr/bin/openvpn --cd /config/openvpn --config openvpn.ovpn --daemon --auth-user-pass credentials.conf --disable-occ --dev tun0 --remote nl.privateinternetaccess.com 1198 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --tun-mtu 1300 --mssfix 1200

@ 5MB/s, gives 50% on router, max reported frag/s = 7... YAY!

@ 8MB/s, 65-75% on router, max frag/s = same low 7. On to something :)

 

According to https://openvpn.net/index.php/open-source/faq/77-server/271-i-can-ping-through-the-tunnel-but-any-real-work-causes-it-to-lock-up-is-this-an-mtu-problem.html

Fragment setting should be used on both client and server side. so skipped that one out.

 

Just a matter of tweaking tun-mtu and finding a mssfix that fits well, and the fragmentation on client-side is history at least.

Will report back on the router-bit later!

 

Edit:

Spoke to the Cisco expert, and my load was perfectly normal on that kind of traffic, and tweaking the MTU more would not make a noticeable difference in speed.

As long as fragmentation is at a minimum, everything is fine.

Also tested out "--mtu-disc yes" but that was not supported by PIA and/or gave tons of fragmentation.

 

So, i ended up with --tun-mtu 1300 --mssfix 1200, and it's working like a charm.

Would be very nice to get those values modifyable in docker for easy access later on :)

 

Attached a pic of what netdata shows me.

It looks like it just drops to 0 at the end, with no traffic, but in reality it's the same speed all the way, first without fix, the end with fix (less than 10 frag/s)

 

And on the topic of side effects, afaik there should be none. This takes hand of the fragmentation i was experiencing, and it was that exact fragmentation that my router was not happy about.

MTU size should have negligeable performance impact. Reducing packetsize would result in more packets being sent, and adding a slight load. But then again, removing fragmentation frees up a ton as well.

 

Edit 2: https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/

Nice explanation of what is happening inthe packet, and why it fragments so much.

frag.png.a99da8b0785adcd64c8ed924878efb7d.png

Link to comment

I couldn't log in so I decided a good time to reinstall.  But, I now can't connect with CP, sonarr etc - is this because the webui setting in deluge won't stay ticked?

 

 

There were also two new docker settings that I left alone (VPN_OPTIONS and NAME_SERVERS) - was this correct?

 

 

Thanks in advance for any help

Firstly that log isn't for delugevpn that's a log from rtorrentvpn, secondly your haven't specified the VPN username and password. If your still having issues after correcting this then please post in the rtorrentvpn thread with an updated supervisord.log file

 

Sent from my SM-G900F using Tapatalk

 

 

Link to comment

I couldn't log in so I decided a good time to reinstall.  But, I now can't connect with CP, sonarr etc - is this because the webui setting in deluge won't stay ticked?

 

 

There were also two new docker settings that I left alone (VPN_OPTIONS and NAME_SERVERS) - was this correct?

 

 

Thanks in advance for any help

Firstly that log isn't for delugevpn that's a log from rtorrentvpn, secondly your haven't specified the VPN username and password. If your still having issues after correcting this then please post in the rtorrentvpn thread with an updated supervisord.log file

 

Sent from my SM-G900F using Tapatalk

 

 

Huh??? That's definitely the deluge file.  I deleted the VPN password so I could post

Link to comment

hmm no not really, i have a theory its around the way the openvpn command line is constructed as this was slightly altered in the latest build, possibly one or more of your env variables is causing an issue with the latest build, i have put in some additional logging and just built a new image with the tag "test", please can you give this a go, make sure to set debug to true, just to be clear i do expect this to not work but it will log out the command its attempting to run at least, the output im interested in will start with ""OpenVPN command line" please post it here.

 

Here's the output:

2017-01-31 22:29:50,145 DEBG 'start-script' stdout output:

OpenVPN command line '/usr/bin/openvpn --cd /config/openvpn --config /config/openvpn/config.ovpn --daemon --dev tun0 --remote ***.net 1196 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --auth-user-pass credentials.conf'

[info] Starting OpenVPN...

 

2017-01-31 22:29:50,168 DEBG 'start-script' stdout output:

[info] OpenVPN started

 

2017-01-31 22:29:50,169 DEBG 'start-script' stdout output:

[info] Waiting for valid IP address from tunnel...

 

Disabling script-security and redirect-gateway didn't help by the way.

Link to comment

I couldn't log in so I decided a good time to reinstall.  But, I now can't connect with CP, sonarr etc - is this because the webui setting in deluge won't stay ticked?

 

 

There were also two new docker settings that I left alone (VPN_OPTIONS and NAME_SERVERS) - was this correct?

 

 

Thanks in advance for any help

Firstly that log isn't for delugevpn that's a log from rtorrentvpn, secondly your haven't specified the VPN username and password. If your still having issues after correcting this then please post in the rtorrentvpn thread with an updated supervisord.log file

 

Sent from my SM-G900F using Tapatalk

 

 

Huh??? That's definitely the deluge file.  I deleted the VPN password so I could post

 

sorry my bad, ive been diagnosing a lot of stuff as of late and was doing this via smartphone and somehow got hold of the wrong log :-). in any case your issue is that something on your network is attempting to authenticate with deluge and failing, im assuming you can see the deluge webui yes?, you just having issues with cp, sickrage etc connecting yes?

 

[ERROR   ] 20:52:48 auth:329 Login failed (ClientIP 172.17.0.1)

 

its most probably due to the fact that you have reset your config and thus changed the authentication back to defaults. hae a look here http://lime-technology.com/forum/index.php?topic=45811.msg437674#msg437674 at the delugevpn FAQ Q1. for how to configure CP for use with deluge, particularly the section regards editing the auth file.

 

 

Link to comment

hmm no not really, i have a theory its around the way the openvpn command line is constructed as this was slightly altered in the latest build, possibly one or more of your env variables is causing an issue with the latest build, i have put in some additional logging and just built a new image with the tag "test", please can you give this a go, make sure to set debug to true, just to be clear i do expect this to not work but it will log out the command its attempting to run at least, the output im interested in will start with ""OpenVPN command line" please post it here.

 

Here's the output:

2017-01-31 22:29:50,145 DEBG 'start-script' stdout output:

OpenVPN command line '/usr/bin/openvpn --cd /config/openvpn --config /config/openvpn/config.ovpn --daemon --dev tun0 --remote ***.net 1196 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --auth-user-pass credentials.conf'

[info] Starting OpenVPN...

 

2017-01-31 22:29:50,168 DEBG 'start-script' stdout output:

[info] OpenVPN started

 

2017-01-31 22:29:50,169 DEBG 'start-script' stdout output:

[info] Waiting for valid IP address from tunnel...

 

Disabling script-security and redirect-gateway didn't help by the way.

 

ok only thing a liittle odd is the name of the ovpn file, so according to the command line the ovpn config file is located at /config/openvpn/config.ovpn is this now correct?, i saw earlier it had the name xxxxx-udp.ovpn.ovpn

Link to comment

I couldn't log in so I decided a good time to reinstall.  But, I now can't connect with CP, sonarr etc - is this because the webui setting in deluge won't stay ticked?

 

 

There were also two new docker settings that I left alone (VPN_OPTIONS and NAME_SERVERS) - was this correct?

 

 

Thanks in advance for any help

Firstly that log isn't for delugevpn that's a log from rtorrentvpn, secondly your haven't specified the VPN username and password. If your still having issues after correcting this then please post in the rtorrentvpn thread with an updated supervisord.log file

 

Sent from my SM-G900F using Tapatalk

 

 

Huh??? That's definitely the deluge file.  I deleted the VPN password so I could post

 

sorry my bad, ive been diagnosing a lot of stuff as of late and was doing this via smartphone and somehow got hold of the wrong log :-). in any case your issue is that something on your network is attempting to authenticate with deluge and failing, im assuming you can see the deluge webui yes?, you just having issues with cp, sickrage etc connecting yes?

 

[ERROR   ] 20:52:48 auth:329 Login failed (ClientIP 172.17.0.1)

 

its most probably due to the fact that you have reset your config and thus changed the authentication back to defaults. hae a look here http://lime-technology.com/forum/index.php?topic=45811.msg437674#msg437674 at the delugevpn FAQ Q1. for how to configure CP for use with deluge, particularly the section regards editing the auth file.

 

 

all sorted now - passwords were out of sync somehow

Link to comment

hmm no not really, i have a theory its around the way the openvpn command line is constructed as this was slightly altered in the latest build, possibly one or more of your env variables is causing an issue with the latest build, i have put in some additional logging and just built a new image with the tag "test", please can you give this a go, make sure to set debug to true, just to be clear i do expect this to not work but it will log out the command its attempting to run at least, the output im interested in will start with ""OpenVPN command line" please post it here.

 

Here's the output:

2017-01-31 22:29:50,145 DEBG 'start-script' stdout output:

OpenVPN command line '/usr/bin/openvpn --cd /config/openvpn --config /config/openvpn/config.ovpn --daemon --dev tun0 --remote ***.net 1196 --proto udp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60 --auth-user-pass credentials.conf'

[info] Starting OpenVPN...

 

2017-01-31 22:29:50,168 DEBG 'start-script' stdout output:

[info] OpenVPN started

 

2017-01-31 22:29:50,169 DEBG 'start-script' stdout output:

[info] Waiting for valid IP address from tunnel...

 

Disabling script-security and redirect-gateway didn't help by the way.

 

ok only thing a liittle odd is the name of the ovpn file, so according to the command line the ovpn config file is located at /config/openvpn/config.ovpn is this now correct?, i saw earlier it had the name xxxxx-udp.ovpn.ovpn

 

ok so taking Gog's idea, lets see if we get any more info when we attempt to run openvpn manually, so ssh into your unraid host and then execute the following:-

 

docker exec -it <name of container> bash

 

then copy and paste the earlier output you got for the constructed openvpn cli into this session, im hoping you get something out from this which might give us a clue as to what is going on.

Link to comment

I'm having issues connecting to the daemon from the GTK thin client. The daemon listens on port 37054.

 

I assume I can't connect from the outside (my local network or internet) because I have the container configured to route traffic through PIA VPN.

 

How can I connect to the daemon from "outside"? I need the GTK client to configure YARSS2.

 

Thanks!

 

Link to comment

ok so taking Gog's idea, lets see if we get any more info when we attempt to run openvpn manually, so ssh into your unraid host and then execute the following:-

 

docker exec -it <name of container> bash

 

then copy and paste the earlier output you got for the constructed openvpn cli into this session, im hoping you get something out from this which might give us a clue as to what is going on.

 

Alright I had to remove --deamon from the args in order to have the logs. We seems to have a fatal error indeed.

I might be wrong but it looks like there's an issue with tun0.

See attached log file.

outputlog.txt

Link to comment

ok so taking Gog's idea, lets see if we get any more info when we attempt to run openvpn manually, so ssh into your unraid host and then execute the following:-

 

docker exec -it <name of container> bash

 

then copy and paste the earlier output you got for the constructed openvpn cli into this session, im hoping you get something out from this which might give us a clue as to what is going on.

 

Alright I had to remove --deamon from the args in order to have the logs. We seems to have a fatal error indeed.

I might be wrong but it looks like there's an issue with tun0.

See attached log file.

 

ok so im not an openvpn pro, but looking at that log it looks like your vpn provider is forcing the vpn client to create an ipv6 address for the tunnel by pushing an option, problem is unraid currently doesnt support ipv6, thus the error.

 

so now onto the question as to why it doesnt happen with an earlier build of the docker image, this i can only assume is due to the fact that openvpn client has been upgraded and now supports ipv6, where previously it didn't, or perhaps did support ipv6 but silently ignored any request to push an ipv6 address to the client.

 

so assuming i am correct, then your options are as follows:-

 

1. stick with the older docker image (not ideal)

2. bug unraid to include ipv6 (something they should of done a long time ago, but unlikely to happen soon)

3. move over to a vpn provider that doesnt force ipv6 (such as PIA (recommended) or AirVPN)

 

the choice is yours :-)

 

EDIT - one last thing you can try is to add in the option "--disable-occ" and see if that makes a difference, this allows for inconsistencies between client and server, im not sure it will work, but worth a shot, let me know the outcome.

Link to comment

Is there a way to view the tracker status? I've always used uTorrent before moving to this docker container and it was easy to just scan through the list to see what torrents may have been deleted from the torrent server (so that I can stop seeding them).

 

The only way I've found in Deluge is to click each individual torrent and see if tracker status says "announce OK" or "failure unregistered torrent"

 

I like to seed my torrents for a long time, but usually the servers take down the torrent if a new version is uploaded.

Link to comment

I recently switched from the transmissionvpn docker to this delugevpn in hopes of getting a running torrent container. Sadly I have had no luck with either. I just do not understand why every container is broken now. I'd happily download an older build if I could figure that out.

 

Either way, I've attached a log. If someone can find something in there and help out I'd be grateful. Thanks.

supervisord.txt

Link to comment

I recently switched from the transmissionvpn docker to this delugevpn in hopes of getting a running torrent container. Sadly I have had no luck with either. I just do not understand why every container is broken now. I'd happily download an older build if I could figure that out.

 

Either way, I've attached a log. If someone can find something in there and help out I'd be grateful. Thanks.

OK firstly your in the wrong thread, this is for delugevpn not rtorrentvpn, so any replies in there please. So taking a look at your logs that is a successful start, there is nothing wrong there, are you attempting to connect to the webui from inside your lan yes? You would need to connect using http://<your unraid servers IP>:<host port mapped to 9080> I can assure you the VPN dockers I have authored are not "broken".

 

Sent from my SM-G900F using Tapatalk

 

Link to comment

I recently switched from the transmissionvpn docker to this delugevpn in hopes of getting a running torrent container. Sadly I have had no luck with either. I just do not understand why every container is broken now. I'd happily download an older build if I could figure that out.

 

Either way, I've attached a log. If someone can find something in there and help out I'd be grateful. Thanks.

OK firstly your in the wrong thread, this is for delugevpn not rtorrentvpn, so any replies in there please. So taking a look at your logs that is a successful start, there is nothing wrong there, are you attempting to connect to the webui from inside your lan yes? You would need to connect using http://<your unraid servers IP>:<host port mapped to 9080> I can assure you the VPN dockers I have authored are not "broken".

 

Sent from my SM-G900F using Tapatalk

 

Well I'm using the delugevpn so I figured I'd post in the delugevpn support thread. My mistake.

 

Anyway neither 9080 or 8112 work for the webui. 8112 being the port used in the webui shortcut.

 

edit: Starting it without the VPN enabled works. I can access the ui perfectly.

edit2: Got it working.

Link to comment

I used to have DelugeVPN working perfectly with my IPVanish vpn provider.  They recently changed something so I went and updated the certificate for my vpn provider and now my Deluge won't connect to any peers.  I can post the docker log or any other information to hep resolve the issue.

 

Thanks.

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.