Setting correct MTU

[dolphs]

Hi,

I am getting used to ovpn ( and VPN in general ) little by little.
Yet I am facing an MTU issue as I frequently experience slow VPN performance, but after rebooting one end ( usually client ) the performance usually is OK after 1-3 reboots.
My goal is to have a proper configuration, so I will have a stable ( read: fast ) connection by default without the need of rebooting.
One end ( server ) has MTU of 1500, while the client's MTU size is: 1492 . My first hunch is I should use parameters like : " link-mtu, tun-mtu, mssfix and maybe more ". Therefore seeking help from community, basically what to do when MTU size on both ends differs ?
As a side note openvpn 2.4.3 and 2.4.4 is used on debian stretch platforms ( client: regular PC and server: NanoPiNEO2 )


1/
I started checking my eth0 devices ( both server and client ) and both show: "2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000"


2/
Next I check both ends with " ping -M do -c 1 -s 1472 www.yahoo.com ".

The server side reports:

PING atsv2-fp.wg1.b.yahoo.com (188.125.80.145) 1472(1500) bytes of data.
1480 bytes from media-router-fp2.prod.media.vip.ir2.yahoo.com (188.125.80.145): icmp_seq=1 ttl=56 time=32.0 ms

--- atsv2-fp.wg1.b.yahoo.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 32.023/32.023/32.023/0.000 ms


While the client fails and says:

PING atsv2-fp.wg1.b.yahoo.com (188.125.80.145) 1472(1500) bytes of data.
From x.y.z.215 (x.y.z.215) icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- atsv2-fp.wg1.b.yahoo.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms


The client MTU seems to be 1492 instead of 1500 and following packet size, 1464, appears to be the maximum

ping -M do -c 1 -s 1464 www.yahoo.com
PING atsv2-fp.wg1.b.yahoo.com (188.125.80.145) 1464(1492) bytes of data.
1472 bytes from media-router-fp2.prod.media.vip.ir2.yahoo.com (188.125.80.145): icmp_seq=1 ttl=56 time=56.8 ms

--- atsv2-fp.wg1.b.yahoo.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 56.838/56.838/56.838/0.000 ms


3/
Currently " ip link show dev tun0 "shows an MTU of 1500 on both ends wich looks incorrect to me:
" 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 "


4/
server.conf shows

log /var/log/openvpn.log
verb 4

status /var/log/openvpn-status.log 30

dev tun
local 192.168.10.11
proto udp4
port 1194
persist-key
persist-tun
keepalive 10 120
txqueuelen 1000

server 10.8.0.0 255.255.255.0
topology subnet

route 192.168.20.0 255.255.255.0
push "route 192.168.10.0 255.255.255.0"
push "dhcp-option DNS 192.168.10.10"

script-security 2
up /etc/openvpn/script/up.sh
down /etc/openvpn/script/down.sh

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

float
comp-lzo no #No need for streaming
fast-io #Optimize I/O writes

tls-version-min 1.2
remote-cert-tls client
tls-auth /etc/openvpn/key/ta.key 0
cipher AES-128-CBC # Nano Pi NEO2
ncp-disable
auth SHA256

client-config-dir /etc/openvpn/ccd
ca /etc/openvpn/key/pivpn01_CA.crt #ca cert
cert /etc/openvpn/key/pivpn01_SRV.crt
key /etc/openvpn/key/pivpn01_SRV.pem
dh /etc/openvpn/key/dh2048.pem




5/ client.conf

log /var/log/openvpn.log
verb 4

client
dev tun
proto udp4
remote someaddress.dynu.net someport
resolv-retry infinite
nobind
persist-key
persist-tun
keepalive 10 120
txqueuelen 1000

script-security 2
up /etc/openvpn/script/up.sh
down /etc/openvpn/script/down.sh

explicit-exit-notify 2
float
comp-lzo no
fast-io

tls-version-min 1.2
remote-cert-tls server
verify-x509-name pivpn01_SRV name
cipher AES-128-CBC
auth SHA256

ca /etc/openvpn/key/pivpn01_CA.crt
cert /etc/openvpn/key/npi2-02.crt
key /etc/openvpn/key/npi2-02.pem
dh /etc/openvpn/key/ta.key 1

[Pippin]

Can you try

Code: Select all

fragment 1400
mssfix 1400

server side, and

Code: Select all

mssfix 1400

client side?

Also see --mtu-test in manual.

[TinCanTech]

I am facing an MTU issue as I frequently experience slow VPN performance, but after rebooting one end ( usually client ) the performance usually is OK after 1-3 reboots.

This does not sound like MTU problem to me ..

Please post your sanitized logs at verb 4
wait for the speed to deteriorate and see if there are any errors in the logs.

[dolphs]

thank you both.
Seems adding " fragment 1400 " screws up my connection totally erroring with:

Code: Select all

Mon Oct 16 19:39:04 2017 us=929296 npineo2/x.y.z.146:41714 Bad compression stub decompression header byte: 52
Mon Oct 16 19:39:06 2017 us=76204 npineo2/x.y.z.146:41714 Bad compression stub decompression header byte: 0
Mon Oct 16 19:39:16 2017 us=284560 npineo2/x.y.z.146:41714 FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented

Removing this option but adding in on server.conf:

Code: Select all

tun-mtu 1500
mssfix 1400

and client.conf

Code: Select all

tun-mtu 1492
mssfix 1400

results in a "stable" connection between both remarkably, meaning streaming works like a charm now - though I need to verify this coming days.
Also need to verify speed on both ends meaning up/download.


The server does throw following warnings/errors:

Code: Select all

Mon Oct 16 19:45:28 2017 us=869299 Initialization Sequence Completed
Mon Oct 16 19:47:04 2017 us=255197 MULTI: multi_create_instance called
Mon Oct 16 19:47:04 2017 us=255396 x.y.z.146:59931 Re-using SSL/TLS context
Mon Oct 16 19:47:04 2017 us=255775 x.y.z.146:59931 Control Channel MTU parms [ L:1622 D:1172 EF:78 EB:0 ET:0 EL:3 ]
Mon Oct 16 19:47:04 2017 us=255824 x.y.z.146:59931 Data Channel MTU parms [ L:1622 D:1400 EF:122 EB:406 ET:0 EL:3 ]
Mon Oct 16 19:47:04 2017 us=255952 x.y.z.146:59931 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-128-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-server'
Mon Oct 16 19:47:04 2017 us=255987 x.y.z.146:59931 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-client'
Mon Oct 16 19:47:04 2017 us=256095 x.y.z.146:59931 TLS: Initial packet from [AF_INET]x.y.z.146:59931, sid=4e6838c5 b7bd2130
Mon Oct 16 19:47:04 2017 us=412210 x.y.z.146:59931 VERIFY OK: depth=1, C=US, ST=FL, L=OP, CN=pivpn01_CA, emailAddress=someone@gmail.com
Mon Oct 16 19:47:04 2017 us=413470 x.y.z.146:59931 VERIFY KU OK
<snip snip>
Mon Oct 16 19:47:04 2017 us=470826 x.y.z.146:59931 peer info: IV_TCPNL=1
Mon Oct 16 19:47:04 2017 us=470930 x.y.z.146:59931 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1562'
Mon Oct 16 19:47:04 2017 us=470982 x.y.z.146:59931 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1492'
<snip snip>

As well the client side

Code: Select all

Mon Oct 16 20:44:58 2017 us=229249 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Oct 16 20:44:58 2017 us=229410 Re-using SSL/TLS context
Mon Oct 16 20:44:58 2017 us=229511 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1492)
Mon Oct 16 20:44:58 2017 us=229831 Control Channel MTU parms [ L:1614 D:1172 EF:78 EB:0 ET:0 EL:3 ]
Mon Oct 16 20:44:58 2017 us=229951 Data Channel MTU parms [ L:1614 D:1400 EF:122 EB:405 ET:0 EL:3 ]
Mon Oct 16 20:44:58 2017 us=230150 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1562,tun-mtu 1492,proto UDPv4,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-client'
Mon Oct 16 20:44:58 2017 us=230230 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1562,tun-mtu 1492,proto UDPv4,comp-lzo,keydir 0,cipher AES-128-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-server'
Mon Oct 16 20:44:58 2017 us=230335 TCP/UDP: Preserving recently used remote address: [AF_INET]x.y.z.130:6002
Mon Oct 16 20:44:58 2017 us=230487 Socket Buffers: R=[212992->786432] S=[212992->786432]
Mon Oct 16 20:44:58 2017 us=230576 UDPv4 link local: (not bound)
Mon Oct 16 20:44:58 2017 us=230669 UDPv4 link remote: [AF_INET]x.y.z.130:6002
Mon Oct 16 20:44:58 2017 us=287758 TLS: Initial packet from [AF_INET]x.y.z.130:6002, sid=e5de7478 dcff357b
Mon Oct 16 20:44:58 2017 us=375589 VERIFY OK: depth=1, C=x, ST=y, L=z CN=pivpn01_CA, emailAddress=someone@gmail.com
Mon Oct 16 20:44:58 2017 us=377679 VERIFY KU OK
Mon Oct 16 20:44:58 2017 us=377803 Validating certificate extended key usage
Mon Oct 16 20:44:58 2017 us=377898 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Oct 16 20:44:58 2017 us=377977 VERIFY EKU OK
Mon Oct 16 20:44:58 2017 us=378052 VERIFY X509NAME OK: C=x ST=y L=z CN=pivpn01_SRV, emailAddress=someone@gmail.com
Mon Oct 16 20:44:58 2017 us=378126 VERIFY OK: depth=0, C=x ST=y L=z CN=pivpn01_SRV, emailAddress=someone@gmail.com
Mon Oct 16 20:44:58 2017 us=510427 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1562', remote='link-mtu 1574'
Mon Oct 16 20:44:58 2017 us=510599 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1492', remote='tun-mtu 1500'
Mon Oct 16 20:44:58 2017 us=511143 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Mon Oct 16 20:44:58 2017 us=511688 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mon Oct 16 20:44:58 2017 us=511887 [pivpn01_SRV] Peer Connection Initiated with [AF_INET]x.y.z.130:6002
Mon Oct 16 20:44:59 2017 us=619548 SENT CONTROL [pivpn01_SRV]: 'PUSH_REQUEST' (status=1)
Mon Oct 16 20:44:59 2017 us=674915 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,dhcp-option DNS 192.168.10.10,sndbuf 393216,rcvbuf 393216,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 1'
Mon Oct 16 20:44:59 2017 us=675463 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 16 20:44:59 2017 us=675552 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Mon Oct 16 20:44:59 2017 us=675649 Socket Buffers: R=[786432->786432] S=[786432->786432]
Mon Oct 16 20:44:59 2017 us=675726 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 16 20:44:59 2017 us=675796 OPTIONS IMPORT: route options modified
Mon Oct 16 20:44:59 2017 us=675867 OPTIONS IMPORT: route-related options modified
Mon Oct 16 20:44:59 2017 us=675936 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 16 20:44:59 2017 us=676005 OPTIONS IMPORT: peer-id set
Mon Oct 16 20:44:59 2017 us=676077 OPTIONS IMPORT: adjusting link_mtu to 1617
Mon Oct 16 20:44:59 2017 us=676204 Data Channel MTU parms [ L:1565 D:1400 EF:73 EB:405 ET:0 EL:3 ]
Mon Oct 16 20:44:59 2017 us=676930 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Oct 16 20:44:59 2017 us=677055 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Oct 16 20:44:59 2017 us=677150 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Oct 16 20:44:59 2017 us=677265 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Oct 16 20:44:59 2017 us=677360 Preserving previous TUN/TAP instance: tun0
Mon Oct 16 20:44:59 2017 us=677523 Initialization Sequence Completed

I am convincend more tuning/debugging is needed to get the logs clean.
Thanks both for your contribution!

[TinCanTech]

Seems adding " fragment 1400 " screws up my connection

See --mssfix & --fragment in The Manual v24x

Mon Oct 16 19:47:04 2017 us=470930 x.y.z.146:59931 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1562'
Mon Oct 16 19:47:04 2017 us=470982 x.y.z.146:59931 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1492'

All I can tell you about these is that the devs are aware that there are some inconsistencies calculating the various MTU settings and there was some considerable changes made between version 2.3 and 2.4 .. it is being looked into but it may be a while before anything changes.

Mon Oct 16 20:44:58 2017 us=511143 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'

This is quite odd because --mtu-dynamic has been replaced by --fragment .. if you specify it in a config you will get:

Code: Select all

Options error: --mtu-dynamic has been replaced by --fragment

and openvpn will terminate.

[dolphs]

OK, a new attempt executing a test between both ends

client.conf
- Removed mssfix from my and kept tun-mtu value as found in my first posts, thus:

Code: Select all

tun-mtu 1492

server.conf
- Removed fragment. mssfix and kept tun-mtu value as found in my first posts
- Added mtu-test - thus

Code: Select all

tun-mtu 1500
mtu-test

I ran these tests twice and similar answer came from the server logs:

Code: Select all

NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1569,1569] remote->local=[1556,1556]

This implies it is required to set " link-mtu " to " 1569 " on my server and " 1556 " on the client side or do I misinterprete and is the mssfix parameter the one to use ? Sorry I am still learning ...

[TinCanTech]

This implies it is required to set " link-mtu " to " 1569 " on my server and " 1556 " on the client side or do I misinterprete and is the mssfix parameter the one to use ?

These are similar to my network and I don't have any problems.

--link-mtu n

• Sets an upper bound on the size of UDP packets which are sent between OpenVPN peers. It's best not to set this parameter unless you know what you're doing.

--tun-mtu n

• Take the TUN device MTU to be n and derive the link MTU from it (default=1500). In most cases, you will probably want to leave this parameter set to its default value.
  
  The MTU (Maximum Transmission Units) is the maximum datagram size in bytes that can be sent unfragmented over a particular network path. OpenVPN requires that packets on the control or data channels be sent unfragmented.
  
  MTU problems often manifest themselves as connections which hang during periods of active usage.
  
  It's best to use the --fragment and/or --mssfix options to deal with MTU sizing issues.

I would use what the manual recommends.

[dolphs]

Hello, it has been a while since I have been updating this post as I am still struggling to overcome one issue - though meanwhile client and server run on openvpn2.4.5:

It seemed I found optimal values for my VPN traffic ( up- and download), however that is partly the case and only if I connect from VPN to VPN server. When I upload from my "server" to the client side I get approx. half of upload speed as expected.
This "slow speed" can be seen on both clients ( linuxdoos1 and linuxdoos2 ) which are at the "VPN-server" side.
The other way around ( clients on VPN-client ) I do get values as expected.


To illustrate "the faulty" side with iperf3 ( single connection ):

Ran following command 10 times in past hour with similar Bandwith results on VPN server to VPN client :

ovpn@ovpn01:~$ iperf3 -c 192.168.20.2
Connecting to host 192.168.20.2, port 5201
[ 4] local 10.8.0.1 port 53796 connected to 192.168.20.2 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 4.29 MBytes 36.0 Mbits/sec 290 328 KBytes
[ 4] 1.00-2.00 sec 3.10 MBytes 26.0 Mbits/sec 63 335 KBytes
[ 4] 2.00-3.00 sec 3.16 MBytes 26.5 Mbits/sec 100 328 KBytes
[ 4] 3.00-4.00 sec 3.16 MBytes 26.5 Mbits/sec 48 330 KBytes
[ 4] 4.00-5.00 sec 2.97 MBytes 25.0 Mbits/sec 31 328 KBytes
[ 4] 5.00-6.00 sec 3.16 MBytes 26.5 Mbits/sec 59 328 KBytes
[ 4] 6.00-7.00 sec 2.91 MBytes 24.4 Mbits/sec 45 328 KBytes
[ 4] 7.00-8.00 sec 3.10 MBytes 26.0 Mbits/sec 45 328 KBytes
[ 4] 8.00-9.00 sec 3.10 MBytes 26.0 Mbits/sec 93 328 KBytes
[ 4] 9.00-10.00 sec 3.10 MBytes 26.0 Mbits/sec 81 231 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 32.1 MBytes 26.9 Mbits/sec 855 sender
[ 4] 0.00-10.00 sec 29.7 MBytes 25.0 Mbits/sec receiver

iperf Done.


Ran following command 10 times in past hour with similar Bandwith results on client1 that uses VPN server to connect to the VPN client on other side. Here "poor" speed is encountered:

ovpn@linuxdoos1:~# iperf3 -c 192.168.20.2
Connecting to host 192.168.20.2, port 5201
[ 5] local 192.168.10.21 port 37997 connected to 192.168.20.2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.07 MBytes 8.98 Mbits/sec 4 67.0 KBytes
[ 5] 1.00-2.00 sec 1.09 MBytes 9.10 Mbits/sec 4 58.7 KBytes
[ 5] 2.00-3.00 sec 1002 KBytes 8.21 Mbits/sec 0 64.7 KBytes
[ 5] 3.00-4.00 sec 1005 KBytes 8.23 Mbits/sec 0 65.8 KBytes
[ 5] 4.00-5.00 sec 1.13 MBytes 9.51 Mbits/sec 0 70.6 KBytes
[ 5] 5.00-6.00 sec 1.15 MBytes 9.63 Mbits/sec 0 76.6 KBytes
[ 5] 6.00-7.00 sec 1008 KBytes 8.26 Mbits/sec 7 65.8 KBytes
[ 5] 7.00-8.00 sec 1.19 MBytes 9.97 Mbits/sec 0 74.2 KBytes
[ 5] 8.00-9.00 sec 1.25 MBytes 10.5 Mbits/sec 0 77.8 KBytes
[ 5] 9.00-10.00 sec 1.08 MBytes 9.08 Mbits/sec 4 63.5 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 10.9 MBytes 9.15 Mbits/sec 19 sender
[ 5] 0.00-10.00 sec 10.8 MBytes 9.10 Mbits/sec receiver

iperf Done.


Ran following command 10 times in past hour with similar Bandwith results on client2 that uses VPN server to connect to the VPN client on other side, as well poor speed :

ovpn@linuxdoos2:~# iperf3 -c 192.168.20.2
Connecting to host 192.168.20.2, port 5201
[ 5] local 192.168.10.21 port 37999 connected to 192.168.20.2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 904 KBytes 7.40 Mbits/sec 2 61.1 KBytes
[ 5] 1.00-2.00 sec 997 KBytes 8.17 Mbits/sec 1 50.3 KBytes
[ 5] 2.00-3.00 sec 943 KBytes 7.73 Mbits/sec 0 57.5 KBytes
[ 5] 3.00-4.00 sec 945 KBytes 7.74 Mbits/sec 0 59.9 KBytes
[ 5] 4.00-5.00 sec 1012 KBytes 8.29 Mbits/sec 0 64.7 KBytes
[ 5] 5.00-6.00 sec 1.07 MBytes 8.94 Mbits/sec 0 69.4 KBytes
[ 5] 6.00-7.00 sec 1.03 MBytes 8.60 Mbits/sec 2 58.7 KBytes
[ 5] 7.00-8.00 sec 1010 KBytes 8.28 Mbits/sec 0 68.2 KBytes
[ 5] 8.00-9.00 sec 971 KBytes 7.95 Mbits/sec 1 55.1 KBytes
[ 5] 9.00-10.00 sec 999 KBytes 8.18 Mbits/sec 0 59.9 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 9.69 MBytes 8.13 Mbits/sec 6 sender
[ 5] 0.00-10.00 sec 9.63 MBytes 8.08 Mbits/sec receiver

iperf Done.


Thus tge above two clients do not perform as expected ( expected values >25Mbit instead of <10Mbit )
While the other way around all is performing as expected ...

Please note no iperf3 available on other side just "iperf" and line is indeed 95Mbit max download ( hence 70 - 89 ) while upload is max 30Mbit ( hence the 23.5 - 28.1 bandwidth rates )

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.10.11 port 5001 connected with 192.168.20.31 port 48830
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-12.8 sec 108 MBytes 70.7 Mbits/sec
[ 5] local 192.168.10.11 port 5001 connected with 192.168.20.31 port 48831
[ 5] 0.0-10.2 sec 108 MBytes 89.2 Mbits/sec
[ 4] local 192.168.10.11 port 5001 connected with 192.168.20.31 port 48832
[ 4] 0.0-10.2 sec 107 MBytes 88.0 Mbits/sec

<snip snip>


What can be wrong as it seems only one side is not performing as expected, which are the clients that use the VPN server to connect to the VPN client on the other side.

[TinCanTech]

Please note no iperf3 available on other side just "iperf"

iperf3 is experi-mental .. iperf is just derp

I presume you read their respective documentation ..

[dolphs]

thanks for your reply however in this case things came close to the reality using iperf as indeed 10Mbit is the max I can get while >25 Mbit should be possible. Would be interested to see why the clients cant reach that throughput on "servers" end while clients on "client" end perform fine.

[TinCanTech]

I cannot see exactly what you are trying to do, however ..

If you are using iperf from one client to another client then the server bandwidth has to be shared between both clients. The packet flow is: Client-1 -> Server -> Client-2 -- The clients do not communicate directly ..

[dolphs]

cheers for that and I was aware clients do not connect directly to eachother hence the "add route" commands.

+------+ ---- +------+
ovpn01 ---- ovpn02
+------+ ---- +------+
| ............. |
linuxdoos01 linuxcutie01
linuxdoos02


ovpn01:
- up: +/- 30Mbit
- down: +/- 100Mbit
- server.conf
- 192.168.10.11

ovpn02:
- up: +/- 150Mbit
- down: +/- 300Mbit
- client.conf
- 192.168.20.2

linuxdoos01/02:
- route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.10.11

linuxcutie01:
- route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.20.2


Direct connection between the two VPN hosts (ovpn01 and ovpn02) shows a satisfactory result:


1/ Connecting ovpn02 to ovpn01 shows +/- 90 Mbits/sec ( download limit ovpn01 side )

ovpn@ovpn01:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

ovpn@ovpn02:~$ iperf -c 192.168.10.11
------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.2 port 11544 connected with 192.168.10.11 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 108 MBytes 89.6 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.2 port 11546 connected with 192.168.10.11 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 106 MBytes 88.2 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.2 port 11550 connected with 192.168.10.11 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.3 sec 110 MBytes 89.2 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.2 port 11552 connected with 192.168.10.11 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 110 MBytes 91.3 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.11, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.2 port 11554 connected with 192.168.10.11 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 108 MBytes 90.2 Mbits/sec


2/ Connecting ovpn01 to ovpn02 shows +/- 27 Mbits/sec ( upload limit ovpn01 side )

ovpn@ovpn02:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

ovpn@ovpn01:~$ iperf -c 192.168.20.2
------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.1 port 24418 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 32.4 MBytes 26.8 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.1 port 24420 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 32.1 MBytes 26.5 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.1 port 24422 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 32.8 MBytes 26.8 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.2, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.1 port 24424 connected with 192.168.20.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 32.0 MBytes 26.6 Mbits/sec



Now connecting linuxdoos01 to linuxcutie01 shows an unsatisfactory result
as I am expecting another 10-15Mbit to be added to the Bandwidth.
Similar results from linuxdoos02 can be seen and therefore excluded.

3/ Connecting linuxdoos01 to linuxcutie01 ( iperf added )

johnd@cutie01:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

janed@linuxdoos01:~# iperf -c 192.168.20.31
------------------------------------------------------------
Client connecting to 192.168.20.31, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.15 port 50596 connected with 192.168.20.31 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 12.1 MBytes 10.1 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.31, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.15 port 50600 connected with 192.168.20.31 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 16.0 MBytes 13.4 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.31, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.15 port 50602 connected with 192.168.20.31 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 12.6 MBytes 10.5 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.31, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.15 port 50604 connected with 192.168.20.31 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 14.0 MBytes 11.7 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.20.31, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.10.15 port 50608 connected with 192.168.20.31 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 13.8 MBytes 11.4 Mbits/sec


The other way round it is working "fine" having linuxcutie01 connected to linuxdoos01 with +/- 80Mbit.
Sometimes a significant drop can be seen, but speed is good enough to have a decent stream.

4/ Connecting linuxcutie01 to linuxdoos01

janed@linuxdoos01:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

johnd@cutie01:/# iperf -c 192.168.10.15
------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48908 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 96.1 MBytes 80.0 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48909 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.5 sec 55.9 MBytes 44.8 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48910 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 96.8 MBytes 80.5 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48913 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 45.1 MBytes 37.7 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48914 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 98.1 MBytes 81.6 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48915 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 100 MBytes 84.2 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48916 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 102 MBytes 85.3 Mbits/sec

------------------------------------------------------------
Client connecting to 192.168.10.15, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.20.31 port 48917 connected with 192.168.10.15 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-11.1 sec 77.0 MBytes 58.0 Mbits/sec


Yet I like to find out why the client machines behind the VPN loose performance while direct connection between the two VPN servers is working fine. If I can squish an additional 5 Mbit from linuxdoos01 to linuxcutie01 that would be great.

[dolphs]

looks like " echo bbr > /proc/sys/net/ipv4/tcp_congestion_control " on the VPN hardware mainly does the trick . when reverted to cubic I get similar results as on my clients. Still it remains a mystery to me why the client "clients" do get proper speeds even when these are also set to cubic ( as only reno and cubic are available )

[dolphs]

Reverted kernel tweaks to initial on both vpn servers now list:

Code: Select all

cat /etc/sysctl.d/ovpn.conf

net.core.default_qdisc = fq_codel
net.core.netdev_max_backlog = 1024

net.core.rmem_max = 33554432
net.core.wmem_max = 33554432

net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 87380 33554432

net.ipv4.tcp_congestion_control = cubic 
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_no_metrics_save = 0

net.ipv4.ip_local_port_range = 9000 65535

Verified MTU is indeed showing following as initially posted:
- client: ping somelink.com -M do -s 1464 +28 = 1492
- server: ping somelink.com -M do -s 1472 +28 = 1500

Therefore I hashed these from config files server.conf and client.conf ( both ends ) :

Code: Select all

tun-mtu 1500
fragment 1400
mssfix
( link-mtu permanently removed )

This shows very fluctuating speeds.
Please take in account max 26Mbit is possible.
Sometimes it reaches this speed, but often it does not.
I would be more than happy if speeds >=15Mbit - 26Mbit will be shown

Also bear in mind changing tcp congestion control "cubic" to "bbr" shows significant improvements vpn-vpn as shown earlier, to summarise:

Code: Select all

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17984
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.5 sec  31.8 MBytes  25.3 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17986
[  5]  0.0-10.5 sec  32.0 MBytes  25.6 Mbits/sec
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17988
[  4]  0.0-10.5 sec  31.6 MBytes  25.3 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17990
[  5]  0.0-10.7 sec  32.4 MBytes  25.4 Mbits/sec

Now as said keeping things "cubic" as that is also the value set on the clients ( can choose reno but that is about it ):

Code: Select all

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17938
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec  30.9 MBytes  25.6 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17940
[  5]  0.0-10.1 sec  31.4 MBytes  26.0 Mbits/sec
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17942
[  4]  0.0-10.3 sec  18.1 MBytes  14.8 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17944
[  5]  0.0-10.1 sec  14.1 MBytes  11.7 Mbits/sec
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17946
[  4]  0.0-10.2 sec  16.1 MBytes  13.2 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17948
[  5]  0.0-10.2 sec  15.9 MBytes  13.0 Mbits/sec
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17950
[  4]  0.0-10.2 sec  15.6 MBytes  12.9 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17952
[  5]  0.0-10.3 sec  14.8 MBytes  12.1 Mbits/sec
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17954
[  4]  0.0-10.1 sec  30.4 MBytes  25.1 Mbits/sec
[  5] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17956
[  5]  0.0-10.2 sec  31.5 MBytes  26.0 Mbits/sec
[  4] local 192.168.20.2 port 5001 connected with 10.8.0.1 port 17958
[  4]  0.0-10.3 sec  15.6 MBytes  12.8 Mbits/sec

results show above is still connecting vpn - vpn directly.

Yet iperf executed on a client (192.168.10.21 -> 192.168.20.31 both linux boxes)
As you can see speed is still limited to max 10 Mbit while max 26Mbit is expected

Code: Select all

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11624
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec  11.4 MBytes  9.42 Mbits/sec
[  5] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11626
[  5]  0.0-10.1 sec  11.0 MBytes  9.10 Mbits/sec
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11628
[  4]  0.0-10.3 sec  12.4 MBytes  10.1 Mbits/sec
[  5] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11630
[  5]  0.0-10.3 sec  12.1 MBytes  9.92 Mbits/sec
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11632
[  4]  0.0-10.2 sec  11.6 MBytes  9.54 Mbits/sec
[  5] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11634
[  5]  0.0-10.4 sec  11.6 MBytes  9.42 Mbits/sec
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11636
[  4]  0.0-10.3 sec  11.6 MBytes  9.50 Mbits/sec

The other way around ( 192.168.20.31 to 192.168.10.21 ) shows satisfactory results ( iperf3 available only and cannot install iperf ).

Code: Select all

-----------------------------------------------------------
Accepted connection from 192.168.10.11, port 58270
[  5] local 192.168.10.21 port 5201 connected to 192.168.10.11 port 58272
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  1.33 MBytes  11.2 Mbits/sec
[  5]   1.00-2.00   sec  2.78 MBytes  23.3 Mbits/sec
[  5]   2.00-3.00   sec  8.84 MBytes  74.1 Mbits/sec
[  5]   3.00-4.00   sec  9.73 MBytes  81.6 Mbits/sec
[  5]   4.00-5.00   sec  10.4 MBytes  87.2 Mbits/sec
[  5]   5.00-6.00   sec  9.76 MBytes  81.8 Mbits/sec
[  5]   6.00-7.00   sec  10.4 MBytes  86.9 Mbits/sec
[  5]   7.00-8.00   sec  10.4 MBytes  87.1 Mbits/sec
[  5]   8.00-9.00   sec  10.4 MBytes  87.2 Mbits/sec
[  5]   9.00-10.00  sec  10.4 MBytes  87.1 Mbits/sec
[  5]  10.00-10.06  sec   619 KBytes  85.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.06  sec  85.0 MBytes  70.8 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

As said I would be very happy if I can squeeze 15-25Mbit out of client connection ( 192.168.10.21 -> 192.168.20.31 ).
Seeking your help for that please

[dolphs]

added mtu-test to client.conf and it came back with

Code: Select all

Sun Apr 22 09:13:34 2018 us=86261 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_00000000000000000000000000000000000000000000000000000000111111] 0:139741 0:139740 t=1524377614[0] r=[-3,64,15,1,1] sl=[35,64,64,528]
Sun Apr 22 09:13:40 2018 us=98745 PID_ERR replay-window backtrack occurred [4] [SSL-0] [0000_00000000000000000000000000000000000000000000000000000000000] 0:145634 0:145630 t=1524377620[0] r=[-4,64,15,4,1] sl=[30,64,64,528]
Sun Apr 22 09:13:46 2018 us=53808 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1572,1572] remote->local=[1524,1524]

Ran this with both ends configured:

Code: Select all

tun-mtu 1500
mssfix 1420

Will keep on digging, meanwhile hoping one can give me a push in the right direction. TiA!

[dolphs]

As just one way showed bad performance I put a work around in placed changing UDP4 to TCP4
which shows accepatable throughput:

Code: Select all

[  5] local 192.168.10.21 port 57321 connected to 192.168.20.31 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   133 KBytes  1.09 Mbits/sec    0   41.1 KBytes
[  5]   1.00-2.00   sec   526 KBytes  4.31 Mbits/sec    0   63.5 KBytes
[  5]   2.00-3.00   sec  1.08 MBytes  9.04 Mbits/sec    0    112 KBytes
[  5]   3.00-4.00   sec  1.88 MBytes  15.7 Mbits/sec    0    199 KBytes
[  5]   4.00-5.00   sec  2.38 MBytes  20.0 Mbits/sec    0    306 KBytes
[  5]   5.00-6.00   sec  3.10 MBytes  26.0 Mbits/sec    0    438 KBytes
[  5]   6.00-7.00   sec  2.66 MBytes  22.3 Mbits/sec    0    576 KBytes
[  5]   7.00-8.00   sec  2.89 MBytes  24.2 Mbits/sec    0    703 KBytes
[  5]   8.00-9.00   sec  3.32 MBytes  27.8 Mbits/sec    0    849 KBytes
[  5]   9.00-10.00  sec  2.67 MBytes  22.4 Mbits/sec    0    973 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  20.6 MBytes  17.3 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  20.4 MBytes  17.1 Mbits/sec                  receiver

iperf Done.

Setting connection back to "UDP4" shows similar results as posted previously:

Code: Select all

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11624
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec  11.4 MBytes  9.42 Mbits/sec
[  5] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11626
[  5]  0.0-10.1 sec  11.0 MBytes  9.10 Mbits/sec
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11628
[  4]  0.0-10.3 sec  12.4 MBytes  10.1 Mbits/sec
[  5] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11630
[  5]  0.0-10.3 sec  12.1 MBytes  9.92 Mbits/sec
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11632
[  4]  0.0-10.2 sec  11.6 MBytes  9.54 Mbits/sec
[  5] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11634
[  5]  0.0-10.4 sec  11.6 MBytes  9.42 Mbits/sec
[  4] local 192.168.20.31 port 5001 connected with 192.168.20.2 port 11636
[  4]  0.0-10.3 sec  11.6 MBytes  9.50 Mbits/sec

The other way around ( 192.168.20.31 to 192.168.10.21 ) shows "satisfactory" results, also on TCP4.
IHowever ideally I keep connection set to UDP4, but for some strange reason it seems somewhere " along the road " it cannot cope with the speeds.

[martintoy]

Have the same issue,
I run a backup (backuppc) over VPN to a Windows shared folder. My VPN runs on 30Mbps fiber internet. But the speed on VPN runs only to 2Mbps. Not sure where to look, Ive tried to move on mtu, but nothing happens.
Im running OpenVPN2.4 with lz4 compression.

[NullDevice]

Hi,

Im also trying to tweak MTU and MSS values here.

About your configuration:

Code: Select all

tun-mtu 1500
mssfix 1420

Im not an expert on those topics. But does this really make sense?
Reason 1:
The official documentation says to better leave alone tun-mtu AND link-mtu parameters, and use mssfix and fragmentation values instead:

https://community.openvpn.net/openvpn/w ... n24ManPage

In most cases, you will probably want to leave this parameter set to its default value.
...
It's best to use the --fragment and/or --mssfix options to deal with MTU sizing issues.

Reason 2:
AFAIK the mss value is 28 bytes smaller than the MTU in IPv4. Because the UDP headers are still added to the packet.
Which makes your settings look weird. Because you set mtu to 1500 , but the MSS to 1420. Which is a lot smaller than 28 bytes less.

I would just try to use the "fragmentation" parameter instead, in combination with mssfix.
Thats just how i would interpret the documentation. But maybe im wrong.

But what is really bugging me is...
Assume i tested my SSL VPN on a few clients, and everything is working fine with the default settings. Means no mssfix or MTU values are set, only the defaults.
Should i still use mssfix and fragment, just in case there are some other clients out there who have problems with those big MTU/MSS values?
Or what's the best practice here?

Another thing that i want to know is:
If the server and client have differnt MTU or MSS values set, can this cause problems?
I mean, assume a client needs a smaller MSS , and it is configured for this. And it sends, lets say 1450 bytes MSS. What will happen if the server has set it to a larger value. Will this cause an instable connection?
Does that mean the client is properly sending, but has problems receiving?

Im asking because we have many different clients with different OS. And im not sure how is should configure the server so the settings are "ok for everyone".

Regards,
ND

[OSILayer3.84]

You can test the maximum available MTU size with ping:

Code: Select all

ping -f -l 1000 example.com

This will start with mtu 1000 and increase it till it fails. Add 28 bytes to the last successful mtu size and you have your maximum possible mtu size.