I apologize for reviving an old thread - but - it appears in recent versions of OpenVPN that some of the MTU issues are fixed. I wrote:
"In addition to trashing UDP packets we have also found that "black holes" exist for certain packet sizes - attempts to send ICMP echo replies through the VPN for specific sized packets with the Don't Fragment bit set cause the packets to completely disappear - no responses back at all not even the Packet Too Big icmp messages that are supposed to come back. Setting tun-mtu corrects this issue."
This does not appear to be the case anymore that "black holes" exist.
But there is ONE issue that I think may be a bug and I was wondering about this if anyone can explain it:
I have an OpenVPN VPN that's a gateway-to-gateway VPN running over TCP without tun-mtu set.
From a host on one side I can do the following:
tedm@beachserver:~$ ping -s 1472 -c1 -M do 172.16.1.16
PING 172.16.1.16 (172.16.1.16) 1472(1500) bytes of data.
1480 bytes from 172.16.1.16: icmp_seq=1 ttl=61 time=32.2 ms
--- 172.16.1.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 32.190/32.190/32.190/0.000 ms
tedm@beachserver:~$
As you can see everything is working fine
However, if I change this to:
tedm@beachserver:~$ ping -s 1473 -c1 -M do 172.16.1.16
PING 172.16.1.16 (172.16.1.16) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500
--- 172.16.1.16 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
tedm@beachserver:~$
The error message that comes back says that MTU is set to 1500. However, it's NOT. It's not because the packet is getting rejected at 1473, because 1500 - 20 (openVPN TCP header size) - 8 (ICMP header size) = 1472
Why is the ICMP error message that's being returned to the sender saying MTU is 1500 when MTU is actually 1472?
(note that not all versions of ping return the second ICMP error message, for example the ping under Windows merely outputs:
C:\Users\tedm>ping -f -l 1473 172.16.1.16
Pinging 172.16.1.16 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 172.16.1.16:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
C:\Users\tedm> )
"In addition to trashing UDP packets we have also found that "black holes" exist for certain packet sizes - attempts to send ICMP echo replies through the VPN for specific sized packets with the Don't Fragment bit set cause the packets to completely disappear - no responses back at all not even the Packet Too Big icmp messages that are supposed to come back. Setting tun-mtu corrects this issue."
This does not appear to be the case anymore that "black holes" exist.
But there is ONE issue that I think may be a bug and I was wondering about this if anyone can explain it:
I have an OpenVPN VPN that's a gateway-to-gateway VPN running over TCP without tun-mtu set.
From a host on one side I can do the following:
tedm@beachserver:~$ ping -s 1472 -c1 -M do 172.16.1.16
PING 172.16.1.16 (172.16.1.16) 1472(1500) bytes of data.
1480 bytes from 172.16.1.16: icmp_seq=1 ttl=61 time=32.2 ms
--- 172.16.1.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 32.190/32.190/32.190/0.000 ms
tedm@beachserver:~$
As you can see everything is working fine
However, if I change this to:
tedm@beachserver:~$ ping -s 1473 -c1 -M do 172.16.1.16
PING 172.16.1.16 (172.16.1.16) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500
--- 172.16.1.16 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
tedm@beachserver:~$
The error message that comes back says that MTU is set to 1500. However, it's NOT. It's not because the packet is getting rejected at 1473, because 1500 - 20 (openVPN TCP header size) - 8 (ICMP header size) = 1472
Why is the ICMP error message that's being returned to the sender saying MTU is 1500 when MTU is actually 1472?
(note that not all versions of ping return the second ICMP error message, for example the ping under Windows merely outputs:
C:\Users\tedm>ping -f -l 1473 172.16.1.16
Pinging 172.16.1.16 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 172.16.1.16:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
C:\Users\tedm> )
Statistics: Posted by tedm — Sat Nov 30, 2024 1:08 pm