[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
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).
-- 'ooroo Stinga...(:)-) --------------------------------------------------- Email: stinga+dclug@xxxxxxxxxxxxx o You need only two tools. o ///// A hammer and duct tape. If it /@ `\ /) ~ doesn't move and it should use > (O) X< ~ Fish!! the hammer. If it moves and `\___/' \) ~ shouldn't, use the tape. \\\ ---------------------------------------------------
-- Giles Coochey
-- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq