See below.
From: "tincantech via Openvpn-users" <openvpn-users@lists.sourceforge.net<mailto:openvpn-users@lists.sourceforge.net>> Date: Saturday, 29 July 2023 at 18:19:07 To: "Niccolò Belli" <darkba...@linuxsystems.it<mailto:darkba...@linuxsystems.it>> Cc: "openvpn-users@lists.sourceforge.net" <openvpn-users@lists.sourceforge.net<mailto:openvpn-users@lists.sourceforge.net>> Subject: Re: [Openvpn-users] How to determine the correct MTU/fragment value in OpenVPN 2.6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ------- Original Message ------- On Friday, July 28th, 2023 at 14:52, Niccolò Belli <darkba...@linuxsystems.it> wrote: > Il 2023-07-24 13:23 tincantech ha scritto: > > > If your PMTU is changing "on a daily basis" then you should probably > > report > > that as a fault to your Internet Service Provider(s). > > > Forgot what I've written before: I've did many more tests and apparently > my connection(s)' MTU is not changing but something else is going on > with openvpn. My analysis of your test data, reduces to the following comment: Personally, I do not consider Google to be a valid target to test against. root@home ~ # ping -M do -s 1252 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1252(1280) bytes of data. ^C --- 8.8.8.8 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3003ms root@home ~ # ping -M do -s 1252 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 1252(1280) bytes of data. 1260 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=13.5 ms 1260 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=13.1 ms ^C --- 1.1.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 13.142/13.312/13.482/0.170 ms I'll leave that hanging ... The value of PMTU, or Path MTU, is really only valid between your source location and your destination location. Testing against a third party is less valid, as seen above. However, considering the data you have posted, I think OpenVPN has documented the most simple solution. The example given is to use these options: --tun-mtu 1500 --fragment 1300 --mssfix If you are confident that you have established the genuine PMTU between your client and server then adjust the --tun-mtu value as you see fit. Then, starting with the --fragment value given, adjust --fragment until you establish the likely maximum. With regard to your multi-path tests, it's complicated and above my pay grade.. Regards -- Hi, several remarks… We’ve found that transmission equipment CAN (and unfortunately sometimes does) treat protocols differently. So what you find with ICMP, may differ from UDP or TCP. Sometimes they are even routed differently! Also, certain devices (no, I won’t specify them) are doing stealth tunneling, without responding properly to their lowered MTU. It caused me a lot of grey hairs. And, as been said before: testing to your intended destination is the only proper way. Either with the build-in tool by OpenVPN, or, while tunnel IS up, or through it, periodically with your own, in order to guard its well-being. Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
