[SOLVED] OpenVPN latency problem (Can ISP or Router prevent access via OpenVPN to some private not secure sites?)

[raffe1234]

Hi!

I have on my LAN a IPFire with OpenVPN, and its admin web interface is a self signed https://192.168.200.254:444/ that is not secure (see https://wiki.ipfire.org/configuration/login ). Also I have on my LAN a private Calibre http book web page http://192.168.200.160:8083/ (see https://hub.docker.com/r/linuxserver/calibre ).

They have custom ports, but I have other local sites with custom ports that work OK.

Normally on LAN, via VPN from work, via VPN with my phone as hotspot and via VPN from many other places I have no problems using the sites. So 95% of the time, all is OK.

But sometimes, in rare occasions it do not work. As today I am at a friends home, and thru his WIFI I can just load 10% of the IPFire page and then it times out. The calibre site gives "The connection to the server was reset while the page was loading.". With phone as hotspot all is OK.

But I can access my Qnap NAS admin web page, and all SMB shared files on it, and some other sites and stuff at home via VPN. So just a few things do not work, and IPFire works ~10% that is even more strange.

He has a Asus RT-AC68U router, and I tried to turn off all different settings, I even tried to turn of the firewall on it without luck. No warnings or error in OpenVPN log or in the IPFire logs.

Do you have any guess what it could be and what could fix it?

Server has:
Global Settings
Protocol: UDP
MTU size: 1500
Destination port: 443
Hash algorithm: SHA2 (512 bit)
Encryption: AES-GCM (256 bit)
TLS Channel Protection: True

Client:
#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
tun-mtu 1500
remote server.com 443
pkcs12 raffe.p12
cipher AES-256-GCM
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name server.com name
mssfix 0
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact
providers legacy default

EDIT: Maybe it is something with the Windows 11 OpenVPN v2.6.5 client. With Phone > Wifi > OpenVPN > IPFire WUI it works.

[raffe1234]

I got this answer in another forum:

Your latency issue may potentially be attributed to an MTU size that is not supported by each hop in the network. Typically, slow or partially loading web pages within a VPN setting can be a consequence of an MTU mismatch.

The MTU, or Maximum Transmission Unit, is a crucial network parameter. It dictates the maximum data packet size, in bytes, that can be sent over your network connection. This size encompasses both the packet’s data and header information. Within a VPN context, the data is additionally encrypted.

If a network can’t accommodate the size of the packets, they need to undergo a process of reassembly, decryption, fragmentation, and re-encryption. This can create substantial overhead, leading to significant network latency.

You can mitigate this issue by determining the optimal MTU size for your network. Although various procedures can help establish the most effective MTU, a common approach involves trial and error: gradually reducing the MTU size until you achieve acceptable latency. Alternatively, the server can automatically determine the optimal MTU if you modify the configuration file, as outlined in the IPFire OpenVPN Troubleshooting Guide 1.

You can adjust the MTU either at the client side, which would only affect that particular client, or at the server side, which would impact all clients. If there is a discrepancy between the server’s and client’s MTU settings, the lower of the two will be used for sending data packets. In my specific case, an MTU value of 1360 has been effective across all the networks I utilize, including during my travels. As I am the sole user of my network, I’ve configured this setting in the IPFire Web User Interface, under /Services/OpenVPN/Global Settings/MTU size and I have matched it in all my clients as well.

There’s also an option to minimize potential mismatches by adjusting a second parameter: /Services/OpenVPN/Global Settings/Advanced server options/mssfix. Both parameters determine the maximum size of a packet, but they operate at different levels. The MTU value is defined at the Network layer (IP level), while ‘mssfix’ operates at the Transmission Control Layer (TCP level). Personally, I tend to rely on adjusting the MTU value.

When I tried a MTU value of 1360 with my client, all problems went away