WSL2 Git Stalls on a VPN: Interface MTU or Path?

The clone authenticates, the object count appears, and then nothing moves for minutes. Windows reports the VPN as connected, the hostname resolves, and a browser on the same machine fetches the same repository page without difficulty. That combination points at packet size rather than at credentials, and the size question has to be asked in two places because WSL2 has its own Linux interface with its own MTU. One number belongs to the Windows side of the path, the other to the distribution, and reading only the VPN adapter leaves half the path unexamined.

Three Signals Separate a Size Problem From Elsewhere

The first signal is shape: connection setup and a small exchange succeed, then bulk transfer stops making progress. The second is symmetry: the same repository and the same transport fail while a different host on the same path works, or the failure changes with payload size rather than with time of day. The third is silence: no authentication error, no proxy rejection, no name resolution failure, just a transfer that never completes.

Those three together justify a packet-size hypothesis. A DNS failure, an expired token, a rejected SSH key and a proxy that refuses CONNECT each produce their own error, and none of them looks like a stall after success. Keeping the same repository, transport and time window while testing is what makes the comparison honest.

Compare Both Interfaces Before Deciding

Collect the Windows view and the Linux view in the same session, and keep the repository's address rather than a guess about which interface carries it. The command below resolves the destination first so the route lookup describes the actual server the clone contacts, which may differ from the name a browser showed. Run both halves close together, because the VPN can change interface metrics between attempts.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Run the Linux half inside the distribution instead of pasting the output into a Windows shell, since the interface names and route selection only make sense there. A paste from a Windows shell reports the wrong numbers with great confidence. Record the device, the selected route and the MTU from each side before changing anything.

Decide Whether the Number Should Be Smaller

A larger interface MTU than the path can carry is not automatically a fault, because path MTU discovery exists to handle exactly that. The failure mode appears when discovery is suppressed: ICMP messages are filtered somewhere along the way, the sender never learns the limit, and large packets vanish while small ones succeed. That is a path property, not a property of Git. It is also the reason a small file can succeed on a connection where a large one never finishes.

If the evidence supports it, a temporary change on the Linux interface is the cheapest test. Pick a value below the usable path size, record the previous one, and keep everything else constant so the comparison means something. If the transfer completes at the smaller value, you have a diagnosis rather than a coincidence.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

Decide Where the Setting Should Live

Three options follow from the test, and only one of them is usually appropriate. If the smaller value fixes the transfer and the value is genuinely required for this network, the setting needs a lifecycle owner: a distribution start hook, a network configuration managed by the platform, or a documented procedure. If the value fixes nothing, revert it and return to the transport, proxy and authentication questions.

Whether a start hook exists depends on the Windows and WSL versions in use and on the networking mode configured. Mirroring the Windows network can change how a VPN interacts with the distribution in ways that matter more than an MTU adjustment, so identify the mode before designing a workaround for it. A value that suits one carrier or one VPN profile is not a default for the next.

What to avoid is the tempting placement: a privileged network command in every interactive shell's startup file, or passwordless sudo for the whole ip binary so a script can run one line. Both turn a diagnostic into permanent exposure and make the original problem harder to see later.

Verify After a Fresh Start, Then Reverse It

A change that survives only until the distribution restarts is not a fix. Restart the distribution, reconnect the VPN, and repeat the original Git operation rather than a substitute like a ping or a small HTTP request. Then confirm the interface carries the intended value in the new session.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

Keep the recorded original value next to the change so the experiment can be undone cleanly, and note which address family was tested, since an IPv4 result says nothing about an IPv6 connection on the same host. The WSL networking documentation describes the modes that determine what a fix should look like; the MTU number itself is a local measurement, not a recommendation.