Il 2023-07-29 19:41 tincantech ha scritto:
In future, the only valid target is your server (or client).
I am not interested in comparing your various network paths.
Establish a well known MTU on a well known path, first.
[tiscali ~]$ ping -M do -s 1432 -c 1 PUBLIC_SERVER_IP
PING PUBLIC_SERVER_IP (PUBLIC_SERVER_IP) 1432(1460) bytes of data.
1440 bytes from PUBLIC_SERVER_IP: icmp_seq=1 ttl=56 time=38.7 ms
--- PUBLIC_SERVER_IP ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 38.699/38.699/38.699/0.000 ms
As you can see MTU from the Tiscali client to the server is 1432+28=1460
Once I establish the tunnel (tun-mtu unset, fragment unset and mssfix
unset) I can ping the private IP of the server and the payload size
decreases by 66 bytes:
[tiscali ~]$ ping -M do -s 1366 -c PRIVATE_SERVER_IP
PING 192.168.2.1 (192.168.2.1) 1366(1394) bytes of data.
1374 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=38.5 ms
--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 38.477/38.477/38.477/0.000 ms
I can use that to infer that the encapsulation overhead accounts for 66
bytes.
Now let's move to the Iliad connection:
[iliad ~]$ ping -M do -s 1472 -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=115 (truncated)
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 70.188/70.188/70.188/0.000 ms
Today Iliad has an MTU of 1472+28=1500 towards Google.
Being a mobile connection I'm not too mad if the MTU is subject to
changes, but I didn't expect it to ever reach 1500.
[iliad ~]$ ping -M do -s 1464 -c 1 PUBLIC_SERVER_IP
PING PUBLIC_SERVER_IP (PUBLIC_SERVER_IP) 1464(1492) bytes of data.
1472 bytes from PUBLIC_SERVER_IP: icmp_seq=1 ttl=55 time=126 ms
--- PUBLIC_SERVER_IP ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 125.893/125.893/125.893/0.000 ms
The MTU from the Iliad client to the server is 1464+28=1492 as expected
(the server has 8 bytes of overhead from the PPPoE).
So if I'm going to ping the server private IP I would expect a payload
size of 1464-66=1398:
[iliad ~]$ ping -M do -s 1472 -c 1 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 1472(1500) bytes of data.
1480 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=93.9 ms
--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 93.861/93.861/93.861/0.000 ms
That's NOT what's happening! Somehow I can ping the server private IP
with a payload size of 1472 despite fragment not being set (tun-mtu and
mssfix have not been set either).
How do you explain that? It looks like it's automatically fragmenting
packets despite fragment has not been set.
Considering your command of English, this is documented:
https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html
I've read that, but it's not fully clear.
About "--fragment max mtu" I can read the following:
"Enable internal datagram fragmentation so that no UDP datagrams are
sent which are larger than max bytes.
If the mtu parameter is present the max parameter is interpreted to
include IP and UDP encapsulation overhead.
If the mtu parameter is absent, 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.
--fragment adds 4 bytes of overhead per datagram."
Let's also read "--link-mtu n" since it looks like it's related:
"Sets an upper bound on the size of UDP packets which are sent between
OpenVPN peers.
Due to variable header size of IP header (20 bytes for IPv4 and 40 bytes
for IPv6) and dynamically negotiated data channel cipher, this option is
not reliable.
It is recommended to set tun-mtu with enough headroom instead."
"--tun-mtu tun-mtu" seems easy to understand:
"Take the TUN device MTU to be tun-mtu and derive the link MTU from it.
The MTU (Maximum Transmission Units) is the maximum datagram size in
bytes that can be sent unfragmented over a particular network path."
According to the docs and my experimental data the Tiscali-Server
tun-mtu parameter should be set to 1460. I think that this is supposed
to set the mtu on the tap interface to such value, but it doesn't
because I create the tap device with NetworkManager. What I do is
manually setting the tap mtu to 1460. I also set the bridge where the
tap has been added to to 1460, as well as the ethernet interface
attached to the bridge. This way all the packets originated from the
Tiscali client or the server shouldn't exceed 1460, but being a layer 2
vpn that does nothing for all the other devices in the network that want
to talk to the other side of the tunnel.
One question remains open: how do I verify which link-mtu gets computed
from the tun-mtu? According to what I've understood from the
documentation it should be at least 1460 - 20 (IPv4 header) - 66
(encapsulation overhead) - 8 (UDP header) = 1366. Unfortunately there is
no way to verify what actually gets computed from the link-mtu.
So from what I've understood so far --fragment should either be set to
"fragment 1362" (the link-mtu - 4 bytes of overhead) or "fragment 1390
mtu" (the link-mtu + 28 - 4 or simply tun-mtu - 66 - 4). Using the mtu
variant looks like the better solution because it takes into account the
IPv4 (20 bytes) vs IPv6 (40 bytes) header size.
Setting "tun-mtu 1460, fragment 1300 mtu, mssfix 1300 mtu" should give
plenty of headroom to stay on the safe side, yet the Tiscali connection
behaves weirdly: for example clients most of the times don't receive the
gateway from the dhcp (certain clients like the Amazon Fire Stick never
do, yet they work fine with static IP). This doesn't happen with the
Iliad connection!
Il 2023-07-31 13:20 j.witvl...@mindef.nl ha scritto:
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!
That's weird, do you know any way to easily and reliably test the MTU
size on UDP?
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.
I've read something similar in the mailing list previously:
"Another situation that cannot be detected or worked around by PMTU
are underlying L2TP tunnels, typically found in the DSL world. If
DSL is done over FastE or gigE (without jumbo frames) between the ISP
and telco, each full sized packet will get fragmented as the max
packet can only be 1460 bytes. In this situation, PMTU wont help you
as the endpoints dont know that behind the scenes all sorts of
fragmentation and reassembly are being done. ISPs typically add a
TCP MSS-Fixup on outbound tcp connections, but with UDP as the
transport for OpenVPN, this wont work."
Since my Tiscali FTTC connection MTU ends up being 1460 it looks like
something similar is happening behind the scenes. I'm unsure why they
would need an L2TP tunnel behind the scenes and I don't know how to
actually verify if that's what's happening.
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.
The OpenVPN built-in tool results don't make sense to me.
This is the result for the Iliad connection:
NOTE: Empirical MTU test completed [Tried,Actual]
local->remote=[1556,1556] remote->local=[1556,1556]
How can it possibly be higher than 1500? My measured (with ping) MTU
from Iliad to Server is 1492.
On the other hand this is the result for the Tiscali connection:
NOTE: Empirical MTU test completed [Tried,Actual]
local->remote=[1556,1362] remote->local=[1556,1446]
This makes more sense because 1362 is near my expected link-mtu of 1366
but I still don't understand:
A) Why local->remote should be different than remote->local.
B) What's the difference between the first value (1556) and the second
one (1362/1446).
C) Why the first value is higher than 1500.
D) What exactly these numbers exactly mean anyway.
Niccolo'
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
