migration error - network unreachable

Proxmox VM Migration Fails: network unreachable

Server & Cloud Intermediate 👁 21 views 📅 Jun 28, 2026

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

  1. Test SSH from source to target. On the source node, run:
    ssh root@target-node-ip
    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 from /root/.ssh/id_rsa.pub is in the target's /root/.ssh/authorized_keys. If not, add it.
  2. Check if the migration port is open. From the source node, run:
    nc -zv target-node-ip 60000
    If it says "Connection refused" or "No route to host", the port is blocked. Proxmox defaults to port 60000 but you can change it in /etc/pve/datacenter.cfg with a line like migration: insecure,port=60001. But first, open it in the firewall.
  3. Open port 60000 in the firewall. On the target node, check your firewall rules. If you use iptables:
    iptables -I INPUT -p tcp --dport 60000 -j ACCEPT
    If you use ufw:
    ufw allow 60000/tcp
    If you use firewalld:
    firewall-cmd --add-port=60000/tcp --permanent && firewall-cmd --reload
    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.
  4. Check routing. Run on the source node:
    ip route get target-node-ip
    If it shows a weird gateway or no route, you need to add one. For example, if both nodes are on 10.0.0.0/24 but the source tries to send traffic through a default gateway that can't reach the target, add a direct route:
    ip route add 10.0.0.0/24 dev vmbr0
    Make it permanent by editing /etc/network/interfaces.
  5. Test the migration manually. Once the above steps work, try a live migration:
    qm migrate 100 target-node-name --online
    Replace 100 with your VM ID and target-node-name with the name you see in pvecm status. If it still fails, check /var/log/pve/tasks/index for 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:
    migration: secure,network=10.10.10.0/24
    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.
  • Disable firewalls temporarily for a test. If you're stuck, stop the firewall service on both nodes:
    systemctl stop pve-firewalld
    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 seen pve-firewalld block migration even if iptables allowed 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 insecure in /etc/pve/datacenter.cfg:
    migration: insecure
    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.

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?