Il 2023-07-29 18:13 tincantech ha scritto:
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.
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.
With regard to your multi-path tests, it's complicated and above
my pay grade..
I used Google as an example, but the MTU I've found is correct and I can
confirm it with any other address, including my server's public IP.
Also 192.168.2.1 is a private address to a private network on the server
side of the tunnel: with Tiscali I can ping it up to a 1366 payload size
(66 bytes less than the Tiscali MTU), while with Iliad I can go up to a
1472 packet size which corresponds to a 1500 MTU and no encryption
overhead. That makes no sense because
A) None of the connections has a 1500 MTU
B) Encryption overhead cannot be 0
C) I didn't enable fragment
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.
What's fragment's max parameter (1300 in your example) supposed to mean?
If it's the payload size after which openvpn starts to internally
fragment packets shouldn't I just set "--fragment xxxx mtu" where xxxx
is the lowest MTU between the client and the server?
Niccolo'
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
