Proxmox iSCSI Uses Management Network Instead of Storage Network: Fix the Interface Binding

Proxmox iSCSI uses management network instead of storage network because open-iscsi picks the source interface by destination IP, not by the storage config. The fix is a one-line bind in iscsid.conf, then restart the service and check with tcpdump.

Why the portal IP decides the source NIC

When you add iSCSI storage in Proxmox, you give it a portal IP. The kernel routes to that IP, and the source address gets chosen by the routing table. If your management network is the default route, the iSCSI session leaves through it. The storage network might be a separate subnet, but open-iscsi doesn’t care about your intent — it binds to whatever the route says.

That’s why static routes feel like the answer, but they’re fragile. A reboot or a network restart and the route is gone. The proper fix is to tell open-iscsi which interface to use for a given target.

The iface binding fix

Edit /etc/iscsi/iscsid.conf and add a binding for your storage NIC. You need the initiator name and the target portal. Here’s the pattern:

node.conn[0].startup = manual
node.session.nr_sessions = 1
node.conn[0].iface.hwaddress = 00:11:22:33:44:55
node.conn[0].address = 192.168.100.10
node.conn[0].port = 3260

Replace the MAC with your storage NIC’s MAC and the address with the iSCSI target portal IP. Then restart the daemon:

systemctl restart iscsid open-iscsi

Now the session should come up on the storage NIC. But trust nothing — verify it.

tcpdump check

Run this while the session is active:

tcpdump -i any -n port 3260

You should see traffic leaving from the storage NIC’s IP, not the management one. If it’s still wrong, check the routing table again — maybe the storage subnet has no route at all, and the kernel falls back to default.

This is the kind of thing that drives you nuts because everything looks configured right in the GUI. The portal IP is reachable, the LUNs show up, but the traffic is on the wrong wire. The fix is small, but you have to know where open-iscsi makes the decision.

If you’re also dealing with Proxmox storage quirks, the ZFS storage summary mapping post might save you some head-scratching.