MTU - who to trust - Windows or Wireshark?

E

EnthusiastXYZ

Limp Gawd
Joined
Jun 26, 2020
Messages
221
When I use WireGuard-based VPN and run "ping -f -l MTU" commands in Windows to find optimal MTU (+28 for ICMP) for pjysical LAN adapter (NIC), Windows reports about needing or not needing to fragment packets based on MTU do not correspond to Wireshark reports. Wireshark reports IPv4 packet loss due to fragmentation for any MTU other than 1500 (-28). WireGuard TUN adapter is set by VPN software to 1420, which is default for WireGuard.

Without VPN, optimal MTU that requires no fragmentation is 1500 (-28) and WireGuard header is supposedly 60 bits, which means optimal MTU with WireGuard-based VPN is supposednto be 1440 (-28).

Not only that, but with or without WireGuard VPN, there is a 12bit MTU range between 1400 and 1500 that results in 'no response' Windows ping reply 100% of the time, but MTU in that range does not prevent websites from loading and Wireshark does not detect packet loss for that MTU range.
 
So let me see if I can understand what you're saying:

Ping ip address normally, and "ping -f -l 1472 192.168.1.1" should reply, but "ping -f -l 1473 192.168.1.1" does not and says it needs to fragment. That is 100% the expected result on most networks especially if you're not leaving the subnet you are on and have the default MTU set. I'd trust ping 100% in this example it's telling you whether or not a packet can be set. With DF bit set, the second one isn't able to send a ping at all.

So now in the second example, turn on wireguard and if you run the same thing, 1472 works and 1473 doesn't? If thats the case then that means that wireguard is accepting at least a 1500 MTU, and it's likely fragmenting it's own packets, but it's telling windows those sizes are just fine. Because you are encapsulating traffic it might be doing magic to let Windows operate like normal, when in reality it has to break up those packets behind the scenes in order to send them. The biggest question comes from where you are running wireshark, because that will make a big difference is what it can figure out. If you're running wireshark on the same machine that has the VPN running, I'm not sure how accurate it will report the VPN interface. If you mirrored the physical port and captured the packets as they are leaving the interface, you might see different results than you would see by inspecting the VPN adapter.
 
I run Wireshark from my own PC on a local network.

"ping yahoo.com -f -l 1472" with WireGuard-based VPN = "Packet needs to be fragmented but DF set" Windows Response = packet loss not detected in Wireshark
"ping yahoo.com -f -l 1392" with WireGuard-based VPN = "Reply from Yahoo IP" (packet does not need to be fragmented) Windows Response = packet loss detected in Wireshark

1392 is the highest MTU that does not result in Windows report that states that packet needs to be fragmented. 1392+28=1420. 1420 is the default WireGuard MTU. It seems to work out from that perspective, but Wireshark detects packet loss at any MTU other than 1472.

WireGuard VPN adapter MTU is set to 1420 by the VPN software, but I think that both Windows and Wireshark try to measure MTU from the physical LAN NIC, not the VPN adapter.

Website-based tests (such as browserleaks.com) always detect MTU of 1500 when I use WireGuard-based VPN, regardless of Windows or router or cable modem MTU settings. Download speeds from public networks are the highest and latency is the lowest from same public sites when I use MTU of 1500 everywhere.

The only conclusion I can make is that my VPN is designed around the standard MTU of 1500 and I should use that option in Windows MTU settings, router MTU settings, and cable modem MTU settings.
 
EnthusiastXYZ said:
The only conclusion I can make is that my VPN is designed around the standard MTU of 1500 and I should use that option in Windows MTU settings, router MTU settings, and cable modem MTU settings.
Click to expand...

That's likely a fair conclusion. The fact that Wireshark says no packet loss for 1472 but yes to packet loss for 1392 makes me think that's simply a bug in wireshark or the wording of what that actually means isn't what we think it is. But either way I generally would never suggest changing the default MTU, especially if the traffic is going to be routed at all.
 
wireshark on Windows is great, but it's not going to show corrupted frames etc because those are lower down the stack, hence why in enterprise environments they use span ports etc on switches. There are hardware taps that would probably give you a clearer packet visibility
 
OK, I figured it out. When running PING command, it does not even go through VPN. If I try to use firewall rules to force PING.exe to use VPN (TUN) virtual adapter, I get "General Failure" error. Is there some way to test MTU without the ping command? MTU reported on websites will always be 1500 if VPN is used.
 
EnthusiastXYZ said:
OK, I figured it out. When running PING command, it does not even go through VPN. If I try to use firewall rules to force PING.exe to use VPN (TUN) virtual adapter, I get "General Failure" error. Is there some way to test MTU without the ping command? MTU reported on websites will always be 1500 if VPN is used.
Click to expand...
Ouch! That sounds suspicious. Maybe something related to your other issues ... Are you running some sort malware protection on this device? Something that can detect rootkits?
 
I use SimpleWall (Windows-based firewall) and Windows system program bypass VPN when I disable "Block Outbound Connections For All (Recommended)" in SimpleWall, even though VPN software has "LAN Invisibility" enabled with Kill-Switch activated. When "Block Outbound Connections For All (Recommended)" is disabled, programs with firewall rules that force those programs to use TUN/TAP adapter IP continue to use VPN, but Windows EXE files bypass VPN. Also, if I disable "Block Outbound Connections For All (Recommended)", browsers with TUN/TAP adapter IP rules bypass VPN if I try to access local network router configuration pages (via 192.168.0.1, etc), but do use VPN when accessing public sites. It makes it convenient, but I now know it makes Windows OS files like PING.EXE and TRACERT.EXE bypass VPN. If I enable "Block Outbound Connections For All (Recommended)", everything goes through VPN on PC, but using PING and/or TRACERT command results in "General Failure" error.

I don't think I have any malware. The same exact behavior occurs on other PC's and freshly installed Windows 10 systems. Maybe PING.EXE and TRACERT.EXE are some subsystem part of SVCHost.exe? I don't have any rules for SVCHost.exe...

On mobile devices it is worse because phones force WiFi calling (even when disabled) via IPSec VPN. TCPDump logs show that Google Voice also tries to bypass installed VPN and use SIP port 5060 for calls. The latest version of Google Voice even installs its own VPN tunnel. To get Google Voice to use 3rd party VPN properly, you have to remove Google Voice VPN, disable common outbound SIP ports in router settings, block Google's lens.l.google.com, stun.l.google.com via HTTP Auto-Proxy (possible on rooted phones).
 
Google says both PING and TRACERT are a part of ICMP. I know firewall can block ICMP, but I am not sure if a VPN can affect it.
 
I have ICMP working correctly now. Now I can use Ping and TraceRT commands via VPN. It doesn't change the packet loss occurrence discrepancy between Wireshark and Windows reports. It only bothers me when I play games because some games report that there is a connection problem, even when gameplay-wise there doesn't appear to be one. My latency remains awesome (on average only 5-10ms above non-VPN connection), there are no symptoms of any connection problems, just reports of such. I assume games and other programs conclude that there is a connection problem based on Windows-based packet loss information.
 
You must log in or register to reply here.
Back
Top