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
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.