Support for debian persistent network interface names?

[ericm1]

TLDR: Has anyone had success removing `net.ifnames=0` from the Debian config so that NG Firewall won't use `eth*` names, and therefore need to remap interfaces if they are recognized in a different order on boot?

This morning my NG Firewall server rebooted and with it came a few hours of downtime, as my network interfaces must've initialized in a different order. In other words, eth0 through eth7 were all assigned to different MAC addresses, so my network had to be remapped inside of NG Firewall. (which is easy enough to do as long as I have physical console access at the time, but it is downtime nonetheless and a huge security concern at the worst)

I dug into this issue and it looks like Debian by default will use persistent network interface names, such as `eno1`. These names are derived from the hardware, so they will always be the same on a reboot. https://wiki.debian.org/NetworkInterfaceNames

However, the install of NG Firewall is configured specifically to use the 'eth0', 'eth1', names. The setting (net.ifnames=0) is in the grub config file:

# /etc/default/grub
GRUB_CMDLINE_LINUX="net.ifnames=0 ramdisk_size=100000 lang=us apm=power-off nomce nodhcp nofstab panic=5"

I tried removing this setting, and I confirmed from the shell that the eth* names went away, but NG Firewall does not seem to recognize the new names.

Does anyone know if there is any way to change this behavior and force NG Firewall to use interface names other than eth*?

[donhwyo]

For now this seems to be the way to fix it.

https://forums.edge.arista.com/forum/ng-firewall/ng-firewall-general/396114-should-i-upgrade-to-v16-6-2-home-user-hompro-subcription?p=396331#post396331

Maybe this will resolve some day?

[ericm1]

donhwyo Thanks for pointing this out. My search of the forums wasn't giving me that result.... and that's exactly what I need to (at least) feel secure that this won't happen again.

I'd still like to see Arista fix the root of this problem though. They purposely set that grub config, and it's a major security risk when at any time someone's firewall could boot up with an entire network segment inadvertently exposed.

(And yes, I've seen this MAC -> name assignment change at other times, not just during the kernel upgrade like everyone is seeing right now)

[sky-knight]

Name assignment can change on any arbitrary restart. HOWEVER, most motherboards worth using are consistent in their enumeration and prevent this. If you've got a platform that's shifting every reboot, the BIOS is crap... it needs replacing.

But yes, the same "fix" applies.

And yes I'm salty about it because I warned about this very issue over a year ago, nothing was done, nothing continues to be done.

I'm even more salty with Debian for making udev be stupid to begin with. No other distribution has this problem, because the kernel is SANE about keeping tabs on things. Debian for some reason... just isn't. AND to make matters worse, in Debian releases 9 and older, the platform DID manage this problem. Automatically writing udev rules on any system that had IPTables in use, for all the obvious reasons. With 10, that all stopped for reasons I'm obviously not intelligent enough to divine.

So here we are... yay.

[ericm1]

It's not shifting on every reboot. I believe it happens after some OS updates, plus after reconfiguring (plugging/unplugging) certain physical interfaces? I haven't taken the time to track down the exact circumstances.

It's a Supermicro X11SDV, so I wouldn't say it's crap hardware. Perhaps it's more likely with that system because there are 8 onboard network interfaces, 4 on an Intel X722 chip and 4 are on an Intel I350 chip.

For now I've gone with the recommendation to add .link files with mappings of MAC Address to Name. I don't see any issue long term with that solution unless I add hardware. But it remains a concern that it is non-obvious to a user of NG Firewall that something like that should be done. Perhaps Arista could write those .link files on an initial setup or make it an explicit option during the "remap interfaces" user experience.

[sky-knight]

Some mainboards arbitrarily enumerate their devices on every single restart. Yours obviously isn't one of those. And you identified Supermicro, which given their lack of quality just about bankrupted me once... yes I WOULD SAY that positively identifies "crap hardware." Or rather, decent hardware supported by a garbage organization, but that's another topic of conversation. You'll sing a very different tune when you get one of their BIOS updates that breaks everything, and you can't "undo."

Your situation of having two different interface types certainly feeds this, because while the interfaces on each individual card aren't likely to move around much, the cards relative to each other certainly will! Though that still should only be happening when the kernel changes, and those updates are mercifully rare.

As for using the .link files, that's the way Debian's WIKI says to pin down the NICs. If you add hardware later, the MAC addresses will still be locked to a specific assignment. So if you add hardware, the existing NICs won't change you'll just get new ones. If you REPLACE hardware, you're going to be reinstalling. NGFW gets EXTREMELY grumpy when you do that, and it's "not supported" for a reason. You'll be reinstalling, restoring without networking, and re-configuring everything in config -> networking by hand as a worst case. That being said, a fresh install with a full restore does give you the ability to map interfaces once, and that process mostly works. Just for the love of all that is good and right in the world don't rely on the remap interfaces button in the UI, that thing just straight doesn't do what it claims, and it will cause you fits.

And yes, Arista should be creating those .link files for us, they're not complex, and they solve the problem. There are other issues certainly, but this band aide is a huge quality of life improvement, that just isn't happening. I assume because Arista feels official hardware is immune to this problem, and that feeling isn't entirely unjustified. BUT Having sold plenty of hardware from the same manufacturers I also know they are not immune, it's simply a rarer concern.

It remains to be seen if Arista is even going to invest in NGFW going forward. They are certainly maintaining it, but it's too soon to know if they're going to really develop it. MicroEdge seems like a more likely candidate from where I'm sitting, and given the nature of the marketplace. So I will not be shocked to be told NGFW is going on the back burner.

[donhwyo]

My search of the forums wasn't giving me that result....

Search seems not to work very well since the forum software change. Google or others work better than the forum search.

It remains to be seen if Arista is even going to invest in NGFW going forward. They are certainly maintaining it, but it's too soon to know if they're going to really develop it. MicroEdge seems like a more likely candidate from where I'm sitting, and given the nature of the marketplace. So I will not be shocked to be told NGFW is going on the back burner.

I hope that is wrong as I still have three years left on a five year renewal. Why would they buy to shut it down? It is not like the have a lot of assets to sell off? Micro edge is openwrt and free.

[sky-knight]

Search seems not to work very well since the forum software change. Google or others work better than the forum search.



I hope that is wrong as I still have three years left on a five year renewal. Why would they buy to shut it down? It is not like the have a lot of assets to sell off? Micro edge is openwrt and free.

Because it no longer has a place in the market. UTMs are dying... rapidly as work forces shift to a cloud centric, mobile model. Larger enterprises with physical premise investments can still use them, but why? If you want a single security control pane, you need something that isn't physically located at a specific location. Complexity is the enemy of security, so you're going to shed your UTM in favor of more modern tools that control the endpoint directly.

So that means Arista keeps MicroEdge, because it's an inexpensive sensor to deploy to the network edge, sitting on top of a stack of switches and waps to create the physical premise network while unifying the control of all that into a single pane of glass that extends to all other locations. This is a stack in direct competition with Meraki, and other stacks like it. This stack has wide market viability.

NGFW simply doesn't fit in that stack, I don't expect them to terminate it, but I also do not expect them to be investing in expanding it.

Meanwhile.. here in the States... https://www.bleepingcomputer.com/new...rity-strategy/

TLDR, the insurance companies are lobbying to make technical solution providers liable for security breaches instead of the customer. So once Arista gets sued because something didn't work, and the vendor that resold Arista is named along with them... Expect HUGE changes. IT will be forcibly adjusted for standardized ethics just like mechanics and doctors. But the lawyering bit is just getting warmed up. There's a ton of risk in here, while profit margins shrink.

So if anything I've written here doesn't make sense, be aware that means you do not understand the tenants of Zero Trust, and therefore are on the chopping block over the next half decade or so.

[road hazard]

It remains to be seen if Arista is even going to invest in NGFW going forward. They are certainly maintaining it, but it's too soon to know if they're going to really develop it. MicroEdge seems like a more likely candidate from where I'm sitting, and given the nature of the marketplace. So I will not be shocked to be told NGFW is going on the back burner.

This is my biggest fear. Being a lowly home user, I'm fine with paying a yearly fee for a NGFW but if Arista isn't going to commit to long term support for Untangle, I might spend my money elsewhere.

Due to the UPnP/hard drive consumption bug, I'm back to sitting on the sidelines until v17 drops but if the long term support isn't going to be there, maybe I'll move along?

[road hazard]

....so you're going to shed your UTM in favor of more modern tools that control the endpoint directly.

At my current company, the IT department utilizes a few different security tools on the endpoints and uses MFA for practically everything. I asked why all this was needed and it was explained to me that all these measures were like putting up multiple roadblocks. If a hacker gets around the first one, no worry....there's 20 more behind it. Hopefully the attacker will give up and move on to easier targets if they run into 2, 3 or 5 roadblocks that must be dealt with before they can proceed.

I see a UTM box as just another layer of security you can place on top of everything else vs. stripping it away. For my home environment, I'm more worried about some zero day WAN exploit being released for my router and an attacker exploiting it. Since I don't know how to shift security onto my iPad and IoT cameras, I need to rely on a strong front door and this is why I'm interested in NGFWs that are a cut above consumer routers.

But I get what you're saying. For large enterprises, maybe cloud based firewalls (along with all the other security tools on endpoints) are the way to go and they can forget all about on-site/dedicated firewall/UTM boxes but even so, I think the bare minimum is to put SOMETHING on the edge to watch over traffic, especially for home and small businesses that might not be able to afford the really nice stuff.

[sky-knight]

At my current company, the IT department utilizes a few different security tools on the endpoints and uses MFA for practically everything. I asked why all this was needed and it was explained to me that all these measures were like putting up multiple roadblocks. If a hacker gets around the first one, no worry....there's 20 more behind it. Hopefully the attacker will give up and move on to easier targets if they run into 2, 3 or 5 roadblocks that must be dealt with before they can proceed.

I see a UTM box as just another layer of security you can place on top of everything else vs. stripping it away. For my home environment, I'm more worried about some zero day WAN exploit being released for my router and an attacker exploiting it. Since I don't know how to shift security onto my iPad and IoT cameras, I need to rely on a strong front door and this is why I'm interested in NGFWs that are a cut above consumer routers.

But I get what you're saying. For large enterprises, maybe cloud based firewalls (along with all the other security tools on endpoints) are the way to go and they can forget all about on-site/dedicated firewall/UTM boxes but even so, I think the bare minimum is to put SOMETHING on the edge to watch over traffic, especially for home and small businesses that might not be able to afford the really nice stuff.

Everyone needs a router, switch, and wireless access point at home that gets regular firmware updates. These updates are there because OS's need patching, and NGFW is still a very nice choice in this space even if running "free" because of this reality. Now, NGFW is VERY SLOW to patch kernel issues compared to what I want, and there are other vendors that are getting those updates out more quickly, Ubiquti is a solid example. BUT those products have other limits.

So I'm still using NGFW at home, but if I were to abandon it I'd swap over to OPNSense, and have my Unifi or Omada stack behind it.

The strong front door is pointless when it's torn down by a user clicking on the wrong link. You're trusting your LAN to be safe, that's simply a bad assumption. All the stuff your work does leans into this hard. But you can get most of this safety from VLAN isolating different classes of devices, and then ensuring all your services are appropriately authenticated. It doesn't cost a TON to do this correctly, but there are costs involved. NGFW can be a part of it for sure! Because the cost for a home license is near trivial, and the combination of Web Filter and Threat Prevention brings a ton of value. The problem with those two modules is they fail to function as soon as you get off your wifi.

For a home environment that's fine, because you only really care about your home. The same applies to any business that has a fixed investment in a large facility. This would be schools, manufacturing plants, hospitals, etc. But as soon as you NETWORK those buildings into a larger conglomerate that has people working from home, and multiple facilities to manage you wind up casting all this aside for cloud controlled stuff because your staff doesn't have the brain space to manage things anymore. Not to mention again... ZERO TRUST, it means you do not trust your admins anymore either.

Enterprises will not bother to waste time with a product that requires an admin to SSH into a box just to create some text files so the thing can update itself. Smaller businesses shouldn't either. And yet, that's exactly the place NGFW lives in now. And yet, people keep asking me why my sales are down? They're down because the product is no longer viable relative to its competition.

[jcoehoorn]

The strong front door is pointless when it's torn down by a user clicking on the wrong link.

This is exactly why I still like Untangle *ahem* Arista ETM. The Web Filter's malware distribution category is likely to stop that link from getting anywhere. And if it doesn't, there's also Application Control, Virus Blocker, and Threat Prevention that also get a crack at it. Of course, this is in addition to antivirus and ad blocking on the client, but the point is Untangle on it's own has four separate layers (five if you count firewall) looking at this stuff, and it's still pretty effective.

[sky-knight]

This is exactly why I still like Untangle *ahem* Arista ETM. The Web Filter's malware distribution category is likely to stop that link from getting anywhere. And if it doesn't, there's also Application Control, Virus Blocker, and Threat Prevention that also get a crack at it. Of course, this is in addition to antivirus and ad blocking on the client, but the point is Untangle on it's own has four separate layers (five if you count firewall) looking at this stuff, and it's still pretty effective.

It is EXTREMELY effective, the problem is the client isn't behind the NGFW anymore.

We're in a timewarp where we've gone back to the dark days of enterprises trusting software on endpoints to secure them, when it's NEVER been able to do so. BlackLotus is a solid recent example of why something like NGFW must be on every network, to act as an impartial traffic cop. The problem is again, we cannot replace every router, we don't have ownership or control over every router. And once you change gears into the endpoint controls that integrate the content controls directly therein, so you have some control over devices as they roam, you don't need the NGFW anymore, because now all you've done is make toubleshooting harder trying to figure out which content control engine blocked the page.

NGFW's malware control technology is wonderful, the problem is it's impossible to keep it between the client and the world, and because of that rendered useless. And if not useless, extremely difficult to sell in an economy that sees companies tightening their belts, and dropping what appears to be duplicate purchases.

[djrees]

For now this seems to be the way to fix it.

https://forums.edge.arista.com/forum/ng-firewall/ng-firewall-general/396114-should-i-upgrade-to-v16-6-2-home-user-hompro-subcription?p=396331#post396331

Maybe this will resolve some day?

I am running 16.6.2 in a Hyper-V VM.
Made several .link files in /etc/systemd/network and restarted the VM.
My interfaces are still all mixed up.

Below is a snip of one of those files.



Did I do this right?

[sky-knight]

I am running 16.6.2 in a Hyper-V VM.
Made several .link files in /etc/systemd/network and restarted the VM.
My interfaces are still all mixed up.

Below is a snip of one of those files.



Did I do this right?

Welcome to HyperV, you didn't configure your NICs to have consistent MAC addresses. If you don't do that, they'll regenerate the MAC addresses on reboot.