Pinging packets greater than 1500 between two proper configured machines on proper configured networks, always possible?

Question

Given the following 3 subnet topology, I will give names to them to simplify it, I am using planets, I see it as a perfect geographic enumeration.

Sites

• Office on Earth 172.1.x FiOS, default MTU
• Office on Moon 172.2.x DSL, MTU 1410 MRU 1410
• Office on Mars 172.3.x FiOS MTU 1450
• Office on Saturn 172.4.x DSL default MTU

Connections

• Earth-Moon are interconnected via layer 2 IPSEC using 2 standard off the shelve routers
• Earth-Mars wireguard appliance on Earth, to wireguard appliance on Mars (Linux x86)
• Moon-Mars wireguard appliance on Moon, to wireguard appliance on Mars (Linux x86)
• Saturn-Mars wireguard appliance on Saturn, to wireguard appliance on Mars (Linux x86)

In the past we had issues with long living TCP connections between Earth-Moon, these issues were only with TCP connections involving a dumb device. such as IP camera, IP phone, but when communicating between windows PCs everything workes, after some online research, we ensured that we couldn't ping between windows PCs packets greater than 1438, so we configured our MTU and MRU to 1410, and #1 we were able to ping, (win to win) #2 the TCP issues have been resolved.

My friend complained to me about an office in India unable to RDP, I told him my experience and he was able to resolve the same, by setting their MTU respectively.

I took this as a fact that it is possible to ping packets with arbitrary size, as long as we have a router that knows to fragment the packets, before being encapsulated in a bigger packet for VPN transmission, and some pings are not going torough the same happens with TCP causing repetitive failed TCP transmissions.

We change location on Moon, to a new ISP and since than we are having ups and downs in our internet service, long page loads Etc. but what is interesting is that even when the browsing is down, we could ping 8.8.8.8 ,resolve DNS requests, we suspected that the MTU should be adjusted accordingly, but we are unable to ping anything greater than 1410, and if we set DF we receive a reply from our Moon gateway DF was set.

In the same time we are able to ping even 2000 over the Moon-Mars WG tunnel.

In Saturn the internet also goes up and down, (but ping always works) and I am unable to ping to either VPNs with big packets, and lowering the MTUs even on the local machine didn't helped. but that never worked perfectly, also I am not onsite so I do not have the exact numbers.

It comes down to 3 questions:

1. the title, is it true that with perfect MTU without DF we should be able to ping with any size?
2. if not always, what are the boundaries, what is the proper method or tool to ensure that MTUs are OK (besides checking how many times internet goes up and down).
3. Given the illustration above, does any obvious issue comes up?

Answer 1

is it true that with perfect MTU without DF we should be able to ping with any size?

It should be. Assuming 1500 bytes standard MTU over Ethernet, using ping payloads greater than 1472 (8 bytes are ICMP, 20 bytes IPv4 overhead) fragments the IP packet. If the maximum-sized fragments don't make it through there's bottleneck in the path that doesn't fragment oversized packets. However, if there is a fragmenting bottleneck you won't see it from ping output alone, only by capturing the fragments (beware of reassembly offloading in the NIC), or by using the DF flag.

if not always, what are the boundaries, what is the proper method or tool to ensure that MTUs are OK (besides checking how many times internet goes up and down).

Using ping -f -l 1472 (from Windows) is the method of choice. There's no guarantee though when different protocols are routed differently by policy. Destination NAT is also problematic as you most often ping the NAT router's public interface, not the actual server behind translation.

Given the coming obsolescence of IPv4, path MTU discovery (PMTUD) should be implemented everywhere and supported on the infrastructure components, and general ICMP filtering is an absolute no-go.

You might also want to check out MSS clamping as it's a more reasonable (yet somewhat imprecise) method to avoid TCP issues and unnecessary in-path fragmentation without PMTUD.