[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 16/11/2021 08:45, stinga wrote:
On 16/11/2021 16:17, Giles Coochey wrote:
On 16/11/2021 07:52, stinga wrote:G'day,
G'day all,This is very often caused by configuring a MTU that is too high within OpenVPN.
We have changed ISP from BT to Zen at the office and now don't seem to copy files.
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn
Thanks Giles, I was beginning to think MTU maybe playing a part in this.
It did work with BT (it was plusnet actually)
It is set to the default of 1500, should it not automagically work this out itself, thought I had been down this rabbit hole before (2 years ago) and I ended up removing a whole load of things like mssfix etc that I had added to try and make it work (Think I was doing TCP then for some reason)
I can see that openvpn is currently set to 1500 and I can see that ping fails with it at 1500, I need to do
ping -Mdo -s1470 legato
To get a successful ping.
I resume I will need to make the change on both the server and client if I pass --tun-mtu 1470?
Just doing it on the client will not work? (which brings up a problem...)
Also openvpn is not showing any other issues, we stream audio over it fine, just these files won't copy over smb/cifs.
Does that sound correct?
I'm not sure if the tun-mtu will work, and we usually make the chosen number divisible by 4 I think, so 1468 would be better. I've not had much success with changing MTU within OpenVPN, might be better to just reduce it at the System level (both server and client). It is heavily discussed on forums out there, so a search for "openvpn mtu mss" will probably uncover lots of previous discussion and experiences.
mssfix should modify the first two TCP packets for new connections (SYN & SYN-ACK packets) inside the tunnel to say "this is the largest payload I can accept" and with the OpenVPN header it is prudent to subtract 40 from the working MTU value to get a value for the MSS. Audio works because it uses smaller packets, large file transfers fail because OpenVPN starts to create full size packets, which get dropped over UDP, and UDP has no mechanism to detect dropped packets.
To be honest, I tend to go pretty aggressive with reducing the mssfix value, and often choose values as low as 1300, it doesn't affect performance to any discernable extent (and still fixes the issue).
Because I have had UDP rate-limiting issues (e.g. at hotel wifi) in the past, I've always also set up a TCP based OpenVPN configuration in conjunction with the UDP one, so if I have problems then I switch to the TCP based one, which I can run on a well known port that won't be rate-limited (e.g. 443 or 8443).
--
From OpenVPN manual page:
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.
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.
The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ).
--fragment adds 4 bytes of overhead per datagram.
See the --mssfix option below for an important related option to --fragment.
It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead.
Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.
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 peers.
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 following options:
--tun-mtu 1500 --fragment 1300 --mssfix
-- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq