Thanks to all who have responded here, it helped me cobble together my own take on this.
For context: Probably due to domain group policy, use of static IP addresses with WSL permission inbound/outbound rules on Windows Firewall did not work for me reliably. On some boots the static Linux IP address and SSH listener on it work, on other boots - not even pinging (from Windows host). Using powershell in windows explicitly to poke the linux VM is clumsy (gotta remember to do it on all reboots, or use task scheduler or some such...)
Ergo - let Linux guest do all its magic!
- Probably need to get PowerShell installed into Windows, as for other solutions (in particular allows to elevate the call for port forwarding on host OS side) :)
- Create
/root/setup-network.sh
:
#!/bin/sh
# https://superuser.com/a/1723531/433945
# Add to /etc/wsl.conf boot/command=... for autostart?
PATH="/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0:$PATH"
export PATH
# Fenced with a separate touch-file, an IP address might be not
# available when this first runs - allow reentry until success!
# Assumes first IP is the one generated by WSL anew for each VM boot.
AUTOIP="`hostname -I | awk '{print $1}'`"
if [ -n "$AUTOIP" ] && [ ! -f /dev/shm/network-initialized-fwd ] ; then
powershell.exe -Command "Start-Process netsh.exe -ArgumentList \"interface portproxy add v4tov4 listenport=22099 connectport=22 connectaddress=$AUTOIP\" -Verb RunAs"
# Consider similar forwards for X11, VNC, etc.
touch /dev/shm/network-initialized-fwd
fi
# (Optionally) shield the rest of such init (assuming SSHD listens
# on IP_ANY, so starting it once suffices)
[ -f /dev/shm/network-initialized ] && exit
ps -ef | grep -v grep | grep sshd || sudo service ssh start
# I've also had problems resolving Internet DNS, so this settled in
# (also works if /etc/resolv.conf is a dangling symlink to non-existent
# dir below, by default). Specifically, my problem was having the
# resolver re-generated from Windows host settings, and not having
# VPN etc. access to the domain DNS server to actually resolve stuff.
# Per my notes, https://github.com/microsoft/WSL/issues/6977 might
# also help: /etc/wsl.conf => [network] => generateResolvConf=false
grep 8.8.8.8 /etc/resolv.conf || {
sudo mkdir -p /run/resolvconf/ && \
echo 'nameserver 8.8.8.8' | sudo tee -a /etc/resolv.conf
}
touch /dev/shm/network-initialized
- And add this into Linux guest's
/etc/wsl.conf
as
[boot]
command="/root/setup-network.sh"
- Alternately, call it in your user's
~/.profile
(maybe place in its homedir to be accessible) - it does work, but only after you first open a terminal to WSL. Some may deem it more secure and better facilitating host OS boots vs. UAC pop-up noted below.
Upon first start of the guest/session after host boot (or wsl --shutdown
and subsequent start) Windows may ask for UAC permissions for that netsh
command called from the guest system. But now it is all constrained in the guest and tied to using it.
v4tov4
routing always work at boot then it doesn't matter that WSL's IP isn't static.