SSH connections hanging from WSL2

[dombegin]

Current Version 10.0.19025.1

I have this weird issue where I can no longer use SSH connections to remote servers from WSL2. I remember that it was working ok in early builds but I am not sure at which point it started to fail.

Any idea on how to resolve this would be appreciated.

What happens

When connected to a remote server, SSH connection hangs after a very short time. I am sometimes able to type a few letters but then it hangs and have to close WSL. It does this with every SSH connections to every server.

For instance, on the following screenshot, you can see that I was able to type a few numbers but the connection froze at the last "1".

Probably related, SSH git cloning is not working either. It starts receiving objects but stops shortly after. I have to CTRL-C to stop. Here's an example hanging at 46%.

> GIT_SSH_COMMAND="ssh -vvv" git clone --verbose git@github.com:microsoft/dotnet.git

...

In WSL1, everything works smoothly and have no issues. It's only in WSL2 that this happens.

Note that git cloning through HTTPS works fine as well.

Just let me know if there is additional trace I can run to help since I know this is probably going to be hard to repro.

[therealkenc]

Just let me know if there is additional trace I can run to help since I know this is probably going to be hard to repro.

No easy guesses off the cuff, and nothing similar on the books I know of. The usual "are you running any third-party VPN or firewall software" question applies. Is it correct to say git.exe and ssh.exe from a Windows cmd.exe prompt does not exhibit the hangs?

[dombegin]

The usual "are you running any third-party VPN or firewall software" question applies

No active firewall / vpn

Is it correct to say git.exe and ssh.exe from a Windows cmd.exe prompt does not exhibit the hangs?

Exactly, everything works fine from cmd/ps and from WSL1 as well

[nadddy]

I am getting exact same issue after upgrading to windows 10 2004 and upgrading to wsl2.

[randand]

I have the same problem. Mu linux distribution is ubuntu, I tested both 18.04 and 20.04.
When the windows host is connected through a VPN, ssh is not working. Also git does not connect to the server.
The problem is only present in wsl2, on the same pc and using the same host vpn, WSL1 works fine.

[lpysj]

I too have the same problem. I just upgraded to Windows 2004 and WSL 2 and cannot connect to hosts on the VPN network. I can however connect to hosts on AWS.

When I'm using Powershell to connect to the VPN hosts it works fine, problem is only under WSL 2.

Interestingly when I use docker (with the wsl2 backend enabled), to start a alpine container from within wsl2 and I try to ssh into one of the hosts from there it works just fine.

[xkotj]

I have the same issue.
WSL1 in VM - connection to SSH server is ok. (VPN)
WSL2 in VM - connection to SSH server is ok (VPN), but when I grep for example larger output from text file it hangs and shows broken pipe aftewards.
W10 - 2004
Ubuntu-20.04

[matheusmb]

I started having this issue since two days ago. I'm not exactly sure what changed, I didn't make any new install/upgrade. Running W10 - 2004, Ubuntu 18.04 @ WSL 2

[redsoft7]

Same problem:

• W10 - 2004 (Version 10.0.19041.329)
• Ubuntu 20.04 in WSL 2
  Sometimes it hangs on the grep command, other times when I edit files with nano.
  The problem only occurs on servers in VPN, in lan servers the ssh connection does not block.

[lbergnehr]

This (in PowerShell) appears to work around this issue for me:

New-NetFirewallRule -DisplayName "WSL" -Direction Outbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Inspired by this comment: #4585 (comment).

[jeffersonfelixdev]

Same problem here
Ubuntu 20.04 in WSL2 running on Windows 10 2004
SSH over VPN hangs when I type a simple "ls -a" or "top"

[jonas154]

I have also the same problem with 2004, connecting via SSH over VPN works but then simple commands like top freezes everything.

[bpottier]

I'm having this issue too. SSH will hang randomly when connected to VPN. Sometimes from cat or grep or sometimes immediately upon connecting to a host.

Ubuntu 18.04 in WSL2 on Windows 10 2004.

[maxdobeck]

No VPN or firewall & I'm on WSL2

git clone git@github.com:maxdobeck/gimme.git
Cloning into 'gimme'...
Received disconnect from 192.30.255.112 port 22:11: Bye Bye
Disconnected from 192.30.255.112 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

ssh -vvv -T git@github.com
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/max/.ssh/config
debug1: /home/max/.ssh/config line 1: Applying options for github.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "github.com" port 22
debug2: ssh_connect_direct
debug1: Connecting to github.com [192.30.255.112] port 22.
debug1: Connection established.
debug1: identity file /home/max/.ssh/id_rsa type 0
debug1: identity file /home/max/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version babeld-fceaa46c
debug1: no match: babeld-fceaa46c
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to github.com:22 as 'git'
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-dss,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib,zlib@openssh.com
debug2: compression stoc: none,zlib,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 1
Received disconnect from 192.30.255.112 port 22:11: Bye Bye
Disconnected from 192.30.255.112 port 22

But if I revert to wsl1 wsl.exe --set-version Ubuntu 1

wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         1

It works ! 👍

ssh -T git@github.com
Hi maxdobeck! You've successfully authenticated, but GitHub does not provide shell access.

[matheusmb]

This (in PowerShell) appears to work around this issue for me:

New-NetFirewallRule -DisplayName "WSL" -Direction Outbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Inspired by this comment: #4585 (comment).

It didn't work for me. I had to restart the PC once or twice to fix it.

[jasonkcarter]

I am also having the same issue. The Windows Firewall rule posted by @lbergnehr did not work for me. I can navigate a few directories, but commands like vim and ls do not work. I can also not sync with rsync from WSL2. It just hangs and eventually throws a broken pipe error.

[redsoft7]

Changing MTU fixed the problem for me:
#4698 (comment)

[ladefoged]

I had this problem when using Docker for Windows with WSL2.. After shutting down docker the problem didn't occur anymore.

[tmtron]

I also have this problem in WSL2 - nothing of these worked for me:

• change MTU setting
• stop docker
• restart LxssManager

OS: Windows 10 Pro 10.0.19041 N/A Build 19041

[dpiow]

I have the same issue with WSL 2
Windows 10.0.18363.1082
Kernel update 4.19.128
Distribution: Debian GNU/Linux 9 (stretch)
via a regular console (not Windows Terminal), no VPNs, no firewalls (except the built-in) etc

Once logged into ssh server the session hangs up shortly. WSL 1 works like a charm.

[johan718]

This may be unrelated, but I can't SSH into my EC2 instance in AWS. I get a message that the host closed the connection. I can SSH from PowerShell and Putty just fine with my keys.

I'm using Ubuntu 20.04 LTS with WSL2
Windows Version 10.0.19041 Build 19041

[hmageste]

Same problem here. Connecting through ssh to a linux server hangs when I try to use some Linux commands.

I am using Ubuntu 20.04.1 LTS
Windows 10 Pro Version 2004 OS build 19041.685

[ThaDaVos]

Having the same issue.... but I cannot connect at all, it just hangs, eventually times out and then it works just fine...

Ubuntu 18.04 LTS
Windows 10 Pro 2004 OS build 21296.1000 (Insiders)

[onsen194]

I will post for the first time.
It does not hang when using a local LAN connection server,
It seems to hang when using a remote connection server.

ver
　Microsoft Windows [Version 10.0.19042.746]
wsl --list -v
NAME STATE VERSION

• Ubuntu-20.04 Running 2

I haven't figured out the cause, but I found two workarounds.

1. Specify the -t option additionally with the ssh command.
   WSL version 1 did not require such a specification.
2. Execute the cmd.exe / c ssh command.
   It does not occur on windows openssh client.

[nadavpa]

I also have this issue in WSL2.
It happens when I print a long list such as ls -la or cat file.txt
I then reconnect immediatly after it hangs and all works fine.
But it happens every day (on the first connection after restart) and drives me nuts. ssh -t did not help.
I use a VPN
Doesn't happen for non-VPN ssh connections
Turning off Docker for windows didn't help
Happens in Windows Terminal + other terminals

[rob-c-baker]

I am getting this too using rsync and SSH from a WSL2 based Ubuntu 20.04.

I can confirm this works for me:

Changing MTU fixed the problem for me:
#4698 (comment)

From that comment: sudo ifconfig eth0 mtu 1350

...But that needs to be run every time the VM reboots which is not ideal. I'm not certain what would be needed to set the MTU to that value on the VM permanently - I don't have anything in /etc/netplan or in /etc/network/interfaces to edit (but I suppose technically that is a little out of scope for this issue).

[onsen194]

Thanks to nadavpa and rob-baker-ar for their comments.
In my case, resizing the MTU did not resolve the hang.

ssh -V
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f 31 Mar 2020

This is an event where ssh hangs, but since the effectiveness of the workaround is different,
It may be due to another problem.

[anton7811]

Same issue. Windows 10 build 20H2.
The only solution works - rolling back to WSL1 as mentioned by @maxdobeck:
wsl --set-version WSL_NAME 1

[mario-lukic]

This (in PowerShell) appears to work around this issue for me:

New-NetFirewallRule -DisplayName "WSL" -Direction Outbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Inspired by this comment: #4585 (comment).

This seems to help a little bit. I had problems when using SSH via WSL2, while running Wireguard Client ( on Windows ). SSH would freeze constantly ( top or htop would freeze the connection ).
Now it seems to be working better for some servers that are closer ping wise, but still breaks (freezes) for servers farther away....

SSH works just fine when using it from Powershell, while VPN is on.

[clee704]

To diagnose if MTU is the culpit try these commands

# This works for me - prints 80 dashes
ssh username@172.29.1.10 printf -- '-%.0s' {1..80}
# This works aswell - prints 580 dashes
ssh username@172.29.1.10 printf -- '-%.0s' {1..580} 
# This fails for me - just hangs
ssh username@172.29.1.10 printf -- '-%.0s' {1..618}

So while we say that the MTU is an issue on WSL, it also exists on Git Bash for Windows (MINGW64) It did fail once, but not permanently. I saw it working with 80, 580, but fail on 718, and work on 750, so this seems better than WSL, but still inconsistent.

I was also running on WSL2, over a ZeroTier connection which has its own MTU issues, however, when I connected directly to the machine, I did not have the issues. I could just connect with no issues.

So there are most likely several layers of issues in this issue.

Thanks for the command. In my case it seems it works fine until 1314 and stops working from 1315.

I had this issue for a while, but until today it was temporary - running tmux after ssh often froze but after reconnecting and tmux a it worked. But it became more severe since today. Now I cannot do tmux a or even top because it always freezes. I use VPN. No issue with PuTTY.

[stela2502]

Great support Microsoft!
Honestly - there are a lot of users having this issue and you just not care?!
Or is this problem too complicated to solve?
I am really looking forward to a Windows without the windows kernel :-D

[derritter88]

I have "solved" this issue: Removed WSL + all Hyper-V stuff and moved over to VirtualBox with a dedicated Linux VM.

[stela2502]

I have 'solved' this problem by simply using the power shell with ssh and scp ...
I really wonder why Microsoft is not able to FIX this problem!

[trailstrider]

I've been playing with this issue over the past couple weeks. Here is what I've adjusted (and automated for new VMs), done to cope, and what else I've observed:

Manifestation conditions

For me, I have not experienced trying to connect and not being able to do anything at all with SSH. I suspect that issue and how it is manifesting for me are different underlying issues. As pointed out by @andreasmarkussen , this thread is probably capturing multiple different underlying issues from different people. It also captures them over time, as WSL and the OSes involved have shifted. For instance, the MTU aspect seems to have zero implications for me, and I can't help but think that was applicable for the earlier manifestations only and Microsoft has since fixed that aspect - or maybe I'm just lucky.

1. I am using Windows 11 Enterprise ( Build 22000) with WSL2 (Kernel version: 5.10.102.1), Ubuntu 20.04.4 LTS
2. The latest Docker Desktop (4.8.2 (79419)) is running in the background, but not running any containers.
3. Connections to Linux VMs in the cloud (Azure) are what I'm primarily seeing affected. [NOTE: AWS connections get random multi-second lags, but I don't lose connections the same way - though sometimes they get forcibly disconnected by the remote - not the same behavior though, as that is explicitly stated on disconnect.]
4. I'd be in the middle of typing into the terminal (bash or vim), and the connection would freeze - and never come back.
5. Mostly in the terminal from VS Code (v 1.67.2 as of this writing, and using the stated WSL2 Ubuntu stated above), but would also happen in Windows Terminal. I don't know why the VS Code terminal instances are affected more, or perhaps it just seems that way because of how I work?

Coping with disconnections

I've always been a fan of using screen for remote connections so that I could detatch and disconnect, and later reconnect and re-attach to the session, kept running int he background until I got back. Generally, I'd not bothered to use it when first setting up VMs, but I began to become more aggressive in its use with this issue, using screen -Rad upon login in order to have persistent sessions and not lose work when my connection got borked.

If you've not used screen or similar terminal multiplexera, I highly recommend using this for remote connections in general.

SSH Configuration

Below is an automation function (written with bash in mind) being used with cloud-init
It can also be used for establish systems for a quick change (just change the backup extension since it isn't being run by cloud-init in that instance) The main things being changed focus on maintaining a connection. Since using this on my VMs, I've now been able to keep SSH connections alive overnight, I am confident that the settings made in the below code made a tremendous difference. I've not tested to see which setting was ultimately responsible, or if indeed it is the entire combination of TCPKeepAlive yes, ClientAliveInterval 30, and ClientAliveCountMax 10000 that ultimately made the difference. Note I also change the default port, and force use of SSH keys by disabling password authentication - take those lines out if you don't want to do that.

Note, in terms of sequence it is important to take care when you run this while launching a new VM. There are two primary considerations: 1) not getting locked out of your system, 2) making a mess of things during system updates.
For the first concern, I've tested it multiple times, and know that it works reliably for me now. I can either add port 22 to my security group temporarily during startup, or just use the new port assignment after I've given the VM enough time to do its thing. For the second, I've noticed that upgrade often impacts /etc/ssh/sshd_config, so I've found it easier to just make sure I've done the update/upgrade first. For whatever reason, before the upgrade I've found the file to be empty as well. I actually like having the other commented out defaults for reference when looking at the file, so doing the upgrade first is useful in that regard as well.

configure_ssh() {
    echo "Changing SSH port to ${SSH_PORT}, as well as a few connectivity settings..."

    declare -A ssh_settings
    ssh_settings[Port]="${SSH_PORT}"
    ssh_settings[TCPKeepAlive]="yes"
    ssh_settings[ClientAliveInterval]="30"
    ssh_settings[ClientAliveCountMax]="10000"
    ssh_settings[PasswordAuthentication]="no"
    ssh_settings[ChallengeResponseAuthentication]="no"

    SSHD_CONFIG=/etc/ssh/sshd_config
    SED_EXP=""
    for setting in "${!ssh_settings[@]}"; do
        if grep -e "^#*${setting} " ${SSHD_CONFIG}; then
            echo "Changed --> ${ssh_settings[${setting}]}"
            SWAP_TEXT="s/^#*${setting}.*/${setting} ${ssh_settings[${setting}]}/;"
            SED_EXP="${SED_EXP} ${SWAP_TEXT}"
        else
            ADD_TEXT=\$"s/"\$"/\n${setting} ${ssh_settings[${setting}]}/;"
            SED_EXP="${SED_EXP} ${ADD_TEXT}"
        fi
    done
    
    SFX=$(date +%Y%h%d_%H.%M)
    sed -i.cloud-init.bak.${SFX^^} -e "${SED_EXP}" /etc/ssh/sshd_config 

    # Restarting SSH immediately since we'll want to connect to it in short order for monitoring...
    systemctl restart ssh
}

[facboy]

I had similar issues with VPN traffic, have you tried enabling tcp_mtu_probing in WSL2? I set it to 1, fixed it for me.

[ktpx]

I had similar issues with VPN traffic, have you tried enabling tcp_mtu_probing in WSL2? I set it to 1, fixed it for me.

Thanks for the suggesion, did nothing here.

[Deadmansshoe]

So I had also problems with my ssh connections on my desktop PC for a long time now. For me, the MTU did not help at all, but now it seems that the problem for me was being connected through Wi-Fi and Ethernet at the same time. Since I switched off my Wi-Fi antenna, the connection freezes and loop breakdowns seem to have stopped (for at least about half an hour now...).
Maybe this can help someone as well (or help Microsoft fixing these problems...).

[sxlijin]

Sharing my anecdata: in a WSL2 client, when I crank up the SSH client verbosity, this is what I get:

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

at which point it hangs until eventually I get Connection closed by $REMOTE.

Server logs (seen via journalctl -u ssh) show:

$timestamp $hostname sshd[11151]: fatal: Timeout before authentication for $client_ip port $client_port

which suggests to me that packets in the key exchange are getting dropped somewhere in the response path in a non-deterministic fashion. The fact that some folks can get around this by twiddling random network settings about packet size I think corroborates this; if the non-determinism was intrinsically the result of, say, some kind of byte truncation for large packets, then I could see that happening.

[benjaesq]

Debian 11 (bullseye) in WSL2 shows the ssh hanging as well.

[rodonal]

Time to time this occurs to me too. I had changed MTU to 1350 and that had fixed the issue. Now when it occurs I just restart my laptop unfortunately.

[fysmd]

Time for yet another bump:

wsl -v
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.2057

$ uname -a
Linux blahh 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"

SSH fails after random periods. Even with continual traffic, keepalives etc.

[itakatz]

Same issue: SSH does not connect at all (while putty or ssh.exe in terminal does work).
Windows 11 (version 10.0.22621) and WSL2 with Ubuntu 22.04. None of the suggested fixes worked.

[grapheon]

WSL2 on Debian 12 (bookworm) i don't see any problems, unlike Ubuntu 22.04

[pedrohgmacedo]

In WSL1, everything works smoothly and have no issues. It's only in WSL2 that this happens.

In my experience, WSL2 is 💩.

[FPintoCircontrol]

MPU of the eth0 adapter is the cause

In case anyone has in the same issue. I do not find the logic of the issue. I tried all options and none worked. My setup is:

• Windows 11
• WSL 2 Ubuntu 22.04
• VPN

As one solution I read that you have to match the MTU of your VPN adapter and WSL eht0 adpater. That did not work for me. Honestly I just started testing random MTU number until it worked with 700. You can try several values and maybe it helps you sudo ip link set dev eth0 mtu 700

[chanpreetdhanjal]

Hi. Can you please collect networking logs by following the instructions below?
https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues

[jpcoetzeeza]

MPU of the eth0 adapter is the cause

In case anyone has in the same issue. I do not find the logic of the issue. I tried all options and none worked. My setup is:

* Windows 11

* WSL 2 Ubuntu 22.04

* VPN

As one solution I read that you have to match the MTU of your VPN adapter and WSL eht0 adpater. That did not work for me. Honestly I just started testing random MTU number until it worked with 700. You can try several values and maybe it helps you sudo ip link set dev eth0 mtu 700

This worked for me when hanging on git push in WSL2.

Attached the following logs. First with MTU at 1500 then with MTU at 1400
WslLogs-2024-09-19_15-24-18.zip
WslLogs-2024-09-19_15-25-16.zip

[Petros626]

I did the following, which worked for me (Windows 10 & WSL2):

1. sudo nano /etc/ssh/ssh_config
2. Under section Host* add ServerAliveInterval 5 (I guess any value is okay?)
3. sudo nano /etc/ssh/sshd_config
4. Near the end of the file search for: ClientAliveInterval 60; TCPKeepAlive yes; ClientAliveCountMax 10000
5. service ssh restart
6. ssh nameofmachine@xxx.xxx.xxx.xx

[younger027]

it's still not fix???

[earizon]

Sort of related problem "here". It all looks to be related to Windows Defender doing weird things.

Disabling the Windows Defender is not an option, since it is controlled by my Security Department.

I try to "scp" a file about ~20Mbytes in size from machine A (WSL guest) to machine B (remote cloud machine). scp starts normally, with a copy speed of about 500Kbytes/seconds. Then performance starts to degrade until the copy stalls.

I can manage to skip the Windows Defender lock ("sort of") with the next trick:

• I install ssh server on my WSL linux (Ubuntu 22.04) guest.
• I use the windows native ssh client to connect from Windows to my WSL linux guest, and then I use the -R option to forward, once connected, an arbitrary port in my Linux guest to the intended machine B (remote cloud) like:

1. Step 1: Connect from windows to WSL guest through ssh tunnel and create tunnel to intended remote machine.

  (at native windows command prompt )
  c:\windows\myUser > ssh -R 1234:machineB:22 ubuntu@<wslIP>
  (Port 1234 in my linux guest will be forwarded to the remote machineB at port 22 (ssh port)

2. Step 2: copy from wsl guest to remote machineB through the ssh tunnel:

  $ scp -oPort=1234 myTestFile_20MbytesInSize  myRemoteBUser@127.0.0.1

In summary:

  wsl guest ··>   ssh      ··> remoteB              <·· FAIL. Windows Defenders breaks it all

  wsl guest ··> windows ··> ssh tunnel ··> remoteB  <·· "work for me". (degraded performance but it does not stall)

Edit: In my "Works for me" scenario, setting MTU to the biggest possible value (65530) makes things work faster, specially for localhost connections.