Proxmox VM Migration Fails: network unreachable
VM migration fails when source and target nodes can't talk over the migration network. The fix is to check SSH, routing, and firewall rules.
Quick answer
Check that both Proxmox nodes can reach each other on the migration port (default 60000) and that SSH works both ways. The real fix is usually opening port 60000 in your firewall or fixing a missing route.
Why this happens
Proxmox migration works by creating a tunnel between two nodes over TCP port 60000 (configurable). The error network unreachable means the source node can't establish this tunnel. What's actually happening here is that the migration process tries to open a direct socket to the target node's IP on that port. If a firewall blocks it, or if the routing table doesn't know how to reach that IP, the connection fails. I've seen this most often when nodes are on different subnets and the administrator forgot to add a static route, or when iptables on the target node drops incoming connections on that port. The source also needs to SSH into the target first — if SSH fails, migration fails too.
Fix steps
- Test SSH from source to target. On the source node, run:
If it hangs or says "Connection refused", fix SSH first. Common causes: SSH key missing, firewall blocking port 22, or hostname resolution broken. I usually check that the SSH key fromssh root@target-node-ip/root/.ssh/id_rsa.pubis in the target's/root/.ssh/authorized_keys. If not, add it. - Check if the migration port is open. From the source node, run:
If it says "Connection refused" or "No route to host", the port is blocked. Proxmox defaults to port 60000 but you can change it innc -zv target-node-ip 60000/etc/pve/datacenter.cfgwith a line likemigration: insecure,port=60001. But first, open it in the firewall. - Open port 60000 in the firewall. On the target node, check your firewall rules. If you use
iptables:
If you useiptables -I INPUT -p tcp --dport 60000 -j ACCEPTufw:
If you useufw allow 60000/tcpfirewalld:
The reason step 3 works is because the firewall was silently dropping the SYN packet, so the source node never got a response and assumed the network is unreachable.firewall-cmd --add-port=60000/tcp --permanent && firewall-cmd --reload - Check routing. Run on the source node:
If it shows a weird gateway or no route, you need to add one. For example, if both nodes are onip route get target-node-ip10.0.0.0/24but the source tries to send traffic through a default gateway that can't reach the target, add a direct route:
Make it permanent by editingip route add 10.0.0.0/24 dev vmbr0/etc/network/interfaces. - Test the migration manually. Once the above steps work, try a live migration:
Replaceqm migrate 100 target-node-name --online100with your VM ID andtarget-node-namewith the name you see inpvecm status. If it still fails, check/var/log/pve/tasks/indexfor the exact error — often it's a timeout, not network unreachable at that point.
Alternatives if the main fix fails
If opening the port and fixing routing doesn't work, try these:
- Use an alternative migration network. If your nodes have a dedicated management network (e.g., a second NIC for corosync), configure Proxmox to use that subnet for migration. In
/etc/pve/datacenter.cfg, set:
This forces migration traffic over that subnet. The reason this works is that the default route might be slow or overloaded, but the dedicated network is clean.migration: secure,network=10.10.10.0/24 - Disable firewalls temporarily for a test. If you're stuck, stop the firewall service on both nodes:
Then try migration again. If it works, you know the firewall was the problem. Don't leave it off — add the specific rule instead. I've seensystemctl stop pve-firewalldpve-firewalldblock migration even ifiptablesallowed it, because Proxmox's own firewall has its own rules. - Use insecure migration mode. If SSH keys are set up but migration still fails, add
insecurein/etc/pve/datacenter.cfg:
This skips SSH tunneling and uses a raw TCP connection. It's less secure but works when SSH breaks. Only do this in a trusted network.migration: insecure
Prevention tip
Before you add a new node to the Proxmox cluster, test the migration port and routing first. I always run nc -zv node-ip 60000 and ssh root@node-ip before joining. Also, configure your firewall once — either use pve-firewalld with proper rules or disable it and manage iptables yourself. Mixing both gives you headaches. If you use VLANs or separate subnets, add static routes in /etc/network/interfaces so they survive reboots. That way, when you need to move a VM in a hurry, it just works.
Was this solution helpful?