[Bug] Cross-Cluster replication map only one bridge

[MatthieuTr]

Hey there! 👋 Thanks for taking the time to report this bug — we appreciate it!

Please keep in mind: PegaProx is developed and maintained entirely by volunteers in our free time. We do our best, but we can't work magic 🪄 — please be patient, we'll get to your issue as soon as we can.

Want to help keep PegaProx alive?

• ⭐ Star the project — it's free and helps a lot!
• 💖 Become a Sponsor — helps us dedicate more time to development
• 🤝 Contributing code or docs is always welcome too!

---

Describe the bug

I have set up cross-cluster replication for an OPNSense virtual machine equipped with 4 network cards, each connected to a different Linux bridge/VMnet.
When configuring the replication, I can only select a single bridge/VMnet.
The replication works correctly, but the network cards on the replicas are all connected to the selected bridge/VMnet and not to the originals one.

All the VMnets and bridges exist on the destination cluster.

See screenshot for the result.

I think the issue 242 is related

Steps to Reproduce

1. Create a virtual machine with more than one network interface, each on a different bridge/vmnet.
2. Create a replication task on it.
3. Associate the bridge with one of the VM’s networks.
4. Start the task.
5. On the replica, all network interfaces are on the selected bridge/vmnet.

Expected behavior

Normally, you should be able to map each network card to the bridge/vmnet of your choice.

Environment

• PegaProx Version: 0.9.12.2
• Installation Method: Other, via repo
• OS: Debian 13
• Browser: Firefox last version
• Behind Reverse Proxy? No
• UI? Corporate

Logs

I can't find any log

Screenshots

Origin VM

Replica

Checklist

• I have searched existing issues to make sure this is not a duplicate
• I am using the latest version of PegaProx

[github-actions]

👋 Thanks for reporting a bug!

Unfortunately, it looks like some required information is missing.

Please provide:

• Steps to Reproduce

Why?
We are volunteers maintaining PegaProx in our free time. Complete bug reports help us fix issues faster. 🐾

Closing for now — please reopen with the required details or open a new issue.

This is an automated message.

[github-actions]

👋 Thanks for reporting a bug!

Unfortunately, it looks like some required information is missing.

Please provide:

• Steps to Reproduce

Why?
We are volunteers maintaining PegaProx in our free time. Complete bug reports help us fix issues faster. 🐾

Closing for now — please reopen with the required details or open a new issue.

This is an automated message.

[MatthieuTr]

Steps to Reproduce

1. Create a virtual machine with more than one network interface, each on a different bridge/vmnet.
2. Create a replication task on it.
3. Associate the bridge with one of the VM’s networks.
4. Start the task.
5. On the replica, all network interfaces are on the selected bridge/vmnet.

[mkellermann97]

Reopening — the bot auto-closed this for "missing Steps to Reproduce", but your steps are right there (1–5), so that was a misfire on its part. And you're right about the cause: I traced it, and a cross-cluster replication job carries a single target_bridge (defaults to vmbr0) that gets applied to the replica's NICs across the board — so a VM with four cards on four bridges comes out the other side with all four on the one you selected. The per-interface mapping you're after does already exist on the DR side (Site Recovery failover takes a source→target bridge map), it just hasn't been carried over to the scheduled replication path yet — doing that is schema + UI + the apply step, so it's a real enhancement rather than a quick patch. I'll track it with #242 since they're the same gap; no timeline I can promise, but it's logged with your repro. opencollective.com/pegaprox helps free up the hours for exactly this kind of work. — MK

[MatthieuTr]

Hello, thank you for your reply.

No problem; we'll assign the network cards manually in the meantime.