The first time you try to ssh to a remote server from WSL over a VPN connection, there's a good chance the connection will hang as soon as you start using it. After a little testing you may notice that it happens when using any command with longer output.
It turns out that the interface for the HyperV VM used to run wsl2 doesn't set its MTU correctly, and the network packets get discarded somewhere along the way. To fix this (assuming we don't have control over the VPN configurations) we need to set the MTU manually.
To find out what MTU setting should be used, the "tracepath" command can be used. Just install the package if needed, run "tracepath <server reachable by VPN>" and check the lowest "pmtu" value shown, that should be set as interface MTU.
For the configuration itself, a quick search on the internet did wield a few alternatives, but the nicer ones unfortunately didn't work... Setting the MTU directly on the HyperV configuration didn't get persisted across reboots; WSL's ubuntu doesn't seem to read any interface configuration on startup by default (and I don't see any good reason to install a init system on WSL)...
In the end I've resigned myself and adopted the ugly solution: put the command to set it directly on ~/.bashrc:
#MTUsudo ip link set eth0 mtu 1350
To get it at least a little less ugly, we can make it so sudo doesn't ask for a password: run "sudo visudo -f /etc/sudoers.d/mtu" and create the file with the following content:
ALL ALL = (root) NOPASSWD: /sbin/ip link set eth0 mtu 1350
That will fix the hanging SSH problem. It's ugly because the MTU should be set dynamically / automatically and It's ugly because bashrc isn't the proper place for this kind of configuration, but at least it works.
No comments:
Post a Comment