This has nothing to do with openvpn MTU because the tunnel itself does not traverse Hetzner network.
Seeing it this way yes, it makes sense. However the problem appeared when I started to use vSwitch (mtu 1400), so I thought it is related.
So, what may be the problem then? A real example is:
1. I connect to my OpenVPN server on 5.9.xxx.xxx.
2. I start transfer large file (several Gb) from 172.16.2.xxx.xxx (not OpenVPN host on the vSwitch network) to my host (10.90.xxx.xxx).
3. After, about 40 sec the connection is broken.
Client's log says:
Code: Select all
May 22 17:43:31 crow openvpn[3412569]: Initialization Sequence Completed
May 22 17:44:08 crow openvpn[3412569]: AEAD Decrypt error: cipher final failed
May 22 17:44:08 crow openvpn[3412569]: Fatal decryption error (process_incoming_link), restarting
May 22 17:44:08 crow openvpn[3412569]: TCP/UDP: Closing socket
May 22 17:44:08 crow openvpn[3412569]: /etc/openvpn/scripts/update-systemd-resolved tun0 1500 1555 10.90.0.2 255.255.0.0 restart
May 22 17:44:08 crow openvpn[3412569]: openvpn_execve: unable to fork: Resource temporarily unavailable (errno=11)
May 22 17:44:08 crow openvpn[3412569]: Exiting due to fatal error
May 22 17:44:08 crow openvpn[3412569]: /usr/bin/ip route del 172.16.0.0/16 metric 1
May 22 17:44:08 crow openvpn[3412569]: openvpn_execve: unable to fork: Resource temporarily unavailable (errno=11)
May 22 17:44:08 crow openvpn[3412569]: Exiting due to fatal error
UPD: OK, I was checking the server side log also and that's what I see:
Code: Select all
client-xxx/185.239.201.xxx:46760 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
client-xxx/185.239.201.xxx:46760 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
client-xxx/185.239.201.xxx:46760 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
MULTI: multi_create_instance called
Re-using SSL/TLS context
LZO compression initializing
Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv
UPD2: It seems like changing tcp-queue-limit parameter to 256 should fix the problem. However, I can't find an explanation why it worked before, when using exactly the same installation.