Lowering the MTU of the OpenVPN connection worked for me.
From the OpenVPN manual:
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 default value is 1450.
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. Resulting
packet would be at most 28 bytes larger for IPv4 and 48 bytes for IPv6
(20/40 bytes for IP header and 8 bytes for UDP header). Default value
of 1450 allows IPv4 packets to be transmitted over a link with MTU
1473 or higher without IP level fragmentation.
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
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
--tun-mtu 1500 --fragment 1300 --mssfix
I added the following the to OpenVPN configuration:
I also assume that this value may be tweaked for better performance.