NG Firewall - udev rules for matching MAC Addresses to GUI-usable names?

[erasedhammer]

I've been getting tired of Untangle and/or Debian mixing up my network interfaces like its a blender.

Replace ONE of my FIVE network cards? all the interfaces are now randomized.
Upgrade major version? Also interfaces are randomized.
Some reboots? yep you guessed, randomized.

Not even the re-map option in the settings truly works. If I match interface names up to the proper MAC addresses, the IP configuration stays behind on the old MAC (for 50% of my NICs for some reason?).
I don't really get why Untangle doesn't try a little harder to keep the Interface IDs and IP configuration tied more tightly to the MAC address. A plugged in cable will always be tied to a single port and thus a single MAC address, so tieing the upper level stuff to the MAC makes sense to keep the network up and working with hardware changes.

I'm sure this isn't entirely Untangles fault, I've fought similar issues with the new network interface naming scheme on plain Debian servers. In that instance, when the server rebooted, the main interface would change names from enp3s0 to enp4s0. Then when I change the interfaces file and reboot, the name would go back to the enp3s0, like playing wack-a-mole. I got fed up and just slapped a udev rule in to always ensure the same interface name gets applied to the MAC address, then apply IP settings to that interface name.

Ironically, I've hear debian introduced the new naming scheme to stop things like this happening. If I remember correctly, the new interface discovery goes off of the order that PCIe devices are discovered. Well guess what, that is not always a static process!

Sorry for the rant, but the main question I wanted to bring up here is to see if anyone has introduced udev rules into their NG Firewall to lock in MAC addresses to the configurations in the GUI.

It seems that Untangle already does some interface renaming from the standard enp*s*f* scheme to the old eth* style. Not sure entirely how they do that, /etc/udev/ is completely empty.
Untangle seems to leave custom configurations (apt packages, systemd services, etc configs) alone from upgrade to upgrade, so using udev rules seems like a good way to integrate in the long term. The issue is when to apply the rules in the boot process, and what to rename interfaces to. I suppose if Untangle named one interface eth5 which was tied to an IP of 192.168.1.1, then I could throw a 99 udev rule to apply the interface name eth5 to the MAC that was previously used for eth5. Not sure if Untangles programs would kick in after a udev rule and just change it back to some random nonsense though. Perhaps a systemd service to kick off after untangles scripts to rename the interfaces?

Anyone have some good ideas for this?


For anyone wondering, here is my hardware setup (not that old):
CPU: Xeon W-2235
MB: Supermicro x11srl-f (32gb ddr4-2933 Reg. ECC)
2x onboard MB RJ45 ports
NIC1: Intel x710-DA4
NIC2: Intel x710-DA4
NIC3: Intel I350-T4v2
NIC4: Intel I350-T4v2

[gravenscroft]

It is, as you say, not our fault: it's to do with Debian itself (and/or whatever bootstraps the device prior to Debian itself launching). This happens on a lot of what we call 'custom hardware', meaning you didn't buy the appliance from us.

There is a fix, but it's been some time since I saw this come up. I'll dig around and see what I can find for you.

[sky-knight]

Custom hardware he says... as if any server that has different types of NICs in it isn't vulnerable to this stupidity. Yes, I know Debian did it, but Untangle should STILL be making these stupid .link files for us.

To the OP here: https://wiki.debian.org/NetworkInter...NG_.LINK_FILES

#/etc/systemd/network/10-persistent-net.link
[Match]
MACAddress=01:23:45:67:89:ab

[Link]
Name=lan0

You need 1 .link file for each interface. The file simply maps a MAC address to an interface name. Just make sure the interface names are ethX derived and match whatever is configured in the UVM and on reboot your interfaces will be back where they should be as well as stay there forever. You can update these flags and reboot to make whatever configuration you need if you need to change them in the future. Untangle doesn't really care what's on ETH0, as long as you're expecting that NIC to come up with your WAN details it's fine. Of course once upon a time we could remap Untangle's virtual interfaces to physical ones too... but that's busted so beware. A .link file for each physical NIC is the only way to do this reliably.

Note, due to these files the interface names are "burned", this causes other issues if you ever have to swap out interfaces in your hardware. So it's not like this solution is perfect, but it does emulate what Debian 9 and older did by default. But back there we had to delete these files at times to keep things working. Device enumeration is hard apparently.

But yeah, basing interface naming flags off PCI enumeration order was a boneheaded move on the part of Debian's maintainers. Interfaces need ID'd and locked into place by that ID. MAC address works, but that's a crutch too... they aren't as unique as they should be. It's kind of hard for NGFW to know where an interface is when the blasted device flags change on reboot!

Also, a BIOS that cannot make up its mind how it enumerates its hardware needs shot too... but that's another discussion. Just go make your .link files and know you're in good company! XD

[gravenscroft]

As always, sky-knight to the rescue!

[erasedhammer]

Custom hardware he says... as if any server that has different types of NICs in it isn't vulnerable to this stupidity. Yes, I know Debian did it, but Untangle should STILL be making these stupid .link files for us.

To the OP here: https://wiki.debian.org/NetworkInter...NG_.LINK_FILES



You need 1 .link file for each interface. The file simply maps a MAC address to an interface name. Just make sure the interface names are ethX derived and match whatever is configured in the UVM and on reboot your interfaces will be back where they should be as well as stay there forever. You can update these flags and reboot to make whatever configuration you need if you need to change them in the future. Untangle doesn't really care what's on ETH0, as long as you're expecting that NIC to come up with your WAN details it's fine. Of course once upon a time we could remap Untangle's virtual interfaces to physical ones too... but that's busted so beware. A .link file for each physical NIC is the only way to do this reliably.

Note, due to these files the interface names are "burned", this causes other issues if you ever have to swap out interfaces in your hardware. So it's not like this solution is perfect, but it does emulate what Debian 9 and older did by default. But back there we had to delete these files at times to keep things working. Device enumeration is hard apparently.

But yeah, basing interface naming flags off PCI enumeration order was a boneheaded move on the part of Debian's maintainers. Interfaces need ID'd and locked into place by that ID. MAC address works, but that's a crutch too... they aren't as unique as they should be. It's kind of hard for NGFW to know where an interface is when the blasted device flags change on reboot!

Also, a BIOS that cannot make up its mind how it enumerates its hardware needs shot too... but that's another discussion. Just go make your .link files and know you're in good company! XD

Awesome stuff, thanks.

If I were to change one of the network cards, could I first change the MACs of the link files to the new card then shutdown, install, and everything should be fine? (assuming the cables for their respective networks are plugged into the new correct MAC/Ports)

Just out of curiosity whats the difference between the link files and udev rules?

[sky-knight]

.link files are udev rules, just configured in a way Debian says on their WIKI is "the most future proof".

So if you needed to swap a NIC, then the easiest thing to do would be to edit the appropriate .link files with the new NIC's MAC addresses, down the box, swap the NICs, and bring it back up.

If you don't know the MAC addresses in advance it's not the end of the world, just beware that if your Internal interface isn't available you might have to get creative to access your box. In situations like this I'm glad Untangle has a graphical UI, even if I do attempt to avoid its use as much as possible.

Then there's the last curve ball... technically speaking NGFW doesn't support NIC swapping without a reinstall. The proper procedure is a fresh install of NGFW when you need to change NICs and restore a configuration backup. There are times when the networking gets FUBAR in these cases, and that's why we have a restore without networking feature.

I've had decent luck doing massive swaps, but I also try to avoid mucking with the hardware on that level as much as possible. And when I do? I've got a configuration backup and installation materials on hand while I'm in the room with the server. I find if I'm ready to nuke the thing from orbit, it just works. If I'm 300 miles away that server is becoming a brick when I click save. Just how my luck works.

[erasedhammer]

The only swap in my near future is a 1 for 1 swap of one problematic NIC. Swap will be done with an identical 4 port i350.

I do have IPMI, and good automatic backups of the UVM and my more custom stuff.

What are the specifics of Untangle breaking with a NIC swap?

[gravenscroft]

On the pro side: same hardware, same driver.

On the con side: new MAC address, ergo you'll very likely end up with the interface associated with the old hardware showing as 'missing'. In that case, it's probable the new one won't register at all. Typically, you'd want to reinstall after changing hardware anyway, so I would plan for that and hope it just sorts itself out.

[robinanthony]

MAC Address components are utilized to match a specific source or objective MAC address in the Ethernet rules.

The MAC Address component characterizes the Macintosh (Media Access Control) address of an organization card.

Steps

• Select Setup.
• Grow Different Components branch.
• Right-click Macintosh Locations and select New Macintosh Address.
• Name the component.
• Enter the Macintosh Address. You can enter any legitimate Macintosh address including, for instance, the transmission address (ff:ff:ff:ff:ff:ff).
• Click alright.

[erasedhammer]

Slight problem with the link rules. I finally got around to rebooting to check their effectiveness, but it didn't do anything.

I have all the link files in /etc/systemd/network/
labeled as 10-eth0-net.link, 10-eth1-net.link, 10-eth2-net.link, ect

After the reboot, the interfaces are still the same way as before, and a couple of them switched around (the usual nonsense).

For an example, this is /etc/systemd/network/10-eth10-net.link

[Match]
MACAddress=a0:36:9f:89:60:e7

[Link]
Name=eth10

But heres that mac from ifconfig:

eth15: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       ether a0:36:9f:89:60:e7  txqueuelen 1000  (Ethernet)

The logs for systemd-udevd show it failing, saying the "file exists" which I assume is me trying to rename the interface to one that already has the eth# name.

Jan 12 21:14:26 efw systemd-udevd[374]: eth15: Failed to process device, ignoring: File exists
Jan 12 21:14:26 efw systemd-udevd[374]: eth15: Failed to rename network interface 17 from 'eth15' to 'eth10': File exists

I assume I have to stick with the eth naming scheme for untangle to work, but how can I solve that issue?
Use higher numbers to avoid initial setup conflicts? change the priority of the link files?
I could just make all the eth numbers 100 larger, so eth0 -> eth100, eth1 -> eth101, ect. Not sure if that would be a problem for untangle though.

Also, do I need to reboot to enact the changes, or can I restart systemd-udevd to apply the new names? (most of my firewall rules don't use specific interface names, so it would prevent a prolonged interruption to service)

[erasedhammer]

Just as an update. I did go ahead and name the interfaces eth100 and up. After rebooting and changing the IP assignments to the "new" interfaces, everything seems to be working well.
IPMI and the untangle desktop GUI is definitely a major time and headache saver here.

I do find it a little annoying untangle does a dance with assigning IDs to the eth names and then using the ID to uniquely identify the interface.
It seems to me that they should have just used the MAC address for the ultimate truth for network cards. After all, the MAC address and where the cable goes doesn't change in software.
I would say even making the Interface ID tied to the MAC is a better idea than assigning the ID to the eth number name.

Now that I think about it, wouldn't that solve this whole issue?? seems like a rather trivial change to make in the software. Maybe a feature request is due.

[pctechs]

A few years back, i had to get some vLans working and all i had laying around were USB ethernet nics. The default naming scheme for the version of Linux I was using was to name the nic "usb" + "MAC Address" so usbAABBCCDDEEFF. The problem was that there is a limit to the length of the network interface name. The vLan interfaces would not come up because the name was one or two characters too long. Try this:

root@vLanTester:~# ip link add dev enxAABBCCDDEEFF type dummy
root@vLanTester:~# ip link add dev enxAABBCCDDEEFF.6 type dummy
Error: Attribute failed policy validation.
root@vLanTester:~# ip link add dev enxAABBCCDDEEFFGG type dummy
Error: Attribute failed policy validation.
root@vLanTester:~# ip link add dev enxAABBCCDDEEFFG type dummy
Error: Attribute failed policy validation.
root@vLanTester:~# ip link add dev enxAABBCCDDEEFF0 type dummy
Error: Attribute failed policy validation.
root@vLanTester:~# ip link add dev enxAABBCCDDEEF.7 type dummy
Error: Attribute failed policy validation.
root@vLanTester:~# ip link add dev enxAABBCCDDEE.7 type dummy
root@vLanTester:~# echo WORKS!

There are kernel command line switches to change the network naming scheme.