VM can ping the host but SSH/SCP fails? Check the host's ufw
I was inside a Windows Server 2025 VM (running on a Linux host via libvirt/Vagrant) trying to scp a file from the host. The host answered ping fine, but every ssh/scp to it just hung and failed. The obvious suspect — the Windows firewall on the VM — was a red herring. The real culprit was ufw on the Linux host, which MX Linux configures to default-deny incoming and only allow the LAN.
The giveaway: ICMP works, TCP doesn't. ufw permits ping by default but drops unlisted TCP ports, so connectivity "looks" fine while SSH silently dies. If you can ping but not connect to a port, suspect a host firewall, not a routing problem.
Check what the host actually allows:
sudo ufw status verbose
In my case port 22 was only open to the physical LAN (192.168.68.0/24), while the VM lived on the libvirt NAT subnet 192.168.121.0/24 — a different network the rules never mentioned. So the VM's packets hit the default deny (incoming) and vanished.
Fix: explicitly allow the VM subnet to reach the port you need.
sudo ufw allow from 192.168.121.0/24 to any port 22 proto tcp comment 'libvirt guests -> host ssh'
After that the VM connects straight away, and the rule survives reboots.
One trap worth naming: if the host is also on a Tailscale/VPN network, its public name may resolve to the Tailscale IP (e.g. 100.x.x.x) — but from a NATed guest that's still the same host, reached through the same deny-by-default firewall. Don't let the fancy hostname distract you; the fix is the same ufw rule on the libvirt subnet.
If you'd rather not open the firewall at all, push the file the other way — from the host into the guest. With Vagrant that's just vagrant upload <src> '<C:\dest>', no inbound rule needed.