Jump to content
binhex

[Support] binhex - DelugeVPN

3908 posts in this topic Last Reply

Recommended Posts

Hi,

I just installed this great docker for the 1st time.

My "container Path: /data" is /mnt/user/downloads/. This share is created in a single disk (disk9) of the array.

I downloaded a torrent file and left it sharing. I observed disk9 is up, but also parity and disk1 is up all the time. Just wanted to ask what disks will spin up while sharing a torrent?

Thx in advance.

Rgds

PS: I have no vpn set up.

 

Share this post


Link to post

Hi,

I just installed this great docker for the 1st time.

My "container Path: /data" is /mnt/user/downloads/. This share is created in a single disk (disk9) of the array.

I downloaded a torrent file and left it sharing. I observed disk9 is up, but also parity and disk1 is up all the time. Just wanted to ask what disks will spin up while sharing a torrent?

Thx in advance.

Rgds

PS: I have no vpn set up.

 

when seeding it will be any disk that contains the completed download, and any disk that contains the configuration files for delugevpn, thus the recommendation to use a cache drive and store configuration and incomplete/complete downloads on there and NOT to write to the array, then use unraid mover script or the metadata downloader to move the files to the array.

Share this post


Link to post

Yeah I'm using Notepad++ and just double checked: the file is Unix (LF).  ;)

I also tried to save it with vim via a ssh.

Here's the ovpn file by the way:

 

verb 4

client

tls-client

script-security 2

remote-cert-tls server

# Disabled, as we pass this value via env var

;dev tun

nobind

persist-key

comp-lzo yes

 

# Disabled, as we pass this value via env var

;remote **********vpn.net 1196 udp

 

auth-user-pass credentials.conf

 

redirect-gateway def1

#up /etc/openvpn/update-resolv-conf

#down /etc/openvpn/update-resolv-conf

 

<ca>

-----BEGIN CERTIFICATE-----

***

-----END CERTIFICATE-----

</ca>

 

im kinda lost as to what to try next, i guess one thing we should try is to completely delete the container AND image and re-pull from scratch, you can leave your configuration in place, just to ensure you are pulling the latest down.

Share this post


Link to post

I already did that and just tried once more. I'm still unable to access deluge UI.  :(

 

Don't know if that's related, but when I download the ovpn file from my provider, I have to comment these lines:

up /etc/openvpn/update-resolv-conf

down /etc/openvpn/update-resolv-conf

 

Otherwise I get this error:

 

[info] Starting OpenVPN...

 

2017-01-30 18:07:29,035 DEBG 'start-script' stdout output:

Options error: --up script fails with '/etc/openvpn/update-resolv-conf': No such file or directory

Options error: Please correct this error.

 

But this modification was working prior to today's update, so I don't think that's the issue.

 

My provider uses the same method.  They include update-resolv script is in the same tarball as all the ovpn files.  Here is mine

 

#!/bin/bash
#
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
#
# Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk>
# and Chris Hanson
# Licensed under the GNU GPL.  See /usr/share/common-licenses/GPL.
# 07/2013 colin@daedrum.net Fixed intet name
# 05/2006 chlauber@bnc.ch
#
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
# foreign_option_4='dhcp-option DOMAIN-SEARCH bnc.local'

## You might need to set the path manually here, i.e.
RESOLVCONF=$(which resolvconf)

case $script_type in

up)
  for optionname in ${!foreign_option_*} ; do
    option="${!optionname}"
    echo $option
    part1=$(echo "$option" | cut -d " " -f 1)
    if [ "$part1" == "dhcp-option" ] ; then
      part2=$(echo "$option" | cut -d " " -f 2)
      part3=$(echo "$option" | cut -d " " -f 3)
      if [ "$part2" == "DNS" ] ; then
        IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
      fi
      if [[ "$part2" == "DOMAIN" || "$part2" == "DOMAIN-SEARCH" ]] ; then
        IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"
      fi
    fi
  done
  R=""
  if [ "$IF_DNS_SEARCH" ]; then
    R="search "
    for DS in $IF_DNS_SEARCH ; do
      R="${R} $DS"
    done
  R="${R}
"
  fi

  for NS in $IF_DNS_NAMESERVERS ; do
    R="${R}nameserver $NS
"
  done
  #echo -n "$R" | $RESOLVCONF -x -p -a "${dev}"
  echo -n "$R" | $RESOLVCONF -a "${dev}.inet"
  ;;
down)
  $RESOLVCONF -d "${dev}.inet"
  ;;
esac

# Workaround / jm@epiclabs.io 
# force exit with no errors. Due to an apparent conflict with the Network Manager
# $RESOLVCONF sometimes exits with error code 6 even though it has performed the
# action correctly and OpenVPN shuts down.
exit 0

 

Share this post


Link to post

To debug my last problem, I ran the openvpn manually mith the same parameters as the delugeVPN init script to see the details of the error message like so:

 

docker exec -it binhex-delugevpn bash

/usr/bin/openvpn --cd /config/openvpn --config XXX.ovpn --dev tap0 --remote XXX.XXX.com 1194 --proto tcp --reneg-sec 0 --mute-replay-warnings --auth-nocache --keepalive 10 60

 

Share this post


Link to post

Yeah I'm using Notepad++ and just double checked: the file is Unix (LF).  ;)

I also tried to save it with vim via a ssh.

Here's the ovpn file by the way:

 

verb 4

client

tls-client

script-security 2

remote-cert-tls server

# Disabled, as we pass this value via env var

;dev tun

nobind

persist-key

comp-lzo yes

 

# Disabled, as we pass this value via env var

;remote **********vpn.net 1196 udp

 

auth-user-pass credentials.conf

 

redirect-gateway def1

#up /etc/openvpn/update-resolv-conf

#down /etc/openvpn/update-resolv-conf

 

<ca>

-----BEGIN CERTIFICATE-----

***

-----END CERTIFICATE-----

</ca>

 

im kinda lost as to what to try next, i guess one thing we should try is to completely delete the container AND image and re-pull from scratch, you can leave your configuration in place, just to ensure you are pulling the latest down.

 

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

 

Share this post


Link to post

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

Share this post


Link to post

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 :-)

Share this post


Link to post

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

Share this post


Link to post

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

supervisord.txt

Share this post


Link to post

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

 

 

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

 

 

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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!

 

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now