"
I registered just to let all know that it doesn't seem to work with ethname. I got things working correctly with 2 NICs, which persisted after reboots and shutdowns. But after adding the third NIC, OPNsense lost all previously made assignments, to the point that repairing the assignments worked for that moment but didn't surface the next reboot/shutdown. I gave up on the matter. Tried it using OPNsense 22.1.10_4. Still pretty weird that a (albeit virtual) router cannot have those MAC-addresses tightly attached to WAN and LAN to start with...?
Regarding OPNsense in ESXi: eventually I fixed it by manually editing the VMX after adding the third NIC and before starting the VM and made sure that the third NIC [1] is of exactly the same type as the other two (WAN and LAN) and [2] it comes AFTER the first two in terms of the PCI device enumeration. In my case, I had to use this line in VMX:
for the third NIC, as the first NIC (ethernet0) has number 128 and the second NIC (ethernet1) has number 192.
YMMV.
I notified the author (https://github.com/eborisch/ethname/issues/2) but I guess it is not their problem, as he already explained that OPNsense != FreeBSD (see https://github.com/opnsense/tools/issues/202).
Regarding OPNsense in ESXi: eventually I fixed it by manually editing the VMX after adding the third NIC and before starting the VM and made sure that the third NIC [1] is of exactly the same type as the other two (WAN and LAN) and [2] it comes AFTER the first two in terms of the PCI device enumeration. In my case, I had to use this line in VMX:
Code Select
ethernet2.pciSlotNumber = "256"
for the third NIC, as the first NIC (ethernet0) has number 128 and the second NIC (ethernet1) has number 192.
YMMV.
I notified the author (https://github.com/eborisch/ethname/issues/2) but I guess it is not their problem, as he already explained that OPNsense != FreeBSD (see https://github.com/opnsense/tools/issues/202).
