Virtual UTM network card confusion?

I have just had a power cut...UTM comes back online and again the card ordering is wrong!

I've turned the UTM off many times prior to this update and not once has it jumbled the ordering up...

To permanently change the NIC order, do the following as root at the command line:

edit /etc/udev/rules.d/70-persistent-net.rules

Save the file and then reboot the VM so the new order is loaded.

Cheers - Bob

Thanks Bob, will give it a go as soon as I can. 

Had this changed in the 9.5 release, do you know? Just odd it only starts after this update...unless I've been lucky int the past with network adaptor asignments

Whereas V9.500 seems to work well for new configurations from scratch, the Up2Date process doesn't seem to be out of beta yet.

Cheers - Bob

Does this file - /etc/udev/rules.d/70-persistent-net.rules even exist in 9.5?  I can't find it In a fresh install under esxi.  Just realized that for some reason, utm insists on eth0 being the lan port. I want eth0 mapped as a wan port.

Local CLI access shows this as a result.  The 192.168.2.51 ip is assigned by an upstream router.  Eventually it will be the public ip.

Instead, this line should read.... https://10.10.12.34:4444

------

edit:  Clarification

The "culture" around the UTM expects to see eth0 used for the "Internal" (LAN) Interface definition, so you will find it easier to get help here if you do the same.  The only 9.502 unit I access is my lab UTM.  The 70-persistant-net.rules file appears to have been rewritten at the beginning of the 9.414->9.501 Up2Date process.  I don't know if it is present in a new 9.5 install.

Cheers - Bob

For a piece of software that's so configurable, not being able to specify the lan/management interface seems a step backwards.

What do you mean by rewritten?  Removed?

After reading a bunch of threads on the topic, I thought about possible workarounds.  For ease of manageability, it makes more sense to me to have port 1 (eth0) for WAN (internet), port 2 and above for nonWAN.  The particular box i'm using has 4 onboard nics. Considering this setup will be running under esxi, it's easy enough to remap the lan port assignment in the VM config while keeping the desired physical interface assignment. 

My concern is if the hardware should ever change or config is restored to a bare metal installation, port assignments will be changed.  There should be an easy mechanism to remap them as needed without jumping through all sorts of crazy hoops.

What a mess getting this all organized!@#

I decided to install utm with all 4 nic's available/defined in the vm config. Getting the order right is a nightmare.

Physically on the unit, WAN (internet) is plugged into port #1, LAN port #2, and ports #3/#4 will eventually be bridged to #2, or used for vlans.

Considering utm's convention of eth0 being assigned to the local lan/management interface, actual mapping would need to happen in the VM config.

Initially I set up each vmswitch/port in the following order;

nic1 - local  lan (phys port #2)

nic2 - wan/internet (phys port #1)

nic3 - local  lan #2 (phys port #3)

nic4 - local  lan #3 (phys port #4)

The expectation was that this would enumerate appropriately and be assigned to eth0, eth1, eth2, eth3 respectively.

Of course this did not happen.  It appears utm enumerates eth assignments based on pci order.  I played around with manual mac assignments but that didn't change the actual eth assignment order. Actual positions remained the same, just the mac changed.

Based on this thread, Esxi allows pci slot number manipulation - Under edit vm, VM options tab, Advanced, Configuration Parameters, edit configuration.  That was worth a shot since changing mac's had no effect earlier.  I changed the order of the initial values to obtain the desired mapping.

So the end result looks like this now (which matches how the cables are physically connected to the unit).

However from UTM's perspective, Lan_port(2) is actually assigned to eth0, wan to eth1, etc.

The take away is all of this could be completely avoided if utm allowed proper eth reassignments.   The visual artifact when looking at the local console was an eyesore but made me wonder if there are other functions that rely on this definition too.  Decided to deal with this issue before I got too deep into utm configuration.

PS.  I should also add, the qotom box I'm using adds its own stupidity to the mix by not mapping the physical ports in order to the internally assigned mac addresses.  This has more details. This issue is dealt with outside of UTM in the esxi virtual switch assignment.  Nics assigned to the UTM should already be in proper order.

What a mess getting this all organized!@#

I decided to install utm with all 4 nic's available/defined in the vm config. Getting the order right is a nightmare.

Physically on the unit, WAN (internet) is plugged into port #1, LAN port #2, and ports #3/#4 will eventually be bridged to #2, or used for vlans.

Considering utm's convention of eth0 being assigned to the local lan/management interface, actual mapping would need to happen in the VM config.

Initially I set up each vmswitch/port in the following order;

nic1 - local  lan (phys port #2)

nic2 - wan/internet (phys port #1)

nic3 - local  lan #2 (phys port #3)

nic4 - local  lan #3 (phys port #4)

The expectation was that this would enumerate appropriately and be assigned to eth0, eth1, eth2, eth3 respectively.

Of course this did not happen.  It appears utm enumerates eth assignments based on pci order.  I played around with manual mac assignments but that didn't change the actual eth assignment order. Actual positions remained the same, just the mac changed.

Based on this thread, Esxi allows pci slot number manipulation - Under edit vm, VM options tab, Advanced, Configuration Parameters, edit configuration.  That was worth a shot since changing mac's had no effect earlier.  I changed the order of the initial values to obtain the desired mapping.

So the end result looks like this now (which matches how the cables are physically connected to the unit).

However from UTM's perspective, Lan_port(2) is actually assigned to eth0, wan to eth1, etc.

The take away is all of this could be completely avoided if utm allowed proper eth reassignments.   The visual artifact when looking at the local console was an eyesore but made me wonder if there are other functions that rely on this definition too.  Decided to deal with this issue before I got too deep into utm configuration.

PS.  I should also add, the qotom box I'm using adds its own stupidity to the mix by not mapping the physical ports in order to the internally assigned mac addresses.  This has more details. This issue is dealt with outside of UTM in the esxi virtual switch assignment.  Nics assigned to the UTM should already be in proper order.

I say rewritten because file formats can change and updated programs may change.  WebAdmin also rewrites files when you make changes and then the configuration daemon might make a thousand changes based on one or two of yours.  WebAdmin just maintains databases of settings and objects.  Once you've learned the metaphor, you will find it easy, elegant and powerful.

Cheers - Bob